Going under the hood of Inbox
gmailblog.blogspot.com
gmailblog.blogspot.com
Right, fun fact: this is what you see on inbox.google.com under firefox
"Inbox only works in Google Chrome. More browsers coming soon."
If you can't get your application working on more than one browser, how am I supposed to take your talk about working on multiple platforms seriously?
Post content: good, interesting.
Timing: not ideal.
It's like Australia at the G20 in 2012. Didn't really make them any friends with that either.
https://gist.github.com/VictorBjelkholm/1d0f4ee6dc5ec0d6646e
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.
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.
e.g. Aaron mentioned it: http://www.aaronsw.com/weblog/ajaxhistory and you can search through Slashdot.org, (former) digg.com and web.archive.org
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.
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 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).
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.
it would be fun to try compiling from..
- java -> j2objc -> objc2j [1]
- objc -> objc2j -> j2objc
- 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
Why did they have to create a data model in Java and then cross compile that into other languages for their various platforms?
Why not just create a RESTful API on top of Gmail, and then just build clients to consume that API?
What's the difference between the two approaches? What is the benefit to doing it the way they did it?
It feels like sending JSON down the wire, would be quicker than waiting for some real-time compilation to be done and sent to the client.
Am I missing something?
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.
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.
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.
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.