Roger has posted 6 posts at DZone. View Full User Profile

The Google Full Monty: Chrome + Canvas + Gears + GWT + App Engine

09.06.2008
| 13303 views |
  • submit to reddit
Me thinks Google Chrome is the most significant and worthy app that Google has produced since Gmail. It's remarkable on its own merits.

However, Google is actually establishing an entire stack. Let's list it from the client tier toward the server tier:

* Google Chrome
* Canvas
* Gears
* GWT (for development language and tools)
* Google App Engine

Yip, this is definitely a Full Monty stack. When taken altogether, they make for a rather remarkable web development stack. Any developer can grab these items and start building software. Google App Engine is available in a developer download that can be installed on a local server. It's all free and mostly open source. Ultimately Google App Engine service will cost of course, but if you architect on this stack, that service should be scalable on a cost basis that is pretty much linear.

What do folks think?

Does this pretty much define the web computing platform stack for the next 15 years?

Is Google positioned to have a strong-hold on developers' mind share comparable to that which Microsoft has had via Windows?

Because Google will be sifting information at a much more intimate level than Microsoft ever did, will they truly remain a company that does no evil?

Is it possible to possess the information reach they have and not succumb to evil?
Published at DZone with permission of its author, Roger Voss.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Geertjan Wielenga replied on Sun, 2008/09/07 - 8:41am

Me thinks everything Google does is geared towards discovering what my personal proclivities are so that Google can sell that data to those who make profit from that knowledge. Me thinks that Microsoft's upcoming browser, which will let the user erase his/her footprint on the web, is scaring the sh%$ out of Google. Me thinks Google desperately needs a browser that it alone has control over. Me thinks Google is the Big Brother George Orwell would have written about if he had written 1984 today. Me thinks that explains Chrome.

Jess Holle replied on Sun, 2008/09/07 - 11:35am

I guess I have a little less Orwellian take on this.

Google needs the HTML+JavaScript web application model to succeed over alternatives -- as it is the most easiest for them to wedge advertising into.  There are alternatives for applications arising, from Adobe Flex/AIR to Silverlight to JavaFX.  It seems unlikely Google really wants any of these to succeed in any major way as they don't seamlessly dovetail with existing advertising models that they and their customers favor.  They also represent a disruptive step in general from the HTML+JavaScript model they and others are using today -- and do not lend themselves to a graceful degradation within the same single technology for clients without appropriate capabilities.  On the flip side, the HTML and JavaScript model is hampered by the browser morasse that exists today.  Thus I believe Google decided that they needed to help pave the way forward for the technology model that is most suitable to their existing advertising model and presents the lowest possibility of disruptive changes to it.

Chrome also allows Google to provide more compelling deployments of their own applications (Google Docs, etc) to customers willing to use their browser.

This to me explains Google's motivation for Chrome.

The more interesting question is what Chrome really means for the rest of us.  Sure, it could provide a compelling browser platform in cases where you can actually target it, but in most cases one has to support all browsers with significant market share -- at which point Chrome offers little to the application developer unless/until its existence pushes other browsers to add the same features.  In the long run it may do just that (and I believe this is part of Google's plan -- to jumpstart improvement by all browser producers) and then it will be much more significant to the rest of us.

In the short term, Gears, etc, are even less apt to be installed on your end user's machine than a suitably recent Java Plug-In, so I don't really see a compelling advantage.  Yes, the Java Plug-In has had (numerous) issues in the past, but the Java 6 Update 10 Plug-In is really quite nice and almost released (it's as released as Chrome is, being available in Release Candidate status now).  It thus seems unfortunate that so much effort is going into re-inventing the wheel to get JavaScript to do threading, client state, etc, etc -- when the Java Plug-In has offered this for years.

John Denver replied on Sun, 2008/09/07 - 10:20pm

Im totally agree with Geertjan, Google is the real Big Brother and is scary of Microsoft browser and Microsoft still have the 70% market share of browsers?, So for Google is a bad move of Microsoft so with that Microsoft still control the monopoly and wants to crush/kill Google.

But Google made Chrome for control and fight back Microsoft thats all, Google it is a International compny as many companies with their own interestes, they dont care the user, they care by my self it is a business, they are another kind of Monopoly the new one, they want to control the Internet somehow.

 Rember this, if you control the API, you control them all.(Chrome+Canvas+Gears+GWT+AppEng, Think of mind share thousands of programmers using Google API, that is scary, it is a new control).

Welcome to the Big Brother and the New Monopoly for the Internet.

2c.

 

Ray Cromwell replied on Mon, 2008/09/08 - 12:23am


That's a pretty silly bit of hyperbole. Chrome == WebKit + different skin and faster Javascript JIT. Canvas is not Google's API, it was invented by Apple, and is not owned by no one, but part of HTML5, and implemented by every browser except IE (ditto for SVG). Canvas is not a Google API.  Gears is no longer called "Google Gears" for a reason. Google no longer controls it. It is developed in the open, and completely open source. Google Web Toolkit is also open source, anyone can fork it.  Finally, Googles hosting environment (AppEngine) is such a ridiculously small percentage of the worldwide market, and promoted in a way that lets people easily leave the service if they have to, that I hardly believe it deserves the scaremongering befitting it. The APIs being named here are not Google specific, and not really dominant. What's Google controlled proprietary API that is dominant? Maps. AdSense. And even with maps, there is still an openness with KML. So in my opinion, simply stringing together a list of Google APIs and scaremongering about them is not a way to make an argument.  

John Denver replied on Mon, 2008/09/08 - 7:29am

Apple is propetary and Apple wanted and want to create a monopoly, market share, Power right?, they are using also open standards but they could be a monopoly and everybody knows it.

Business/Capitalist doesnt care to help people they care about Power, Money. This gives a lot of power to Google even using Open standards and Opensource model, they know their game. First is crush Microsoft in the deep and then take the control and you have a new Internet monopoly, yes yes using open source model and standards, for some people that is good we will live in piece with open standards but for others nope because we will have Big Brother watching our ass. So get the point?.

Control the API(means developers, developers,developers not the tech api) and you control them all, The new developers of the Internet but History repeat it self.

This is not an insult but people like you seems is very easy to wash your mind, really watchout.

Regards.

 

Ray Cromwell replied on Mon, 2008/09/08 - 2:50pm

 

You're missing the point. Apple couldn't control the API anymore than Microsoft controlled XMLHttpRequest. Short of harassing people with patents,  they couldn't control it, and now they have lost control. The reality is, the OpenWeb/HTML5 people now dictate the defacto standard of what makes it into everything except IE. All browser vendors add their own extensions, and developers are free to use them, and in many cases, libraries are written to abstract away these proprietary differences.

Google cannot control Chrome now, for multiple reasons. First, it's based on WebKit which is already open source. Secondly, they released Chrome itself as open source. At best, Google could control a single fork/branch of Chrome, but if they start acting evil, people will just fork it.

The analogies with Microsoft don't hold up. There are far too many people working at Google who give a damn about ethics and doing things right, I know many of them.  Chrome is not an attempt to take control of everyone's browser and steal all your privacy. It is an attempt to improve the web, because the better the web is, the better Google's bottom line is.

 

Sometimes a win, can be a win-win.

 

 

Roger Voss replied on Mon, 2008/09/08 - 2:50pm

After I posted this, it dawned on me that there is a bit of a technical hitch in my qualification of this combo as a complete end-to-end web app solution stack.

When I last worked with GWT, making an async RPC call resulted in GWT generating some stub for the server side that was Java servlet centric.

Well, Goole App Engine is programmed in Python.

So it looks like GWT needs to be subtracted from this stack, which leaves the stack without a RIA solution.

Unless GWT 1.5 now does something different per implementing async RPC calls on the server tier...

Ray Cromwell replied on Mon, 2008/09/08 - 4:01pm


You don't really need RPC calls. While they are nice, they are most powerful when both sides are running Java so you can debug both client and server with your IDE's debugger. However, they have the downside that they can easily lead people to a fall sense of security, sending down huge serialized object trees to the client and vice-versa without thinking about repackaging stuff for the wire. If you look at the GWT groups, one of the most frequent questions is someone with a J2EE app attempting to integrate GWT and serializing too much data, or, trying to send down Hibernate collections. Too much serialization can also hamper GWT's code pruning leading to bloated code. GWT 1.5 makes working with JSON a lot easier, and JSON is really the defacto wire-format for objects these days. It is possible to make a tool to generate JSON serializers/deserializes for POJO DTOs in multiple languages, but it's not neccessary.   

Roger Voss replied on Mon, 2008/09/08 - 4:41pm in response to: Ray Cromwell

So to invoke an alternative, non-Java, server-tier service, would a GWT programmer do an XmlHttpRequest() in JavaScript, wrapping that in a Java class method, ala JNI style?

Jay Spring replied on Mon, 2008/09/08 - 5:32pm

for the next 15 years?

 

have you even written a sample app that even uses your full monty stack? heck, when does year 1 start?

Ray Cromwell replied on Mon, 2008/09/08 - 6:48pm in response to: Roger Voss


No, GWT already provides an API around XmlHttpRequest so that you don't need to be exposed to it. See the com.google.gwt.http.client class.  You can also use FormPanel (see my blog at http://timepedia.blogspot.com) for cross-domain POSTs using the window.name trick. Finally, you can inject SCRIPT tags and use the new GWT 1.5 overlay types to interpret the resulting JSON inclusion as a Java type. -Ray 

Ray Cromwell replied on Mon, 2008/09/08 - 6:48pm in response to: Roger Voss


No, GWT already provides an API around XmlHttpRequest so that you don't need to be exposed to it. See the com.google.gwt.http.client class.  You can also use FormPanel (see my blog at http://timepedia.blogspot.com) for cross-domain POSTs using the window.name trick. Finally, you can inject SCRIPT tags and use the new GWT 1.5 overlay types to interpret the resulting JSON inclusion as a Java type. -Ray 

John Denver replied on Mon, 2008/09/08 - 8:51pm in response to: Ray Cromwell

Maybe you are right but for me the Stack kind of sucks, GWT generate all the code for me and I think is a big mess, I dont like code generators and It is a client side Tech, I prefer to have control of my code and if I do Ajax it will be on the server side for security reasons.

AppEngine when it was launched I was very exciting, Im also Python programmer and I tested it but I didnt like all the policies, To small the resource for use each app right now, I could pay now for that service so I could have more resource and less constraints but as all Google projects still in Beta or Preview, I cant do anything right now with it.

Gears I dont use it, I prefer Adobe Air/Flex or Java/JavaFX JRE6_10 and the HTML/WebKit yes is open standard and I use it.

Google Chrome I think means a lot of power to Google or You could be right nobody knows or really maybe Google just plain sucks because all their projects are previews and playing around making hype, The only good at Google still right now at best it is the search engine and ads but even in that lately Google begin to sucks, all my search results ware better before and it comes a lot of crap so even the Google searches are not so that great as before. Saying that maybe we dont need to worry about Google and Chrome?.

 

Regards.

 

 

Roger Voss replied on Mon, 2008/09/08 - 11:13pm in response to: John Denver

[quote=alpha512]

Maybe you are right but for me the Stack kind of sucks, GWT generate all the code for me and I think is a big mess, I dont like code generators and It is a client side Tech, I prefer to have control of my code and if I do Ajax it will be on the server side for security reasons.

[/quote]

 

Boy, reading that paragraph caused me to all of a sudden slip into a worm hole and emerge back in time circa the mid 1980s. I was discovering the shear wonder of programming the Mac Toolbox in this high level language, Lightspeed/THINK C. Before then, to craft performant Mac apps that could run in the meager memory, Motorola 68000 assembly language was really the way to go. Pretty much the same story over in MS-DOS land. The real programmers looked on disapprovingly at us folks that dabbled in high level languages like C. For if you dumped the code that was generated, they themselves could write assembly that was certainly much tigher.

Gee, history may not exactly repeat but it sure as heck does a good ryhme.

--Roger

"Let me get right to it by lobbing some grenades: I recognize two arch evils in the software universe – synchronous RPC and remoted interfaces of distributed objects."

Ray Cromwell replied on Tue, 2008/09/09 - 12:07am in response to: John Denver

 It sounds to me like you haven't had much experience with GWT. First of all, to say you'll do "AJAX on the server side" which seems to be a contradiction in terms, or it sounds like you'll be generating code from the server to run on the client, which you said you don't like. But as for code generation, GWT isn't a mere Java to Javascript translator, it is a full fledged compiler  which will usually generate code faster and more compact than would be productively written by hand. (see my GWT Extreme presentation here: http://www.youtube.com/watch?v=2ScPbu8ga1Q The reason for this is several fold: 1) hand written JS that is maintainable uses lots of methods, prototypes, and closures. GWT inlines as much as possible, shortens prototype chains, and devirtualizes method calls. The result may look like a "mess" to you, but it'll startup much quicker and run faster. (moreover, GWT in PRETTY mode produces code that is not "messy", in fact, I routinely step through this code) 2) GWT includes a very aggressive optimization architecture called Deferred Binding which allows the compiler to perform multiple optimization passes specialized for multiple scenarios.  3) GWT reduces the number of HTTP requests in an app, by doing CSS sprites on steroids, automatically. Images, CSS files, even audio, can be inlined into the Javascript itself. And that's just scratching the surface. There is also the huge benefit of using the existing Java tool chain, IDEs and debuggers, build tools, unit test frameworks, code coverage tools, and on and on. People who write non-trivial AJAX apps, on the order of something like Gmail, Docs, or other full-fledged applications, tend to need tools like GWT to cope with unwieldly Javascript. If they're not using GWT, they invent their own compiler or framework, just like Apple did with SproutCore, or Google with their JSCompiler, or 280Slides with their Capuccino framework.  I'm have no desire to get into a debate about Google's many great products, but I find it ironic that if Google produces a product and it doesn't "dominate" than it sucks, but if it does dominate, then it is evil. There appears to be no room for Google to release things which are very useful to the public at large, but don't result in proprietary control.  Google makes enough money that funding a couple of engineers to work on a Javascript VM and skin for WebKit doesn't seem like a huge sacrifice.  

Ray Cromwell replied on Tue, 2008/09/09 - 12:15am in response to: Roger Voss


Roger,  I think you'll find two things: 1) Given enough effort, one can always beat a compiler (hence, the Full Employment Theorem for Compiler Writers), the question is, is the effort worth it from a productivity standpoint. The "macho" programmers may think writing 100% of the code with 100% control over everything is great, but the reality is, for most applications (save, realtime or embedded) it's a complete waste of time.   Secondly, I think you'll find that the people who protest most loudly about compilers end up producing code that is suboptimal and more error prone. Sometimes because they spend less time figuring out more efficient algorithms and more time shaving cycles, but also because facilities in higher level languages tend to free the programmer from making common mistakes.  Consider C, most people these days could not produce a non-trivial app that has a higher sustained functional unit utilization on the CPU than what a compiler could. CPU pipelines and memory hierarchies have gotten alot more complex.   Personally, if GWT could take Scala or Haskell as input, I might even be using those.  

John Denver replied on Tue, 2008/09/09 - 4:17am

This is my story with GWT, I was very happy Google introduced GWT, I download the kit and the plugin for eclipse I said wow it will rock!. The Android thing too also was similar experience.

When Im programming struts I create every class, every xml file to know exactly my project how it is growing and have a good picture of it so I was thinking I can do that with GWT I will let the IDE create the template for me the entry point and that and then code some event handlers and compile and see the result.

What it happend is I compile and for my surprise "What the heck is all this!!", It is an abomination all this html files and javascript files and this I will deploy? and the deploy and configuration it was a nightmare. At that moment I delete complete eclipse with the GWT SDK. Then I got Andriod and that is another disapointed story, And all with Google products has beed disapointed, thats why I dont like anymore. Yes they spend money for create some opensource products and pay good engineers but I think that one it is for the taxes discount or something(I dont know the term in english but you get the picture they use some services so the goverment give a discount for taxes).Me Im still thinking all this is for Google grow more the Hype Machine.

Ray this is nothing against you, nothing personal, it is just my opinion.

Regards.

John Denver replied on Tue, 2008/09/09 - 4:46am in response to: Ray Cromwell

About the history of optimize a C Program it is different than GWT,  In that time you could write the performance parts in assembly inline or in another file and recompile but that step it was optimization and what it produces a simple native binary file(an exe file), for deploy I just copy the exe file and thats all in msdos.

GWT it is a mess of web application and lots of html and javascript files how the heck I deploy easy that thing and how do I optimize that thing with many javascript files?. In C and Assembly I know in one part of my program I created in C the function that needs to optimize and re write it in assembly inline but what about GWT?. I think is not the same thing.

Or really maybe I dont understand GWT, Now you see how confuse are Google products? heheh.

Regards.

 

Ray Cromwell replied on Tue, 2008/09/09 - 2:39pm in response to: John Denver

What you're describing is an aesthetic issue it seems, not really a technical one.You need to think of GWT as a cross-compiler not a regular compiler.Imagine using GCC to produce binaries for x86, MIPS, PowerPC, and 68k architectures.You'd end up with 4 binaries. That is what GWT does today, it produces a separate 'binary' for Safari, Firefox, Internet Explorer, and Opera.

Why does it do this? Because it is absolutely more optimal to do so.Studies have shown that each additional 100ms of startup time in your application causes you to lose users.GWT is architected to produce the fastest and smallest Javascript code possible with the fewest numbers of HTTP roundtrips.

It does this through the Deferred Binding architecture,with allows GWT to intercept the construction of Java classes,and replace them with other user defined classes.For example, you can replace the DOMImpl class with one for Safari, Internet Explorer, or Firefox. GWT compiles each of these permutations separately, so calls to methods like DOM.setInnerText() become inlined for each browser, there is no polymorphic dispatch, and users of Firefox don't have to suffer downloading inactive code meant for Safari or Internet Explorer.Function calls in Javascript cost alot more than inlined code, the end result is a faster Javascript application especially on slower browsers.

The reason the files are named funny names like ".cache." isbecause GWT supports perfect caching and eliminates cache validation HTTP requests. The GWT output files are named for cryptographically strong hashes of the contents,such that if the contents change, the filename changes. Once a user downloads your application,all future users of the application collapse to a single HTTP request downloadinga small ~1k bootstrap script.

This leads to an up to 5x reduction in startup time in your application. I'll say it again,if I develop an app in GWT, it will most likely load and display 5x sooner than an equivalently appwritten with ZK, or ExtJS, or jQuery, or some other framework.

You're complaining because rather than foo.js, GWT produces 4-5 files named abcd.cache.js.These cost $0.0001 diskspace, but save you on network bandwidth and make your users happier.

And if you are really addicted to this concept of a single file, you can use the SSO linker in GWT to produce a single file.

The C and Assembly analogy doesn't exactly hold water either.A real optimizing compiler could produce arbitrary code transformations on your source,obscuring the mapping between output assembly and source, unless it annotates the files,which you can do with GWT as well (search for the SOYC patch). GWT doesn't make this impossible,most people just find it unneccessary.

My point is, you refuse the read the documentation, tutorials, or community posts,and then assert that Google produces are "confusing" One could say the same thing about ZK. Ihaven't read the docs. The whole thing is very confusing. Should I say that ZK has a terrible product?

Perhaps it is true that Google needs to improve their communication with respect to GWT's value proposition,but that's a bit different than a flaw in the technology.

Richard Walker replied on Sun, 2008/09/14 - 1:01am in response to: Ray Cromwell

Thanks

Ray Cromwell

for helping stop the spread of FUD :-)

 

 

Roger Voss replied on Sat, 2008/09/20 - 12:53am

The Google Full Monty stack has some definite awkwardness as it currently stands:

* GWT uses Java, whereas the Google App Engine uses Python. (This is rather peculiar in another respect - Java is usually the sever-tier language instead of the web client language.) So to use the Google Full Monty stack, the developer will need to be ready to shift gears (ah, pun intended).

* Java is awkward for client GUI programming. No component model with properties, events, and databinding as intrinsic in the language. No closure language feature in Java - which the closure is the most natural way to code event handling (anonymous inner classes are very clunky by relative comparison to an actual closure language feature.) Alas, anonymous inner classes have to be used extensively to program GWT, and they very much tend to pollute the code readability. Plus, the anonymous inner class is the most confusing construct to teach new comers to Java language (learning JavaScript/ActionScipt closures are a snap by comparison).

* There is no declarative variation of the GWT client programming language. Flex has MXML, Silverlight has XAML. JavaFX has JavaFX script. Firefox has XUL. GWT just has imperative Java. The declarative languages are more natural, clearer to understand, and more concise for coding the view of the MVC pattern than doing equivalent in imperative language coding fashion.

* Any modern end-to-end web stack, that makes claim to support RIA web clients, needs to support server-side push of messaging to the RIA clients. The Comet Pattern, as devised by AJAX web developers, is one way to do this within confines of HTTP protocol (and over ports 80/443). Plus the server-tier is moving in direction of supporting the Comet Pattern better. Java servlet 3.0 spec provides for async programming model, which will mesh well with a Java NIO implementation (greatly enhances connections scalability). So does Google App Engine support message pushing to GWT RIA clients via Comet Pattern?

 

BTW, if "Google Full Monty Stack" ever catches on as how this stack is referred to, just remember who originated it. :-)

Mister Elyxor replied on Thu, 2008/11/20 - 6:48am

No closure language feature in Java - which the closure is the most natural way to code event handling (anonymous inner classes are very clunky by relative comparison to an actual closure language feature.)

 

public static void xClosure(final Object x){

final Object y = new Object(){

@Override

public String toString(){return "GWT creates var closures when you specify final variables of any kind, any where; even in constructors.";}

};

DeferredCommand.addCommand(new Command(){

@Override

public void execute(){

Window.alert(y.toString() + x.toString());

}

});

}

static (xClosure("Don't say there aren't ANY declarative languages for GWT. \nI've got preliminary test code for my own private xml dialect... It's just that there aren't any finished/polished models yet"));

 

 

....Ok, I think I see what you mean...

Java has a lot of weird little quirks that don't translate into simple-human very well,

But we should ask ourselves how "well" simple-human translates into machine code...

Not to mention javascript and it's oh-so leaky tendancy to let event handler closures DEVOUR memory...

THAT'S the biggest issue for any newcomer, and I <i>personally</i> find a virtual dip into the complexities of java a lot more navigable> than javascript...

(Ctrl+Click = Go To Source) == Yummy && BigLongJavaNames == minJS ?

Window.alert("java interfaces taste like prototypes to me") :

throw new CustomException("Non-compiled javascript waste time on the wire if it uses human-readable identifiers"){

@Override

public String getMessage(){

return "If gwt didn't compile this code, and CustomException.getMessage() never gets used, the user has to download ALLLLLLLLLLLLLLL this text even though it's depracated. If it is used, gwt will STILL trim this code because the override literally erases the default contents of getMessage()..."

}

};

 

 

 

...Apologies for this post; I've just been optic-nerve deep in source for too long, and I've forgotten how to play nice....

 

Once you pore over enough PRETTY code, you begin to see how GWT blends Java compiler-optimizations with javascripts['Crazily boundless\nlanguage \nrules'].prototype.SomeFunctionWithDifferentTypePatterns_7$("GWT almost entirely eliminates my javascript pet peeve, Which is the need to TEST the same state more than",1,"time.","I prefer knowing where my data is","by choosing whatever construction method I need","Without having to move or alter any existing source code"," or splitting class and injecting script tags to remove depracation or debugging code.");

 

public native JavaScriptObject SomeFunctionWithDifferentTypePatterns()

/*-{

return {'Crazily boundless

language

rules' :@some.overriding.static.class.cname::SomeFunctionWithDifferentTypePatterns(Ljava/lang/String;I;[Ljava/lang/String) }

}-*/

public static void SomeFunctionWithDifferentTypePatterns(String x,int i,String ... _){

Window.alert("Ok, so this example is a little extreme,\nbut I still think learning GWT is a good way to push the boundaries of java and ecmaScript. Namespacing is the way of the future, and once you can handle GWT JSNI, making modular, mashup xml dialects that encourage rapid crossover from audience to author should become less than totally confusing.  ...Unlike this entire post!");

}

 

I think that's enough near-gibberish for now.

Hope you liked this little rant...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.