6 ms·

Going under the hood of Inbox

107 points by cleverjake 12y ago

weavie 12y ago
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.
- jaimeyap 12y ago
  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.
- eva1984 12y ago
  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.
- azakai 12y ago
  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.
  - cromwellian 12y ago
    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.
    - azakai 12y ago
      Ah, very interesting, thanks for the info.
    - nostrademons 12y ago
      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.)
      - cromwellian 12y ago
        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.
- cromwellian 12y ago
  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.
- derengel 12y ago
  I don't think a company like Google will tolerate the hyperbuggy software of xamarin, xamarin just pushes new features with ever fixing anything.
  - mwcampbell 12y ago
    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.
- TeeWEE 12y ago
  You are not getting the quality native ui's using xaramin. Its always a common-denominator ui. Thus lacking new native features.
comboy 12y ago
> 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."
- exacube 12y ago
  Maybe it's forgivable for now because it's still in Beta and is invite-only.
  - comboy 12y ago
    Sure it is. I do love that product. But maybe then it's a little bit early for this kind of blog post.
  - shadowmint 12y ago
    To be fair it does come off as a bit preachy to blog about your great crossplatform story under the circumstances.
    - jrockway 12y ago
      I believe the cross-platform comment is about supporting iOS and Android.
      - shadowmint 12y ago
        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.
- maxmcd 12y ago
  It "works" in firefox: https://gist.github.com/VictorBjelkholm/1d0f4ee6dc5ec0d6646e https://gist.github.com/VictorBjelkholm/1d0f4ee6dc5ec0d6646e
deleted 12y ago
[deleted]
_lce0 12y ago
this is cool! it would be fun to try compiling from.. - java -> j2objc -> objc2j [1] - objc -> objc2j -> j2objc and compare the outputs :) [1] https://code.google.com/p/objc2j/ https://code.google.com/p/objc2j/
- revelation 12y ago
  Check if theres a fixpoint..
shadowmint 12y ago
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.
- nodejsisbest 12y ago
  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)
- chii 12y ago
  > [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).
  - shadowmint 12y ago
    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.
optymizer 12y ago
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?
frik 12y ago
> 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.
- wh-uws 12y ago
  Whats the source you have for this information?
  - frik 12y ago
    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 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.
reactor 12y ago
Just for curiosity, have you guys considered http://www.robovm.com/ http://www.robovm.com/ Or is it that it wasn't available when you guys started of with inbox?
TeeWEE 12y ago
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
- sfilipov 12y ago
  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?
  - TeeWEE 12y ago
    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.
marcamillion 12y ago
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?
- on_and_off 12y ago
  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.

107 points by cleverjake 12y ago

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.

jaimeyap 12y ago
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.
eva1984 12y ago
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.
azakai 12y ago
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.
- cromwellian 12y ago
  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.
  - azakai 12y ago
    Ah, very interesting, thanks for the info.
  - nostrademons 12y ago
    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.)
    - cromwellian 12y ago
      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.
cromwellian 12y ago
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.
derengel 12y ago
I don't think a company like Google will tolerate the hyperbuggy software of xamarin, xamarin just pushes new features with ever fixing anything.
- mwcampbell 12y ago
  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.
TeeWEE 12y ago
You are not getting the quality native ui's using xaramin. Its always a common-denominator ui. Thus lacking new native features.

comboy 12y ago

> 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."

exacube 12y ago
Maybe it's forgivable for now because it's still in Beta and is invite-only.
- comboy 12y ago
  Sure it is. I do love that product. But maybe then it's a little bit early for this kind of blog post.
- shadowmint 12y ago
  To be fair it does come off as a bit preachy to blog about your great crossplatform story under the circumstances.
  - jrockway 12y ago
    I believe the cross-platform comment is about supporting iOS and Android.
    - shadowmint 12y ago
      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.
maxmcd 12y ago
It "works" in firefox: https://gist.github.com/VictorBjelkholm/1d0f4ee6dc5ec0d6646e https://gist.github.com/VictorBjelkholm/1d0f4ee6dc5ec0d6646e

deleted 12y ago

[deleted]

_lce0 12y ago

this is cool! it would be fun to try compiling from.. - java -> j2objc -> objc2j [1] - objc -> objc2j -> j2objc and compare the outputs :) [1] https://code.google.com/p/objc2j/ https://code.google.com/p/objc2j/

revelation 12y ago
Check if theres a fixpoint..

shadowmint 12y ago

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.

nodejsisbest 12y ago
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)
chii 12y ago
> [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).
- shadowmint 12y ago
  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.

optymizer 12y ago

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?

frik 12y ago

> 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.

wh-uws 12y ago
Whats the source you have for this information?
- frik 12y ago
  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 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.

reactor 12y ago

Just for curiosity, have you guys considered http://www.robovm.com/ http://www.robovm.com/ Or is it that it wasn't available when you guys started of with inbox?

TeeWEE 12y ago

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

sfilipov 12y ago
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?
- TeeWEE 12y ago
  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.

marcamillion 12y ago

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?

on_and_off 12y ago
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.