What’s the difference between SproutCore and GWT?
Everyone always asks: “What is the difference between SproutCore and GWT?”. If you don’t know, GWT is the Ajax library developed by Google. You write Java code, which is translated into JavaScript for you to run in the browser.
I could go into lots of details about the specific strengths or weaknesses of this or that feature, but the big difference between GWT and SproutCore can be summed up with this quote from their from page:
Google Web Toolkit (GWT) makes it easier to write high-performance AJAX applications. You write your front end in the Java programming language and GWT compiles your source into highly optimized JavaScript. Writing web apps today is a tedious and error-prone process. You spend 90% of your time working around browser quirks, and JavaScript’s lack of modularity makes sharing, testing, and reusing AJAX components difficult and fragile. It doesn’t have to be that way.
In other words: we don’t like JavaScript. It’s not Java and it’s hard. Use GWT instead and avoid learning that language altogether!
SproutCore’s approach, as you probably know by now, is quite the opposite. Embrace JavaScript. It’s a good language once you get to know it. The tedious and error-prone part of it is not the fault of JavaScript, its the natural state of the web browsers and their relatively primitive APIs. But that’s what a framework is for.
Here’s the problem with using something like GWT or any other framework or tool that lets you write in <insert favorite language here> and then converts it to JavaScript: they can’t always get it right.
Every framework, even SproutCore, makes some assumptions about the kinds of problems you will need to solve or how your code will need to perform. When you run up against these limits (and you always will) in a platform that tries to isolate you from JavaScript what do you do? Well you have to write the JavaScript yourself. Only now the problem is twice as hard because you have to figure out how to interface with that super-optimized, totally unreadable code generated by your tool as well.
With SproutCore, if you want to do something not anticipated by the framework, well, write a little more JavaScript. It will be easy to interface with the rest of your app because that is what SproutCore does. Better yet, use one of the many libraries already out there to help you. It feels totally natural and normal to do this because you get to stay in the same platform where you belong.
The point is, any framework that tries to help you avoid learning JavaScript, be it GWT, ruby helpers, or anything else, is fine when you have some relatively simple things to do. But if you want to build apps that really shine in the browser, you need to go native. Use the technologies that the browser is made of and you’ll be far happier in the long run.
And that’s the difference between SproutCore and GWT.
Update: I have great respect for the GWT team and what they have built. It’s an amazing feat of technology and very useful for any Java engineer who needs to add a little Ajax love without learning JavaScript. But for the kinds of apps SproutCore is designed for, we differ on the approach. The purpose of this post is to explain that difference.
I don’t think that’s a fair assessment of GWT, it has many further advantages over manually writing JS code (and yes I do know JS):
1. Speed - by using the compiler optimized code that is remarkably hard to code by hand is generated for you on the fly. Since Java is strict its much easier to optimize and obfuscate code to produce a very fast version that’s suitable for a specific browser.
By upgrading to the new version of GWT all developers got a great speed boost, by upgrading to a new version of a JavaScript library you are more likely to slow down your application.
2. Size - again, you don’t need to download all the “portability layers” since the GWT compiler generates multiple fast versions for all browsers.
3. Reuse - Java IDE’s feature remarkable tools from refactoring to smart searches and navigation. There is nothing remotely like this in the JavaScript world, most Java IDE’s have some limited support for JavaScript but it doesn’t carry the full abilities afforded to Java.
4. Java EE - Java on the server is remarkably powerful (especially Java EE 5+). GWT allows you to serialize your business objects from the server to the client making programming JavaScript as easy as old time client server programming. This IMO is the “killer feature” of GWT, the fact that you can reuse code and algorithms all the way to the browser tier.
“In other words: we don’t like JavaScript. It’s not Java and it’s hard. Use GWT instead and avoid learning that language altogether!”
I’m trying to figure out if you’re being ignorant or disingenuous here.
The former would disappoint me in that it means you don’t understand the engineering tradeoffs of deciding to leverage the static-provability afforded by a judicious choice of source language, but the latter would mean that you do not want others to entertain and appreciate that tradeoff, and thereby are willing to distract them by boiling it down to absurdities.
I think it’s the former, though, because you go on in the next paragraph to ridiculously claim that a source language is not responsible for the engineering tradeoffs that it embodies.
I guess I’m happy that you’re being candid but misinformed.
This post stinks of arrogance. GWT creates code faster than you could ever write by hand, so is more “native” than your beloved framework.
And no, they can’t always get it right. Do you not have a bug tracker? FGS!
Heres some more:
“With SproutCore, if you want to do something not anticipated by the framework, well, write a little more JavaScript. It will be easy to interface with the rest of your app because that is what SproutCore does. Better yet, use one of the many libraries already out there to help you. It feels totally natural and normal to do this because you get to stay in the same platform where you belong.”
—-
With GWT, if you want to do something not anticipated by the framework, well, write a little more JavaScript. It will be easy to interface with the rest of your app because that is what GWT does. Better yet, you can create javascript in typesafe libraries (see gquery for example).
Have you even used GWT? We use 3 popular javascript libraries with our project with much success.
Fud alert!
I’m still not sure you quite grok the full GWT story. I know these type of things don’t mean very much over the internet, but, I’ll bet you bushelful of sprouts that in a year or two, the fastest, most intricate SproutCore applications will be written in GWT.
Take a look at GWT-Ext (not to be confused with Ext-GWT) - It’s a lightweight GWT wrapper around the excellent (if schizophrenically licensed) Ext JS framework. After a GWT wrapper was written for it, a number of incredibly robust applications sprang up at a speed that surprised the original framework creators.
Saying that you use GWT so that you can use Java instead of Javascript is like saying you use Objective-C instead of assembly because you don’t want to learn machine language.
First, well no-duh, who the heck wants to learn 5 different versions of assembly code. I mean, there’s PPC and AMD64 and those funky Intel SSE extensions and …
Also, you don’t write in assembly because, it takes forever to geat anything big done, the tooling is terrible, and, unless your one of the smartest people on the planet, the compiler writes better code than you do.
That’s the same thing with GWT. This is not hyperbole and not hocus-pocus in the future stuff. Right now, the GWT compiler can perform both standard and some novel compile time optimizations that make the resulting Javascript smaller, faster and more manageable than *is possible* with hand written single target code.
I’ll go so far as to say that the incoming language for GWT doesn’t really matter. Since Browser Javascript is a ’source code as payload’ language, you are always stuck with a full AST parse and interpret (or JIT compile) in the browser at page load. One could think of GWT as a static preprocess step, allowing optimizations that would be CPU cost prohibitive at page load. Like the GCC backend, one could imagine starting with Python, Ruby, or even Javascript, and end up with browser JS interpreter optimized code.
From here I won’t even get into the tooling, static analysis and multiple target benefits. Needless to say that you started out saying you were going to define the difference between SproutCore and GWT, but go on to compare the GWT class library to the SproutCore framework.
I like SproutCore the framework, now just run it through the GWT compiler to really make it good and you’ll really be rocking.
I am completely aware of the engineering tradeoffs re statically typed languages. And I don’t know if GWT can produce code faster than I could ever write by hand or not. But that isn’t the point.
The point is what will produce the higher quality application. I think the evidence says that apps built with the “native platform” they target generally turn out better. Just look at any Cocoa app vs any Java Swing or Qt app. User’s notice.
That said, maybe you are building an app that lives mostly in the server and just needs some Ajax here and there. Maybe the advantages of not having to learn JavaScript surpass the drawbacks. There are lots of reasons to use GWT.
But if you want to build a real high quality app in the browser, I think avoiding JavaScript is the wrong approach.
–
The idea of having a compiler that can produce optimized JS is a good one. And I hope in a few years that is possible. I do think we will need support from the browser vendors also before that can happen since developers need the code they see in their debugger to reasonably approximate the code they wrote in their text editor.
Thanks for the thoughtful comments guys.
Comparing Swing/QT to Cocoa is comparing a lightweight rendering toolkit to a heavy weight toolkit.
GWT does no rendering and can/does invoke any JavaScript code making it more like Cocoa than like Swing.
No one ever said avoid JavaScript, we are saying: properly encapsulate code to gain the benefits mentioned above. You can still use all your old JavaScript libraries without a problem under GWT.
Another GWT benefit I left out from my previous comment is the debugging/hosted mode that allows you to debug GWT code in Java mode and seamlessly pause on client/server breakpoints… This is an amazingly helpful debugging tool and makes features like the firefox JavaScript debugger look like the stone age.
The discussions remind me a lot back when Fortran was first introduced. It could never be faster than writing machine language. By now both are not used anymore and OO languages took over.
Sproutcore has its merrits, but the developers remain the limitation here. It might not even be the developers but time is always a constraint, and there Java/GWT and Eclipse really shine.
Just writing off GWT since it is for sissies that do not want to learn JavaScript. I know JavaScript, I’ve used it in big projects where I had to handcode a lot of AJAX things. Its just a nightmare because the tools are not there and its hard to even find a developer that knows how to leverage the language in a powerfull and maintainable way.
Sproutcore is just a nice JavaScript library, nicely designed that I admit, but the tools are not there and the developers neither.
Eeeek
Still missing the forest for the Sprouts!
The use case that GWT would be horrid for a java engineer who ‘just needs to add a bit of ajax here and there’
It has a pretty large setup cost of project building, base download, etc. It’s sweet spot is for super-rich, intricate, complex, browser side applications.
But, maybe this will help get you over the grok barrier. I am planning on writing an application in GWT that uses SproutCore as it’s rendering library. This would involve creating a light weight SproutCore->GWT bridge layer. In GWT 1.5, these have become super-simple. (Anyone else on board?? Send email to amalter (at) illegalcheese.com)
Perhaps after that we can come up with something like JPetStore or any other benchmarking type application and we can have a friendly contest in which you write your business logic in JS and render in SproutCore and I write my business logic in Java->GWT->JS and render in SproutCore.
Then we benchmark. The bet I’m willing to make is that my app is
a) Faster total run time
b) Smaller payload judged by *gziped size of js file*
Anyway, the reason I soooo want you to grok this is because I really think that SproutCore could be *the* rendering library for GWT. For a while it looked like it was going to ExtJS, but everyone is hands off after some very nasty licensing in-fighting. Also, to your credit, none of the other Ajax/JS guru’s believed in the potential of GWT at first either, but just about all of the ‘big names’ have come around. (I mean, really, how long can you argue for writing in assembly language)
Don’t be surprised or alarmed to see some sprouts growing in the GWT garden, it’s a complement.
Charles, you can’t use the SWING/Cocoa comparison with GWT/JS here. Swing runs within a VM and Cocoa isn’t. GWT compiles down to JS, the same JS stuffs that SproutCore uses, no VM that controls the GWT-JS.
You can also write JS native code in GWT. This concept is exactly the same like writing C/ASM for kernel code: you still can write ASM snippets here and there within your C code.
Now, using your analogy of Swing/Cocoa, you’re saying that all OS/Embedded devices would be much better off to be written in pure 100% ASM instead of C.
At first, I doubted GWT. But once I used it, get used to it, feel the benefit of it, I don’t see why I should write JavaScript anymore unless if the server-side framework dictates me to do so. For now my job requires Java for server-side, so I’m good with GWT.
Charles, take a look at Lombardi Blueprint demo if you want to see GWT in use for the “High Quality Web-App”. Also take a look at GWT-Ext (the native ExtJS written in GWT, not the wrapper like the Ext-GWT).
You can’t do these with SproutCore. Well, technically you could (make a widget, draw some cool stuffs), but you wont’ beat their speed for sure.
By the way, Swing is getting better and better. I see more companies are writing client-side desktop using SWING. It may not be as slick as Cocoa but users seem not to mind as long as they can use the software and it’s easy to use it. Check out Zimbra Desktop Client and OpenProj free download. Both have serious users.
@Adam Malter, If you build an SC app through GWT and it is both smaller and faster, then I will indeed become far more interested in GWT.
@Ed: Thanks for the thoughtful comment. I understand the argument that writing in Javascript is like writing in Asm, but I don’t agree. JavaScript is very different from Java conceptually. If you were working directly inside of JavaScript, the strategies you would use to solve a problem would often be completely different than what you would do in Java. A compiler/converter can translate your code, but it can’t understand your design strategies and convert them also.
Like I said though, if someone would like to create an Apples-apples comparison, building Gwt -> SproutCore, I’d go along with it. My experience tells me that those who work natively in their target platform will come out on top, but I could be convinced otherwise if GWT produces code that is faster and just as easy to debug and maintain.
Charles,
I really like your style. You seem to be able to take things on board when you are wrong, which is great and speaks volumes for your frameworks future.
“The idea of having a compiler that can produce optimized JS is a good one. And I hope in a few years that is possible. I do think we will need support from the browser vendors also before that can happen since developers need the code they see in their debugger to reasonably approximate the code they wrote in their text editor.”
This is GWT. Now. Right now. Go read about it’s performance, Bruce Johnson did a talk about why it’s faster than what you can write manually.
In our application it was doing over 80 compilation passes (sloowww) but worth it. Our app is ~10x faster to respond then your demo on the same computer.
Notably, with GWT you also have the full power of the IDE when debugging, you don’t need to go to firebug. What this means is that while you are developing you can use your normal debugger (e.g. eclipse) to debug your javascript application.
So what you think may be here in a couple of years, with support from browser vendors has been in use for a year or so.
Also, your comment about swing vs cocoa is completely off target. Swing draws its own widgets to the screen independent of the OS. GWT simply provides you convenient api’s around the DOM so you can create a Button, Table, Tree, CheckBox etc and style them as normal html.
Creating an application that looked identical to your demo wouldn’t take long assuming you could reuse your styles. So do you see your point was wrong? GWT doesn’t provide its own rendering, it uses normal HTML + CSS, just like every other framework. It’s up to you to style as you want.
Now what would be nice is a great default style like sproutcores
at the moment its very googly-minimal.
ben, can you point me to this app that is faster than the demo? I’d love to check this out for myself.
I could not agree more. GWT was suggested for a project that I was on in 2006. We decided not to go with it because we knew that our needs would never be in lock step with what google would be able to release in every GWT iteration. I applaud the effort and the results that it has had, allowing a few JS Engineers create interface components that are used for a ton of Java apps at Google. For the rest of us though, that don’t have access to a JS framework team, we should have access use the raw materials.
There are way too many misunderstandings in this blog post, and some of the follow up comments, with respect to understanding what GWT is all about. It’s the same mistake every newcomer to GWT makes, which is to assume that GWT is just about widgets and “hiding” yucky JS/Browser issues. How many times must the GWT team repeat that they chose Java not because they hate JavaScript, but because *static compilation works better with Java* There are a number of people trying to build compile-time tools for pure Javascript, and it’s just a lot harder to do JS optimizations at compile time, vs runtime.
@8, Adam, watch my Google I/O presentation (GwtExtreme) on GwtQuery, my jQuery clone, in GWT (http://youtube.com/watch?v=2ScPbu8ga1Q), to see the benefits of GWT compilation.
These is simply no way you will achieve a faster than startup time than GWT, period.
GWT aggressively prunes and obfuscates JS far better than any JS minifier/packer. I obtain a FACTOR OF ONE HUNDRED reduction in code size in my example.
It also prunes the prototype chain by promoting methods to static as needed based on app usage. Are you going to measure your app’s callsites to class foo and decide that foo’s subclasses are never used, and therefore can be made a top level function? This has to be done on an *app by app* basis. GWT detects when non-polymorphism is used and removes it. Thus, you don’t pay for abstractions you don’t use.
GWT inlines non-polymorphic methods as well, further improving performance.
GWT can package *all* of your resources: css, images, even SWFs into the JS that is downloaded itself, thus removing HTTP requests which are the biggest startup-time delay. It even auto-generates CSS Sprites, so that images are packed into a single image.
GWT permits perfect caching, by naming its outputs according to cryptographically strong hashes, and then tells the client to cache them forever. A new compilation is only downloaded if something actually changed, by the bootstrap script.
The GWT widget library is only a tiny part of the GWT platform, the biggest benefit of GWT is the compiler and hosted mode. While SproutCore could be used to render widgets, it would eliminate many optimizations possible, because the SproutCore classes become an event horizon for the compiler.
What I don’t understand is why every new framework proponent seems to start off comparing their framework with GWT and trying to attack GWT. GWT is hardly the dominant AJAX platform, you should be going after ExtJS, jQuery, Dojo, etc I think you’re picking the wrong fights.
GWT is not for everyone, that’s for sure, and there are tons of people using Javascript as their primary language who don’t want to use Java. Fine. But there are lots of other people who want the fastest and smallest app possible, who want Java debuggers and IDEs, and JUnit, and painless integration with Servlets, and a first-class package system, and for that tiny minority :), why assail their choice of GWT?
I say, let a thousand flowers bloom, and if you want to gain more converts to SproutCore, go after those pesky Javascript programmers hooked on Dojo and ExtJS.
@charles:
I’m getting the sense that it may have been premature for you to attempt to contrast SproutCore with GWT, since some of the things that you’re saying don’t seem to line up with the realities of GWT as it exists at the moment. Ben already pointed out that the debugging you desired is here right now. In addition to that, your point about applications being better when they are “native”, and that GWT is somehow “avoiding javascript” is obviously off-the-mark too: a compiled GWT application _is_ javascript running in the browser, hence all of the widgets that you see are build of the same DOM objects that would exist if the source language had been javascript. It’s like saying that a C program, compiled to x86 instructions, is somehow less native than an x86 assembly program on the same machine.
I think SproutCore looks great. I guess what I was hoping for when I first came to this article, was a higher level of discourse: something that started by acknowledging what GWT was trying to accomplish with respect to avoiding the pitfalls of writing in javascript, but then went on to claim that those shortcomings could be mitigated by other means than changing the source language (design patterns, idioms, …). That would have probably been better received by those of us who know better than to accept your characterization of GWT as being something for people who think learning another programming language is too difficult. That’s just insulting, and got us off on the wrong foot.
I’ll keep my mind open for a “GWT vs. SproutCore redux” if you want to try a higher approach.
“If you were working directly inside of JavaScript, the strategies you would use to solve a problem would often be completely different than what you would do in Java”
I’m not familiar enough with JS to answer this. Could you point a simple example?
To me, if you want to do DOM manipulation, it’s still a DOM manipulation regardless whether you use GWT or JS. GWT also wraps JS objects by the way.
“A compiler/converter can translate your code, but it can’t understand your design strategies and convert them also.”
Still saying the GWT/JS approach is different to C/Compiler/ASM ?
I’m sure he means using closures, & etc. The flip side, however, is also true. Design patterns that require strong typing are available to GWT programmers. For example, I use Visitor all the time in my GWT project to bind UI widgets to object subclasses.
I’m very disapointed by your demos. Not very rapid, poorness of the list of widgets. GWT demos are faster and not so poor on widgets.
The advantage of using a framework/tool is not to have to develop lots of widgets. What is the advantage of using Spoutcore on this point?
I don’t want to say something about the architecture choice between GWT and SproutCore, both are valid. It depends on the context of the project, and all had been said.
But I want to mention 2 points :
- You said using native JS is faster than using GWT. It’s a nonsense GWT is native JS, it produces native JS.
- You said “if you want to do something not anticipated by the framework, well, write a little more JavaScript” but in GWT if you want to do something not anticipated by the framework, well, write a little more Java and/or JavaScript (see the large community on code.google.com) What is your advantage on GWT ?
Finally I think that the biggest disadvantage of JS Libraries (all) against GWT is the lack of IDE.
By the way I will continue using JS and GWT depending on projects.
@charles: What these folks are saying about GWT is quite true, both in terms of the state of GWT optimizations as well as our actual product philosophy. GWT’s goal is to provide lots of leverage, not “insulate you from JS”. In fact, JS experts tend to be among the very best GWT developers because they can apply their deep knowledge of the DOM, CSS, and JS within the context of GWT optimizations for a very powerful combo.
If you ever do consider a “GWT vs. SproutCore redux” post, I would highly recommend viewing Ray’s “GWT Extreme” talk from Google I/O, as well as three others ones:
(Why GWT actually is faster than handwritten JS for non-trivial code)
http://sites.google.com/site/io/faster-than-possible-code-deferred-binding-with-gwt
(You can do “regular” DOM programming in GWT)
http://sites.google.com/site/io/surprisingly-rockin-javascript-and-dom-programming-in-gwt
(You can indeed build sophisticated, high-performance apps with GWT)
http://sites.google.com/site/io/using-gwt-to-build-a-high-performance-collaborative-diagramming-tool
If you can make it through those four videos, I would be eager to hear if you still stand by your claims in this original post.
I’m late for the party - anyway, let me throw in a few remarks. Compile-optimizing JS is a good idea, but there are other projects besides GWT that work on that, e.g. qooxdoo which does JS-to-JS compile-optimization, packages, variants and such. To say JS is the assembly language is a bit unfair (to both JS and assembler), I think on the language abstraction curve it is on par with Java, tooling issues not withstanding, but that is also going to change if you believe Google’s Steve Yegge (http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html). The true assembly in this case would be HTML and DOM. Since people love preferences in programming languages I think there will be co-existence of a couple of implementation languages for web apps. Good integration with hand-written JS code for the finishing tweaks is of course a plus but can probably be achieved by any framework with a bit of effort.
The question JS frameworks should ask themselves is: How long will it take Google to carve out a solid JavaScript(!) API that will be used internally in their GWT, but can also be used natively like any other JS library?!
Disclaimer: I am a GWT developer
A couple of points that I don’t think have been addressed:
- your photo demo doesn’t work in IE. When I first tried to write a moderate-complexity AJAX app in JS (using prototype/Rico), I also had a lot of trouble getting it to work cross-browser. With GWT, for the most part it just works since the library already has browser-specific implementations (as others have mentioned, unlike most JS libraries you only get the one you need instead of all the different implementations and run-time selection code) so you don’t really have to worry about that except when CSS styling your app (and we have some help coming there as well).
- many of the things that make code maintainable make it slow in the browser, as do many of the advanced JS features. GWT allows you to write your code in a fashion optimized for development and maintainability while what the browser sees is optimized for download and execution. Having separate source and target languages makes that possible (note that you cannot safely perform complete dead-code elimination and obfuscation for arbitrary JS [if you restrict what features you use you can] as you have to essentially execute all possible paths through the code to know what it will or won’t use).
Your argument is specious. It is equivalent to saying we should only code in assembly language as that’s what C will be compiled into anyway. You can write in C and invoke assembly language subroutines. You can write in GWT using Java and invoke Javascript functions. GWT is a great tool for some RIA web app’s which makes it especially easy to interact with server side Java libraries (via GWT services).
I’m not very familiar with the Sprout framework but if that’s what Apple is using for their new mobile-me web applications, it looks like it has a lot of potential for a nice GUI interface. My vote goes to using Sprout Core as a library for GWT development. We would get the best of both worlds, nice GUI (SC) and all the advantages of GWT already mentioned in this thread.
Little off topic: for now I’m exploring the gwt-ext for some development but the thing that worries me with that is how long will that last since they can only use the last version of the extjs library that was LGPL and I think that will not be supported with new browser updates any more. Sure, you can create a great lookin/fast/cross browser web app with gwt-ext now, but will it run in the next firefox?/ie?/safari?
hi,
Why do you consider Java as a better choice then JS because of the maintenance reason? because it’s dynamic? it’s just excuse.
after small research i found SproutCore very interesting. to be honest i don’t know why. maybe because i just feel good when using it (similar fun to ruby) - programming GUI is fun and results are very good (i’m productive).