Hacker News Reader

This is a super interesting perspective. It seems to me that another way to strike this very tricky balance is to design a language with it in mind - so that you can choose semantics with the emulation trade-off explicitly taken into account - and invest very heavily in its ecosystem - so that you can catch up on the library, framework, and IDE front. Arguably both Dart and TypeScript (among others) are doing the first part of that, but only TypeScript is doing the second part. I guess there's a third important part too: choosing a really good set of semantics based on that trade-off. I think TypeScript has really nailed that one. I like Dart and Elm too, but TS is definitely in the sweet spot for me.

Unfortunately, to take this approach you generally need it to be a new language, so it doesn't have existing ecosystem baggage to carry along, which means it is less likely to win on another axis you often care about: developer familiarity.

This is why the candidates in this space are only the upcoming ones like Dart, Elm, and maybe Kotlin. The other "compile to web" approaches that use more established languages (like emscripten for C++ or GWT for Java) tend to produce larger binaries due to carrying along their ecosystem.

This is restating GP's point, but to say it again, this tradeoff is kind of inevitable -- half the reason to want to transpile is to reuse knowledge and libraries, but then by reusing those libraries you kill your binary size.

(This dynamic reminds me of all the people who hoped they'd be able to reuse their existing web apps on mobile but ended up with bad mobile apps. I think it's possible to make a good web-based app work on mobile but it's often a rewrite from an existing web site, at which point you're often rewriting anyway and might as well use a mobile-native language.)

JS did already have flavours and with ES6+ we did get an entire new language ;)

This isn't like using Kotlin or Scala in order to use an alternative to the "original" language. The power of TypeScript is that it is designed to be less an alternative programming language per se than a dev tool for JavaScript. Instead of choosing different semantics, you're being somewhat more explicit in specifying your JS semantics. And you aren't switching to a different ecosystem, you're making your tools more powerful when working with the JS ecosystem.

Since the nature of this "tool" is an extension to the syntax, there is a bit of risk that there will be an conflict with some future JS, but other than that, the 2-factor (same but more explicit semantics, same but fortified ecosystem) analysis seems to show why TypeScript is popular.

Kotlin looks promising. Sure, you can use the whole JVM ecosystem with Kotlin/JS or Kotlin Native. But it looks like JetBrains is trying to bootstrap a JVM-independent Kotlin ecosystem.

So why Kotlin instead of TypeScript?

1. Potentially more static optimization, because Kotlin is designed from the start for static typing. 2. Ability to target other platforms (Android, iOS, desktop) without adding the overhead of a JS runtime.

Why not Scala?

1. Scala's standard library is heavier. For instance, Scala has its own collection classes, whereas Kotlin merely has its own collection interfaces. I assume this is why Scala.js advertises a starting size of 45 KB gzipped for an optimized build. That's not actually very small. 2. On the JVM, Scala fundamentally gets interop wrong in at least one way: Java getters and setters don't automatically become Scala properties, as they do in Kotlin. So idiomatic real-world Scala requires more wrappers.

The one thing that worries me about Kotlin is that it has reflection instead of compile-time metaprogramming (e.g. macros). Wherever reflection is used, it impedes static optimization (e.g. ProGuard, other tree-shaking). Sure, real-world JVM work has to use reflection sometimes, but at least JetBrains should have refrained from providing an API for doing Kotlin-specific reflection, and provided something like macros instead. (Edit: And yes, the Kotlin reflection API is implemented in the JS back-end. That was a mistake.)

Oops, meant can't use the whole JVM ecosystem with JS or Native.

Technically GWT is still an active project. They're (slowly) working towards a 3.0 release. I use GWT in my day job.

I used GWT to build an app in 2011-2012. It was my first web app, and it needed to have a desktop-like feel. GWT + the SmartGWT UI library allowed me to leverage my existing experience with Java, its IDEs and tooling, and various desktop GUI frameworks to build an app that did what I needed.

But, over time GWT became a hindrance rather than a help. The DevMode plugin stopped working as of FF27, and I had to keep around a copy of FF24 just to debug the client. The entire app had to be recompiled every time I made an edit and refreshed the page, wrapping JS libs to expose them to the Java code was a pain, and no one else on the team I moved to had ever worked with GWT. The discussion around this notional "GWT 3.0" didn't help either - it sounded as if half of the technologies around GWT would be removed, like GWT-RPC, but at the same time all the threads about it have been saying "well, J2CL is still internal to Google, we'll get it out eventually". Really uncertain future there.

I spent the next couple years working on a JS app, introduced Backbone+Marionette, and became comfortable with JS. In mid-2015, I began exploring the idea of rebuilding my app's client with a modern JS stack, and decided to try these "React" and "Redux" things I was reading about. Prototyped a client rewrite, and it was clear this was the way to go.

A few months ago that rewrite finally reached feature complete, and I got to go in and rip out every last line of GWT in the codebase. I was absolutely GLEEFUL when I did that :) The React+Redux codebase, with Webpack+Babel as the build toolset, allows us to iterate so much faster and with a better dev experience.

I can understand why GWT would still have some semblance of usefulness in certain enterprise situations, but I would never touch it again myself.

I think GWT suffered from being a bit too early. If source maps and Java8 closures existed in the early days, GWT would have been a lot more compelling.

I also did a lot of GWT work about a decade ago and haven't touched it since. But there's a lot of things I miss, and I would be willing to consider a "modernized" GWT if it ever materializes. I especially miss GWT-RPC; statically checked typesafe interfaces are just much faster and safer than hand-coding REST interfaces and hoping the client and server agree.

That said, I do think the train came off the rails when added all that crazy model-blah-blah-presenter pattern stuff. If GWT is ever going to make a comeback, it needs some sort of simple equivalent of Angular or React.

Yeah, it's kind of funny when you look at what GWT had vs what modern JS development looks like. Multiple browser targets, using the same language on both client and server, static types, RPC declarations, a dev mode server, etc.

That said, GWT-RPC also went from being nice to a pain. The serialization formats were "proprietary", in the sense that they were GWT-specific and couldn't be reused with any other platform. There were actually two separate formats. Client->server was some kind of custom text format, while server->client was _technically_ JSON, but the contents were still basically opaque. (I found a document that tried to reverse engineer the format, and it was pretty ugly.) That was another pain point, actually - inspecting API calls in a browser's Network tab was useless, because you couldn't interpret anything out of the contents. Also, I'll take promises (and `async/await`) over GWT's ugly `MyRpcInterface/MyRpcInterfaceAsync` definitions and success/failure handlers any day.

When I rebuilt my app, I was lucky enough to be able to re-expose the same internal API endpoint implementations over JSON-RPC. That let me keep my existing backend logic, and build out the new JS client separately while keeping the old one in place until the new one was ready.

I agree the implementation of GWT-RPC could have been better. It was also pretty slow if the payload was a lot of tiny objects. But I'm less enthused with promises than you are; I like GWT-RPC's programming model.

I'm surprised some sort of IDL-based client & server generator for REST services hasn't taken off.

Have you looked at Swagger's IDL?

The big problem with an IDL that people want to avoid is tight coupling, IOW, all systems have to be upgraded at once to use a change in API.

Tried Vaadin? It's a different take on the "write Java rich client code and run it in browser"-idea. It uses GWT as its "backend". They switched to GWT several years ago - too bad if they have to switch again due to GWT dying.

Could these very same arguments not be applied to Javascript itself? JS is "transpiled" to bytecode, a language with vastly different semantics and a totally different ecosystem. It end up being wildly inefficient, but consumers don't seem to mind.

The description of Dart is also wrong. My understanding is that they are aiming at REPLACING JS in the browser, not compile to it. Compilation to JS is a stopgap to make the language useful while it's left unimplemented in Google's very own browser (A fact that never ceases to entertain me). The next web language shouldn't compile to JS, it should replace JS.

As JS becomes the asm of the web, TypeScript is going to become the C of the web. Just enough abstraction to make it possible to write, but still not enough to tank performance.

That was their initial goal, but it's been years since they backed off of Dartium at this point.

For what it's worth, almost no one on the Dart team ever believed that Dart would "replace" JavaScript. The memo that claimed that wasn't written by anyone on the Dart team.

> The problem with (b) is that you typically opt into a large ecosystem that was originally written for a very different environment. This was a big issue with GWT: people would pull Java libraries, but those libraries, amazing as many are, were not written for the web or with code size in mind. This meant using a common library like Guava required a lot of engineering effort to keep code size in check. This also applies to WASM, possibly even more so.

Didn't GWT-RPC solve most of this ? You could simply run them on the server, which was another nice property of Java. You could actually link nearly any java library together with any app and use it, even with isolation if necessary.