> If you’re building an application that (a) has significant UI independent client logic, (b) is targeting multiple platforms, (c) must not compromise on user experience and polish
Right, fun fact: this is what you see on inbox.google.com under firefox
"Inbox only works in Google Chrome. More browsers coming soon."
> allowed many of those clicks to be handled right within the browser without waiting for the server at all. Fast forward 10 years and this architecture is the norm, having been adopted by most websites
GMail made async HTML popular and well known. AJAX got popular in 2005 around the same time. Many media articles often cited GMail as a good AJAX website back than.
The reality was, GMail used invisible iframes for async data transfer and not AJAX. One reason was browser backwards compatibility. Memory leaks were an serious issue in early GMail days, especially IE 6 users complainted a lot. Gmail switched to AJAX around 2007. Interesting is also that AJAX was added to IE 4/5 for OWA (outlook web access) in ~1999 but it was little known and got popular as Mozilla completed the API reimplementation in 2004/5.
My own experience. I coded async DHTML back in 2002, with iframes or async XML loading (since 2005 named AJAX). I debugged GMail back then (the first version with the blue rounded corners, the same design as Google Groups and Google Code)
It's incredible hard to find older web resources from 10 to 15 years ago, as most bookmarks don't work anymore. And some current websites sadly try to rewrite the history.
Both GMail (2004) and Google Maps (2005) used iframes for the first years. There were still many users with older browsers without real AJAX support - Firebird/Firefox/Mozilla Suite/Netscape, Safari(?) and some Opera. Only IE 4/5+ and current Firefox/Mozilla browser supported real "AJAX" in late 2004. Iframes were supported by most browsers.
Interesting. ...and here I was thinking gwt was dead in the water these days.
Cant say Im in any particular hurry to go down that path again (used to use gwt, it was a headache in production), but there is certainly something to be said for sharing a single language for both server and client.
I remember using GWT as my first venture into dynamic web applications. I didn't really understand what was going on at the time 4 years ago, but I ended up making something kind of cool.
I too have a draw to the single language concept which is why Node was initially appealing to me. Thinking about it, there is a lot of <language> to JavaScript compilers, so I assume one could cobble a single language server / client setup for web development (though it wouldn't be as complete)
can you shed some light as to what the headaches were? I m quite interested in real world usages of gwt, but i don't often hear much about its use (despite the fact that i know it's still being used quite a lot, just internally in companies).
Let me caveat anything I say as being 3 years out of date.
The biggest and most annoying issue was that it generated a per-browser file for each variation of the compiled javascript. This resulted in a set of hashed javascript filenames to deploy in production, and while more efficient (why load IE specific code on safari?), it had some down sides:
- Every tiny change resulted in new files with new names. If you're deploying using binary diffs this is just a no go, because you have no way of knowing which of the 7 hashed filenames from last time matches the filename this time. You have to redeploy the entire application basically, for a typo. For large applications, this sucked.
- When a new browser version comes out, if you're lucky it 'just works'. I recall an update to IE where we were 'not lucky' and had to rebuild and redeploy every application to support the new version of the browser working at all.
- 3rd party javascript things had a mysterious tendency to work fine locally and then break in the live environment. I recall never figuring this one out, but something we were doing with GWT & the dom would sometimes just break, but would work fine locally if you ran the debugger. A lot of 'randomly remove and change code until it works'. :/
There are other issues with GWT that ultimately led us to stop using it (googles lack luster support, other new tools that were more designer friendly, new developers having to install a very specific toolset to be able to work on projects being the big ones), but those were the annoying production issues I personally encountered and had to deal with.
Not show stoppers by any means, but I'm certainly in no hurry to go back.
I really like this approach. I never liked any cross platform solution such as Cordova or Xaramin. The approach google is taking is a best-of-both-worlds approach:
- Latest uix on the native platforms
- Shared model layer in the apps
I would love them to create sample projects, or to provide a framework for doing this kind of stuff
How is that different from Xamarin? Inbox is written in Java and Xamarin apps are written in C# but I think the idea is very similar - cross platform logic, native UI. Why would you prefer the approach Google took but dislike Xamarin's approach?
From what i know, Xaramin only has the ui elements that both platform supports. You are writing one UIX for both platforms, and thus you can only use the common-denominater uix. Which limits your uix.
you are.
There is no real time compilation going on.
What they are doing is writing model code once in java and then use J2ObjC once in order to transpose it in ObjC.
The interest of this approach is obviously to only write model code once. Main benefits :
-same implementation everywhere, you can't hit a road block because one platform implemented its model in a very different way, so they need to refactor it entirely for new feature X. You also can't have a platform specific model bug.
-Less time spent coding the model.
I work on a very large scale mobile app where we have completely separate clients hitting the same REST API. We already thought about such a move (or something similar, like a common c++ module) but so far we continue to have totally separate web, Android, iOS and WP applications :
- the cost of a migration to such a solution is huge for a big app
- any bug in the generated code is the promise of a nightmare to debug and solve
- I am not sure it would save us so much time. The 70% figure does sound impressive though, so I might be wrong.
- our product managers are obsessed with features and don't care about the technical side of things. It is already very hard to restrain their shitty ideas like iOS design everywhere or never do any maintenance because there are always urgent new features. So, even if we wanted to, we would never get them on board with such a big refactoring.
I am more interested in the UI components used by web Inbox. Initially I thought it's Polymer, but after inspecting the code, it seems to be custom-rolled CSS. Perhaps its a new Closure Library with an implementation of Material Design?
I wonder why they went to all that effort when they could have just used Xamarin and one of several IL to JS traspilers instead. Probably just a standard case of Not Invented Here syndrome.
Sharing code across the client and server is also important. Not just code sharing amongst clients.
The JVM is going to be the preferred server target at Google over C# and .NET by a wide wide margin. Which probably rules out Xamarin.
Add to that the fact that native Android is already Java (source). And GWT is a mature technology that is Google maintained. Seems like the logical route to take.
Most Google servers run Java and there are millions of lines of Java code in our repository. GWT has existed long before Xamarin since 2006/7. And Java is a first class citizen on Android.
Otherwise, yes, they could have written the shared logic in C#, or C++, or a few other languages, all of which are portable between the platforms they want.
There might also be history, I believe gmail has been using Java/GWT, so it was a natural decision for them to continue using Java?
It is a little surprising on the performance side, though. I would expect C++ to be faster when compiled/transpiled to all three relevant platforms (iOS, Android, Web), compared to Java similarly compiled/transpiled. But maybe most of their time is spent rendering anyhow, and little in the shared code.
Gmail as written in 100% Closure Compiler code, Closure Compiler was invented for Gmail.
Simple fact is, Google is a Java oriented company. Inbox uses lots of components and shared code across the company that are based on Java. To use C# or C++ to do it would rewriting a lot of code that already exists.
JS performance is not the gating factor for the Web client in most cases, it's rendering and startup (code size). We run expensive calculations off the main thread in a Web Worker anyway.
The translation of Java to Objective-C could have been to C++ as well. I started prototyping something a while ago that does such. Objective-C makes more sense, because for iOS, the front end developers get to consume 'idiomatic' code that looks like they had hand-written it and it meshes well with other tools, and would work with Swift too.
The Apps (+ Ads, Android, Social, & DevTools) side of Google is a Java-oriented company. Search, Geo, Infrastructure, and Chrome are all very much C++-oriented. (Inbox is very much an Apps project, so of course they would lean toward a Java stack.)
That's true, Google has very large codebases of C++, Java, and Javascript. But the C++ code base cross-compiled to JS via emscripten wouldn't help us much on Inbox since most of the interesting bits are very backend oriented.
GWT has been there for a very long time, and they own android. Based on that, Java will be a non-brainer for their choice of data model. I didn't see to the point to go all the way to Xamarin.
Right, fun fact: this is what you see on inbox.google.com under firefox
"Inbox only works in Google Chrome. More browsers coming soon."