Hacker News Reader

Comment by nostrademons | Hacker News Reader

Considering that most Google Apps (GMail, G+, Docs, Calendar, etc.) are single-page webapps with over a million lines of JS, I'd hardly say "GWT is the only way to go". The programmers I know at Google who worked on complex GWT apps (notably Google Base and Adwords 3) didn't have very many nice things to say about it, besides the Eclipse integration.

The Java/JS integration is handled the same way it's handled in any large distributed system: define a protocol for the server and client to communicate. Only evolve the protocol in backwards-compatible ways. You need to do this anyway if you expect user sessions to survive server upgrades, because you may have an old client talking to a new server. I'm curious how GWT handles this case - if it's autogenerating communication responses, it needs to be aware of both old and new versions to safely upgrade them.

View on HN

I'm most familiar with GWT-RPC and it doesn't have any backward compatibility built in, so most deploys are a protocol change. (It does at least give you a clear error when there's a protocol mismatch.)

So if you want old user sessions to survive, you'll need to keep the old service available until they reload the page.

There are protobuf/JSON-based alternatives with a better compatibility story.

It's not true that most deploys are a protocol change - only changes that would also change Java serialization's serial UID will cause GWT-RPC clients to become incompatible.

I routinely deploy a new version while hundreds of users are online and nobody is the wiser.

Well, that's true; it depends on how complex your protocol is and how often you change it. Simplicity is good!

But this can be tricky for large, distributed projects, where the author of a class might not even be aware that it's used with GWT.

Actually there is backwards compatibility in the same sense as there is binary compatibility. Have a mechanism to force upgrades, ideally conserving state. Leave the old call in place for 1 version.

This is not difficult.

Protobuf/JSON alternatives don't even have frontend-backend compatibility in the same version. Protobuf in java has completely different encoding to normal protobuf, meaning you need TWO protobuf libraries in your backend, and of course javascript protobuf messages don't actually support anywhere near the language set that protobuf itself supports. Those are reasons why calling it protobuf is misleading. The data structures don't mean the same thing in the frontend and the backend.

Funny you mention docs... The new Google Sheets (y'know, that awesome spreadsheet app that lets you write javascript macros with a full in-browser debugger), is written in GWT.

As I understand it, Google does not write apps in javascript, at all. The language closest to javascript that they do use is closure [1]. Closure is technically a javascript to javascript compiler but it makes the language

1) compiled, not interpreted

2) strongly typed (not optional typing according to the google style guide [2])

So yes, there are large javascript applications. In the same sense that KDE is an extremely large C application, or that the linux kernel is written in assembly. Only not really written in javascript.

[1] https://developers.google.com/closure/

[2] http://google-styleguide.googlecode.com/svn/trunk/javascript...

(I worked at Google, with Closure, on some of these large JS apps. The Closure tech lead responsible for open-sourcing it is a friend of mine.)

It's true that all of Google's major customer-facing apps use Closure. However, I would not consider it to be a separate language, but rather a large component library and toolchain for developing JS apps at scale. The language is identical to Javascript, and Closure apps can be run uncompiled, they just take up more bytes on the wire and give the programmer weaker error-checking.

It is also very possible to write Closure without the type declarations - I've done it, frequently, for various doodles & easter eggs. They are non-optional according to the styleguide, but that's a style choice mandated for large teams. Typically, type annotations make working with large multi-developer JS apps much easier, but they're unnecessary for smaller one-off projects.

Also, any JS developer off the street can download Closure and use it to write JS apps, since it's open-source. If they want to use Closure Compiler they will probably have to forgo certain language features; I once tried to get JQuery to compile with it and it was basically a total loss. But the language should be completely familiar to anyone accustomed to working with Javascript. (You probably don't want to do this if you just have a small startup, since both the compiler and class library are designed for working with very large-scale apps and pay a large verbosity penalty for keeping things manageable, but it's possible.)

And you can implement C as a set of assembler macros and a preprocessor step (which can be part of any C compiler). That does NOT make C and assembly the same language. The same is true for large C++ codebases. Nobody claims they're valid C, even though they're one preprocessing step away from being one.

Specifically C is "smaller". Everything in C can be expressed in assembly, but not every piece of assembly code has a matching C code. One hopes that it's mostly the more insane parts of assembly code that can't be translated.

Nobody will argue that C and "text" assembly are the same language. In the same way, I argue that javascript and closure are very, very different. Generally, assuming google actually demands closure apps compile with the toolchain (I'd be astonished if they didn't), these languages are not the same, despite one being valid in the other.

Javascript further clouds this issue by allowing preprocessing steps in the language itself. If you don't take that into account, you could say python is valid javascript. That's not a reasonable claim.

Reply on news.ycombinator.com