

Going under the hood of Inbox - cleverjake
http://gmailblog.blogspot.com/2014/11/going-under-hood-of-inbox.html

======
comboy
> 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
Maybe it's forgivable for now because it's still in Beta and is invite-only.

~~~
shadowmint
To be fair it does come off as a bit preachy to blog about your great
crossplatform story under the circumstances.

~~~
jrockway
I believe the cross-platform comment is about supporting iOS and Android.

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

------
frik
> 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
Whats the source you have for this information?

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

------
eridal
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
Check if theres a fixpoint..

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

~~~
chii
> [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
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.

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

------
reactor
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?

------
optymizer
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?

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

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

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

