Going under the hood of Inbox(gmailblog.blogspot.com)
gmailblog.blogspot.com
Going under the hood of Inbox
http://gmailblog.blogspot.com/2014/11/going-under-hood-of-inbox.html
10 comments
It "works" in firefox:
https://gist.github.com/VictorBjelkholm/1d0f4ee6dc5ec0d6646e
https://gist.github.com/VictorBjelkholm/1d0f4ee6dc5ec0d6646e
The main bug blocking Inbox on firefox has been fixed in nightly.
Maybe it's forgivable for now because it's still in Beta and is invite-only.
Sure it is. I do love that product. But maybe then it's a little bit early for this kind of blog post.
To be fair it does come off as a bit preachy to blog about your great crossplatform story under the circumstances.
I believe the cross-platform comment is about supporting iOS and Android.
Come on~
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.
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.
> 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.
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.
Whats the source you have for this information?
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.
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.
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.
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.
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.
Actually, we just released GWT 2.7:
https://vaadin.com/blog/-/blogs/what-s-new-in-gwt-2-7
https://vaadin.com/blog/-/blogs/what-s-new-in-gwt-2-7
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)
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)
> [gwt]... was a headache in production
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).
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.
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.
this is cool!
it would be fun to try compiling from..
[1] https://code.google.com/p/objc2j/
it would be fun to try compiling from..
- java -> j2objc -> objc2j [1]
- objc -> objc2j -> j2objc
[1] https://code.google.com/p/objc2j/
Check if theres a fixpoint..
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
- 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.
Just for curiosity, have you guys considered http://www.robovm.com/ Or is it that it wasn't available when you guys started of with inbox?
I would love to get some feedback on the technical details.
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?
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?
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 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?
[deleted]
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.
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.
I am guessing they just like Java?
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.
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.
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.
Ah, very interesting, thanks for the info.
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.
I don't think a company like Google will tolerate the hyperbuggy software of xamarin, xamarin just pushes new features with ever fixing anything.
Can you provide evidence that Xamarin's software is buggy and they're not paying attention to bugs? Honest question; I'm evaluating Xamarin at work.
You are not getting the quality native ui's using xaramin. Its always a common-denominator ui. Thus lacking new native features.
Right, fun fact: this is what you see on inbox.google.com under firefox
"Inbox only works in Google Chrome. More browsers coming soon."