Related
I cannot find any good comparisons between Umbraco and Craft CMS. What are the strengths/weaknesses between the two?
I am a sole developer (owner) for a marketing agency and have projects/sites of varying sizes and types. My major considerations are how time consuming it is to develop basic sites, how much maintenance time goes into things like updating, what the platform isn't capable of / where I will run into problems for larger projects, how well it handles things like SEO and page speed etc, and of course all in long term costs.
It ultimately comes down to what platform you're most comfortable working with.
I'm a big fan of Umbraco, and I've used it for the better part of a decade on both small brochureware sites and huge builds. It's probably the best CMS available on the .NET platform, and it's easy to get something built quickly with minimal fuss.
I've also used Craft in the past, and I think it's a great CMS, albeit not as user friendly as Umbraco, but as long as you're providing adequate user training it shouldn't matter.
Umbraco's weakness isn't really a weakness, it's a preference. Being a .NET CMS, you are limited to the .NET platform on Windows, and many developers would prefer to not develop on Windows tooling. If building and hosting on Windows is a problem for you, choose Craft, otherwise I'd recommend Umbraco.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We are trying to choose a framework for our client development for a web application. These are the key points about our application.
1) Rich text application where user performs many activities in the client.
2) We are looking to develop using Java technology
3) The services will be offered in cloud.
4) Mobile support is required.
5) Scalability is also one main concern.
I went through lot of doc and information along with this video http://twit.tv/show/floss-weekly/187 online and have now left with Vaadin and plain GWT. I have a small bit of experience in development with GWT, but not in Vaadin(I have written couple of sample programs only in Vaadin). Please help me in understanding few things.
1) If I have to write a new widget in Vaadin how easy or difficult it is to accomplish?
2) Is there any obvious issues with Vaadin widgets or concepts which might be a blocker for any application?
3) If tomorrow we decide to just switch back to GWT, is that feasible given that Vaadin works with all server code logic?
4) Does the Vaadin method of going to server everytime a concern for applications that are deployed on cloud?
5) Last but most important, how is forum support and future dev?
Thanks a lot. Please note that I have gone through many articles and links about these discussions but feel its good to know from a guy who has real experience in these stuffs atleast for sometime. Thanks again.
GWT
now left with Vaadin and plain GWT.
Vaadin 7 and Vaadin 8, now known as Vaadin Framework, are both Java-based wrappers around Google Web Toolkit (GWT).
You write pure Java code for your business logic and UI-creation. This Java code runs in a JVM on the server-side in a Java Servlet web container. The magic happens when Vaadin uses GWT to auto-generate the necessary HTML, CSS, JavaScript, DOM, AJAX, XML & JSON, WebSocket, and Push code needed to render your web-app’s user-interface within the user’s client-side web browser.
So, pure Java on the server-side, pure web-standards tech on the client-side (no Java on client).
Web Components
Vaadin 10, now known as Vaadin Flow, replaces the internal use of GWT with the emerging Web Components standard technology. This new generation is a major re-write of Vaadin, though its purpose and many of its concepts such as data-binding remain the same.
By leveraging Web Components technology, it should be easier to build Vaadin widgets. And it should be relatively easy to make existing JavaScript-based components not designed explicitly for Vaadin available to your server-side Java code. That's the whole point of Web Components: making web-based widgets that work across various web framework tools.
While the Vaadin Ltd in quite excited and proud to ship Vaadin 10 Flow, they remain committed to Vaadin 8 Framework as well. Vaadin 8 is under active development, with a road map plan for continued support at least through the year 2022.
If you really want to work with GWT, you can do so in Vaadin 8 Framework.
If you want to bet on Web Components instead of GWT, go with Vaadin 10 Flow.
Rich apps
Rich text application where user performs many activities in the client.
If you meant "rich text" as in fonts, colors, and such, you should study the RichTextArea widget bundled with Vaadin 8 as well as check the Vaadin Directory for additional add-ons. That widget is not being brought over to Vaadin 10 Flow, but as mentioned above, the use of Web Components may make other existing such tools available to a Java-based Vaadin app. I see one already in beta.
If you meant "rich" in terms of professional-looking, business-oriented, desktop-style web apps with enterprise-level reliability, that is the very purpose of Vaadin.
Java
We are looking to develop using Java technology
That is the raison d’être of Vaadin: Writing pure Java to leverage the vast ecosystem of Java tooling and libraries, with all its benefits of security, performance, and reliability — while at the same time using web-standards technology to auto-render your app in a web browser.
Mobile
Mobile support is required.
The Vaadin collection of widgets have evolved to support touch-surface gestures.
The Vaadin Ltd company previously offered a special package for mobile support, called Vaadin Touch. The built-in support for touch gestures in regular Vaadin widgets rendered that package obsolete and unnecessary.
Cloud & scaling
The services will be offered in cloud.
Scalability is also one main concern.
Your Java-based Vaadin app does live in a JVM on the server-side. Each current user is represented by session object. All the user-interface widgets appearing in the browser have a counterpart in a Java object on the server. You may be keeping further data and functionality in additional Java objects on the server. You may be calling JDBC or Web Services etc. from that server-side as well.
So all of that takes up memory and CPU cycles on the server. You do need to be cognizant of your programming doing caching and placing other burdens on the server. Any resources shared between users must be thread-safe, as a Java Servlet environment is multi-threaded by design.
Robust server hardware (memory, cores) may be needed, depending on the particulars of your app. Or you may want multiple servers with sticky-session load-balancing if you truly have a very large app with very many users.
The Vaadin Ltd company has simulated the use of a Vaadin app supporting thousands of simultaneous user sessions. You can contact them for consultations on your particular situation.
While scalability is an issue to consider, do not jump to conclusions. Think it through, and do some experimentation.
Creating custom widget
If I have to write a new widget in Vaadin how easy or difficult it is to accomplish?
In Vaadin 8, you can indeed create your own widgets. But doing so required learning the use of GWT. Doable, certainly as you can see from the hundreds of published add-ons in the Vaadin Directory. But still some serious work. The Vaadin Ltd. offered training on this.
In Vaadin 10 Flow, the use of Web Components should make the creation of your own widgets much easier. Check out this starter project provided free-of-cost to get you going. See the tutorial, Creating A Simple Component Using the Element API. Key concepts in creating widgets in Vaadin 10 Flow:
Every Vaadin 10 component always maps to one root element in the server-side DOM representation.
The Element API makes it possible to modify the DOM easily from the server side.
Any other issues?
Is there any obvious issues with Vaadin widgets or concepts which might be a blocker for any application?
Not sure what you mean here. I suggest reading through the excellent Vaadin tutorial and manual. It leads you through using all kinds of features in Vaadin.
Having used other rapid application development environments for desktop apps, Vaadin always made sense to me, fit my way of thinking and doing things.
Bleeding edge
For Vaadin Flow, know that Web Components is still new, and somewhat bleeding-edge. Web Components is actually a collection of technologies. Not all of these are supported fully by all browser makers. So some polyfills are still necessary.
Vaadin Flow also makes use of the pair of modern page-layout features that have finally arrived in CSS: Flexbox and Grid Layout.
Only the latest versions of the browsers are coming close to having good support for all these features. See CanIUse.com for particular details.
Part of Vaadin’s purpose is to paper over the gaps between various versions of various browsers, to insulate us developers using Vaadin. So you may not encounter problems in some browsers, but then again you might.
Also, Vaadin Flow does not quite have all of Vaadin 8 features. Some are under development, and some are planned.
Upshot: If you are eager to ship soon and cannot insist on users updating to the latest browsers, use Vaadin 8 rather than Flow.
Leaving Vaadin for GWT
If tomorrow we decide to just switch back to GWT, is that feasible given that Vaadin works with all server code logic?
If you want to use GWT, and you want to write that server-side logic in Java, then Vaadin 8 Framework is the perfect tool for you. I do not see how you would ever want to leave Vaadin.
But if you did leave Vaadin, you would no longer have the glue that connects your GWT in the browser with your Java code on the server. That glue is what Vaadin provides for you. Of course, you can write your Java back-end business logic to be unaware of Vaadin directly. Indeed, Vaadin Ltd provides a Maven-based multi-module archetype for this very purpose. The backend module holds your business logic and database-access (etc.) code, kept separate from the ui module containing your Vaadin-oriented code.
Network traffic
Does the Vaadin method of going to server everytime a concern for applications that are deployed on cloud?
You will need to do some experimenting and profiling to see the memory and cores needed for your particular app. Vaadin can be demanding on server resources as discussed above.
But technically, no tricks or technical limits with cloud deployment. Just plain Java code running, in a JVM. Anything that can run a Java Servlet web container such as Tomcat, Jetty, Glassfish/Payara, WildFly/JBoss, and such can run your Vaadin app.
If you are concerned by the network traffic, yes, there is traffic. When a user uses a widget such as clicking a button or entering data in a field, your server-side Java app is informed so that your app can respond with business logic. So that means frequent network traversal.
You do have options to not immediately inform the server-side when not needed. In doing so, you are controlling some of that traffic. For example, you can choose whether you want the server-side to be informed (and react) for every single keystroke while entering text in a field, or occasionally such as a pause between keystrokes, or only after the user has completed entry in that field. See the [Configuring the Granularity of Value Change Events](https://vaadin.com/docs/v8/framework/components/components-textfield.html section in the manual.
I did fear a problem with Internet performance when I started with Vaadin. But I can say that in my own experience, I was pleasantly surprised, astounded really, to find this was a non-issue for me. For example, in the United States, with a mere Mac mini in a colo in Wisconsin on very fast Internet connection running a Vaadin 7 or 8 app reacts virtually instantaneously on clients accessing household DSL and Cable-TV connections in Seattle, Florida, and Canada. When accessed from Hong Kong, only the slightest delays, generally imperceptible in a data-entry app.
Your mileage may vary, of course. My example above was a dedicated computer. In contrast, cloud providers are notorious for fluctuations in both CPU availability and network delays or latency.
Support
Last but most important, how is forum support and future dev?
Vaadin Ltd appears to be a very healthy open-source company. They sell add-on products, support, consulting, and training. The company has been growing, hiring more staff, and establishing overseas offices (US, Germany) while their home base remains in Finland (Turku, Helsinki).
The various Vaadin products are under very heavy development with many incremental releases, pre-releases, and soon to arrive Long-Term-Support versions. The regularly publish a road map to their development plans. They also provide regular updates on their business and technical issues in their blog.
The Vaadin Ltd company hosts a very active forums site. Both their staff and other users actively use Stack Overflow as well.
I think you should make this decision depending on the architecture of each, because this is the point where they differ the most.
Vaadin follows the Half-Object Pattern and is therefore more comparable to Eclipse RAP (and ZK) than to GWT. You have basically a server-application and you control it from the Browser. Think of a simple Button, its state is hold on the server and in the browser you see a representation of it. Everytime the Button's state changes, it has to communicate with the server in order to update it's state. So this is true for every widget you have.
I must say that I have not much experience with Vaadin or RAP, but imagine how many states your server will have to juggle when you have many widgets and many users who use them at the same time. This may not be a big concern in the cloud, but maybe on a traditional server with limited resources.
That said, you can imagine that this approach is also not very mobile-friendly. Every state-change results in a server round-trip, but on mobile you might have a poor connection or even none at all.
Here I would clearly prefer plain GWT as it can run entirely in the browser and is also usable "offline".
Your other question was about widgets. It is true that GWT does not provide as many widgets as Vaadin, but there are good Widget libraries out there to supplement the stock GWT widgets. The problem is, you can not start with Vaadin and decide later on to switch back to GWT because Widgets written in Vaadin can not be used in plain GWT. But the other way around works, GWT Widgets and self-written widgets are usable in Vaadin.
I would suggest to start with plain GWT, write your own Widgets with UiBinder, it is very very easy. If you feel you would like to use some more complex widgets, look at widget libraries like GWT-Bootstrap or Sencha GXT, they play very nice with plain GWT.
if you want future dev, go with jsf, honestly. It is not the best pick, but you will be at least vulnerable of dying frameworks.
In our project I have to use Vaadin, I would not have decided so. I prefer ZK (http://www.zkoss.org/) or GWT.
Regarding your questions, as far as I can answer them.
Relatively easy, like Swing. You extend CustomComponent and there you go.
Performance. We have performance problems and problems while programming. The architecture had to be rethought several times because of VAADIN specification. In combination with JPA, to me, it is not a pleasure to work with.
Hard to tell. Of course you read everywhere about MVC, loose coupling, etc. But I personally think you always have some roots from your GUI framework that affect some code below. You cannot simply change the framework as plug'n play. I don't know the details, but probably the lifecyle is already different than other frameworks. So the implementation of Vaadin for the communication with the db for example, as when using FormFactory, will affect your persistence layer which you will have to adjust when using another framework. Simply because of the implemented strategy.
I have no experience here.
Vaadin is big in the community and it seems, many people use it. I experienced that the Vaadin team does a string effort in propagating the framework and also is there to answer questions and help you whereever it can. I appreciate that. The documentation is really good.
I personally think you will have to deeply think about the framework and if it does fit your needs.
Before choosing for a big framework think abou, if you want to
- server side programming (ZK, Vaadin, )
- server and client (GWT)
- using markup language and logic (JSF)
What will be your environment setup, like application server, database, etc?
Even though Vaadin is a good product, I would not use it, if I was free to choose.
Ciao
It's better to choose client-side technology like HTML, Javascript or more advanced UI frameworks like ReactJS, Angular instead of server-side technologies. Server-side frameworks are slow in performance and hard to debug for browser issues.
Background: I have created a CRUD web app using a java based RAD tool called Wavemaker. I am considering developing the app again in a framework that has greater support. Even though I have some experience in development I still get confused by all of the terms. My understanding is that there are languages (C#, PHP, Javascript, Java, etc), frameworks (Wavemaker, Ruby on Rails, Yii, Symfony, Code Igniter, Zend, etc) and editors (Dreamweaver?)?
I outsourced the development of a mobile version of my web app and this was created using jquery mobile, php and ajax. I started using Dreamweaver because I read it had integration for development with jquery mobile and hence I could perform modifications on my mobile app.
I was wondering whether Dreamweaver was a viable choice for the development of a CRUD web app? I used dreamweaver many years ago for the create of html pages and it would automatically create a lot of "unclean" code that made it hard to maintain. I fear that I would put myself in a similar situation here with server-side code.
If Dreamweaver is not appropriate could you kindly suggest a framework that may meet my requirements?
The main things I liked about Wavemaker:
Drag and drop widgets
A lot of the database functions were automatically handled
The main things I don't like about developing with Wavemaker (not Wavemaker itself):
Support: The support generally involves posting to the forums and hoping for a reply that may never come. I would rather paid support over this option which to be fair is offered by vmware but I found it too confusing.
Small number of freelance contractors: Much of the functionality within my app required coding or workarounds outside of the standard features of wavemaker and it is very hard to find a freelance wavemaker developer for help
Ongoing bugs that cause a headache during development
With that being said my priorities are:
Support: great documentation with rapid response to problems (even if this requires a paid subscription)
A large number of freelance contractors available (I guess this means a popular framework using a popular language).
Simple and easy to use (I understand there would be an initial learning curve)
Stable: I won't be running into bugs that hold up my development and need me to wait for the next release for a fix
The ability to incorporate reporting like BIRT reports or Jasper.
Possibly steer clear of Java as I have found Tomcat to be an extra level of complication that it would be great to do without.
Any help would be greatly appreciated.
Thanks.
Dreamweaver was a viable choice for the development of a CRUD web app?
Yes, but with caveats. It still does not produce code that advanced users would consider "clean" but the integration of JQuery Mobile in CS5.5 makes it a good choice for non-coders or beginning coders who need to spin up rapidly and will worry about elegance later.
That being said, if you are outsourcing the design it is likely that the code you get back will be editable in Dreamweaver but not written in such a way as to take advantage of Dreamweaver's built-in behaviors (automatic code writing). Dreamweaver expects to see code written to its specs in order to take over for the user. If not, it is still a great wysiwyg editor and above-average code editor.
But it's not a framework. In your sitution, JQuery Mobile is the framework and any JQuery Mobile developer should be able to step in and run with the project. But if you write big chunks of the CRUD using Dreamweaver, developers may tell you that they will want to rewrite those sections. Some won't care.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
My company is planning on developing a brand new web front-end application.
Some background:
It must "sizzle" i.e. a nice marketable look and feel.
Our development team has no Java experience, with limited experience in Silverlight, Javascript, JQuery or CSS.
Time to market is a factor.
We need to stream large amounts of data from an Oracle database.
It must support 500 - 1000 concurrent users
It will be hosted internally behind a firewall.
We need mapping (geo-spatial) capabilities.
Someone has recommended using GWT instead of Silverlight or Traditional technologies(Javascript, jquery, CSS etc.).
I am not sure if this is the right way to go? A lot of the GWT news is from 2007/2008. It makes me think that this technology is old and maybe dying.
If you had a choice would you choose GWT?
unfortunately two of your statements are mutually exclusive in this context:
Our development team has no Java experience
Time to market is a factor
I'm a Java programmer who has picked up GWT over the last year or so. It's immensely effective being able to write direct to the browser using a compiled language & mature development tools. I can fly through web-development faster than ever before (using ASP, JSP, ExtJS ...).
But, as the other commenters have said: if you've no Java experience you're going to find it a real challenge picking up both technologies (Java & GWT) in a short time. If you do manage to make it to market in a reasonable time I could only imagine the code base would be in very poor condition (since you'd be learning as you go) - which would be a very poor foundation for your organisation's shiny new venture.
There again, you don't have a 'lot' of skills in the other related skills you listed either.
I suspect there's a more effective solution. As some wise old goat project manager said:
I have three variables to delivering your project: time, cost and quality. Pick any two
In your situation, if the organisation wants a quality product in a short time, it's the cost factor that must compensate - your organisation should buy in some interim GWT expertise to give you a sound software architecture and to mentor your team for the next few months. After that you'll be ready to take the reigns, inheriting a quality codebase by 'standing on the shoulders of giants'.
As others have said, GWT definitely is not a dying project. Quite the contrary actually as there are now more than 20 regular contributors from within Google (versus a semi-dozen back in 2008). Wave (despite being discontinued as a Google service, it's still alive as an Apache Foundation project), Orkut, AdWords, Google Moderator and the new (still beta) Google Groups are made with GWT; and parts of Google Buzz and a few other projects at Google are built with it too.
Now as to your choice:
Silverlight is a dying technology. Microsoft made it clear that it now invests in "HTML5": http://www.zdnet.com/blog/microsoft/microsoft-our-strategy-with-silverlight-has-shifted/7834
GWT is mostly a client-side toolkit, but it comes with "high productivity" tools for client-server communications (GWT-RPC and RequestFactory for end-to-end protocols, AutoBeans for easy JSON serialization). With UiBinder, you can easily put to use your web designer skills.
if you're comfortable with JS, then go for it, but then you'd have to choose the "right toolkit" (jQuery? Google Closure?). Otherwise (which seems to be the case), it really depends how much "ajaxy" you need/want to be. I'm a strong believer in "one-page apps", but YMMV, or you can have specific constraints that rule it out. In any case, you'd have to choose a server-side technology.
So, depending on your needs/wants and skills, I'd choose GWT or "some JS toolkit". In any case, you'll have full control over the look and feel (unless you choose one of the bloated players: ExtJS/ExtGWT, SmartGWT or similar; you'll probably have a shorter time-to-market with these, but you'll pay it later, in terms of performance, integration with other toolkits, and look-and-feel).
In the light of what you're saying about your skills, I would definitely recommend GWT (despite your lack of experience with Java); because lack of experience with JavaScript is far worse than lack of experience with Java (you're talking about a "large application", so it's really important to start building things right and/or have tools to help refactoring, which you'll have with Java).
#ianmayo replied while I was writing the above, and I can only second what he said!
GWT is definitely not old or dying! A lot of Google's own applications are developed using GWT. You can download the GBST case study and learn how the global financial company uses GWT to improve productivity and create a rich user experience. You have to know that when you use GWT you automatically use javascript, html, etc. You create a your gwt application in java, but when you compile it gwt creates a folder with html files, javascript code, css, etc...
I definitely recommend it!
In order not to mislead readers with above seemingly unanimous answers, keep objective view in respected stackoverflow, following review expressed exact experiences I had with using GWT. Whether GWT is dying depends on how many new apps will adopt it,Google trend can tell (gwt trend).
Excerpt from https://softwareengineering.stackexchange.com/questions/38441/when-not-to-use-google-web-toolkit
>
I am both good and bad to answer this question - good, in that I've actually used it before, and bad, in that I was quite experienced with HTML/CSS/JavaScript prior to working with GWT. This left me maddened by using GWT in a way that other Java developers who don't really know DHTML may not have been.
GWT does what it says - it abstracts JavaScript and to some degree HTML into Java. To many developers, this sounds brilliant. However, we know, as Jeff Atwood puts it, all abstractions are failed abstractions (worth a read if considering GWT). With GWT, this specifically introduces the following problems:
Using HTML in GWT sucks.
As I said it, to some degree, even abstracts away HTML. It sounds good to a Java developer. But it's not. HTML is a document markup format. If you wanted to create Java objects to define a document, you would not use document markup elements. It is maddeningly verbose. It is also not controlled enough. In HTML there is essentially one way to write
<p>Hello how are <b>you</b>?</p>
In GWT, you have 3 child nodes (text, B, text) attached to a P node. You can either create the P first, or create the child nodes first. One of the child nodes might be the return result of a function. After a few months of development with many developers, trying to decipher what your HTML document looks like by tracing your GWT code is a headache-inducing process.
In the end, the team decided that maybe using HTMLPanel for all HTML was the right way to go. Now, you've lost many of GWT's advantages of having elements readily available to Java code to bind easily for data.
Using CSS in GWT sucks.
By attachment to HTML abstraction, this means that the way you have to use CSS is also different. It might have improved since I last used GWT (about 9 months ago), but at the time, CSS support was a mess. Because of the way GWT makes you create HTML, you often have levels of nodes that you didn't know were injected (any CSS dev knows how this can dramatically affect rendering). There were too many ways to embed or link CSS, resulting in a confusing mess of namespaces. On top of that you had the sprite support, which again sounds nice, but actually mutated your CSS and we had problems with it writing properties which we then had to explicitly overwrite later, or in some cases, thwarted our attempts to match our hand-coded CSS and having to just redesign it in ways that GWT didn't screw it up.
Union of problems, intersection of benefits
Any languages is going to have it's own set of problems and benefits. Whether you use it is a weighted formula based on those. When you have an abstraction, what you get is a union of all the problems, and an intersection of the benefits. JavaScript has it's problems, and is commonly derided among server-side engineers, but it also has quite a few features that are helpful for rapid web development. Think closures, syntax shorthand, ad-hoc objects, all of the stuff done by Jquery (like DOM querying by CSS selector). Now forget about using it in GWT!
Separation of concerns
We all know that as the size of a project grows, having good separation of concerns is critical. One of the most important is the separation between display and processing. GWT made this really hard. Probably not impossible, but the team I was on never came up with a good solution, and even when we thought we had, we always had one leaking into the other.
Desktop != Web
As #Berin Loritsch posted in the comments, the model or mindset GWT is built for is living applications, where a program has a living display tightly coupled with a processing engine. This sounds good because that's what so many feel the web is lacking. But there are two problems: A) The web is built on HTTP and this is inherently different. As I mentioned above, the technologies built on HTTP - HTML, CSS, even resource-loading and caching (images, etc.), have been built for that platform. B) Java developers who have been working on the web do not easily switch to this desktop-application mindset. Architecture in this world is an entirely different discipline. Flex developers would probably be more suited to GWT than Java web developers.
In conclusion...
GWT is capable of producing quick-and-dirty AJAX applications quite easily using just Java. If quick-and-dirty doesn't sound like what you want, don't use it. The company I was working for was a company that cared a lot about the end product, and it's sense of polish, both visual and interactive, to the user. For us front-end developers, this meant that we needed to control HTML, CSS, and JavaScript in ways that made using GWT like trying to play the piano with boxing gloves on
First of all , GWT is not dying technology, its usage increases, and its latest version is 2.2. I am using GWT for 2 years, since version 1.6. Its improvements since them is quite amazing.
Since GWT is client side technology, it does have only positive effects of your application scaliblity feature. Because server side web technologies such as jsf, struts, wicket are server resource consumers, but gwt does not need any server resource to render user interface..
But there is problem for your team. Because your team has no java experience, it would be quite difficult to adapt yourself two new technologies java and gwt.. If you have time to learn , I would strongly suggest GWT.
It takes approx 1 year to become proficient in GWT. Using GWT pays off if you develop an application as sophisticated as MicrosoftOffice or PhotoShop. It makes no sense to use GWT for small and relatively simple apps, IMHO. GWT is a time killing framework indeed, and you have to have very strong reasons to use it. I think that 99% of web apps don't need GWT.
GWT is not dying framework, but time killing framework. It has security issue. You can do easily CSRF(Cross site request forgery) request to the GWT applications. Also Java and Javascript are totally different languages, you can't translate easily. For your productivity avoid GWT.
By day, I am a front-end web developer but in my off time I dabble with other languages such as C, Objective-C, Python, etc. When I first got into web development the idea of web applications was just getting started.
Since then two amazing frameworks have appeared, SproutIt's SproutCore and 280 North's Cappuccino (+Objective-J). SproutCore is being used by Apple for it's MobileMe application and 280 North released 280 Slides. Both of these applications are amazing and they are a testament to what is possible on the web. So the momentum is shifting. Web applications starting to look and act like desktop applications.
So my question is this: should web based applications follow web standards, separation of markup (content), presentation (design), and behavior (functionality) or no?
I am not sure about SproutCore since I have not look at the source code, but I know that if you go to 280slides.com and turn off the JavaScript everything basically disappears. You are left with some meaningless words.
Let me clarify, I understand that web based applications such as 280 Slides is meant to have JavaScript on and not meant to be functional without it but in my day job my main focus is writing clean markup, separating content, presentation, and behavior so that our site and applications can be used by as many people as possible.
It seems like the other people who have answered so far have no idea what you're talking about.
Like me, you've had it pounded into your head to make your web applications as accessible as possible. That is, they should work without scripting and without stylesheets. JavaScript and CSS should only be used to enhance the experience. They should not be required.
SproutCore and Cappuccino are frameworks for front-end development that require the user to have both JavaScript and CSS enabled. Your question is around how we reconcile this with the dogma of the day.
Unfortunately, I don't have a clear-cut answer. I like the fact that SproutCore and Cappuccino (and probably others) are testing the limits of what's possible within a web browser. I also believe firmly that information and services provided on the web should be available to as many people as possible, given the limitations of the technology.
How you approach your solutions needs to be based on a deep knowledge of your user-base. If you're working on an iPhone app, you don't need to worry about traditional web accessibility because the experience is intensely visual. If you're building a web application for a general audience, these new frameworks are probably a poor choice (if you value the widest possible access to your information and services).
Over time, screen reader software is likely to get better at interpreting JavaScript-heavy interfaces, so perhaps this issue will fade. Thing is, something else is likely to "sprout" up in its place.
Javascript is a Web standard — certainly more so than, say, Flash, which was previously (and still often is) used for rich Web applications. In this regard, SproutCore and Cappuccino are giant improvements in my book.
The question here really seems to be how important accessibility is. And that is largely a personal decision based, as Andrew said, on knowing your users. For some apps, accessibility really doesn't make that much sense — 280 Slides is a good example of this. It's a graphic design app that's largely about visual behaviors. It doesn't make very much sense for it to degrade to plaintext. (At least, a text-based app meant to accomplish what 280 Slides does would be really be a completely different thing.)
Yes. It will be difficult at first, but once the codebase matures you will be thankful you followed those rigorous standards.
Edit: An added benefit will be portability to many web-based platform via CSS profiles and whatnot.
The MVC model can be applied just as easily to desktop applications as it can to web based applications. I don't see much reason to distinguish between the two, especially since the line is more blurred in the case of web applications.
I don't know about these particular frameworks, but a lot of web frameworks these days are structured around the MVC model, such as ASP MVC, CakePHP, Ruby on Rails, etc.
Separate as much as you can and it will pay out in the end. When things get complicated and hairy :)
I think they should. Following that type of MVC design allows for changes to be more easily implemented, provides good separation of concern, and is generally easier to understand for newcomers to a project.