6 ms·

> The first tempting option is to just abandon this ruined planet and settle a new one that doesn't even involve JavaScript. If only we invested more in GWT (a

> The first tempting option is to just abandon this ruined planet and settle a new one that doesn't even involve JavaScript. If only we invested more in GWT (a Google project that compiles Java to JavaScript) or Dart (a Google project that compiles a new language to JavaScript) or WASM or [insert your favorite language here — Clojure? Haxe? Elm?] we wouldn't need to worry about JavaScript at all! I thought about this for quite a while when we started on TypeScript at Google (I work on this with Evan). I've convinced myself that using a different language cannot solve the problem that we're looking at. The argument goes like this: if you use a different language than JavaScript for front end development, you're (hopefully) doing it for a reason. That is, you (a) want the other languages semantics (e.g. bounds checks on array accesses, runtime types, method dispatch, you name it), or you (b) might want the programming languages ecosystem - editors, IDEs, etc; but most importantly libraries and frameworks. Most likely, you're looking for a combination of (a) and (b). The problem with (a) is that the more different the runtime semantics of your programming language are, the more emulation code you need. Emulation code is costly in code size, performance, interop with JS, and often understandability (at some point you will need to debug the output, believe me). 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. These mechanisms work together to make it very hard to hit the sweet spot between performance, developer experience, and interoperability. And ironically, the better you get at the goals you're aiming for (different semantics, different ecosystem), the farther you get away from a working solution. I don't think it's impossible to achieve a transpile-to-JS language that works really well with enough investment, but keeping in mind the other reasons Evan lists (mind share, existing code base), incrementally improving JavaScript where needed is IMHO the much more promising approach.

Bjartr 8y ago
Technically GWT is still an active project. They're (slowly) working towards a 3.0 release. I use GWT in my day job.
- acemarke 8y ago
  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.
  - stickfigure 8y ago
    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.
sanderjd 8y ago
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.
- evmar 8y ago
  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.)
- z3t4 8y ago
  JS did already have flavours and with ES6+ we did get an entire new language ;)
- SiVal 8y ago
  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.
delusional 8y ago
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.
- esrauch 8y ago
  That was their initial goal, but it's been years since they backed off of Dartium at this point.
  - munificent 8y ago
    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.
mwcampbell 8y ago
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.)
- mwcampbell 8y ago
  Oops, meant can't use the whole JVM ecosystem with JS or Native.
candiodari 8y ago
> 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.

Bjartr 8y ago

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

acemarke 8y ago
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.
- stickfigure 8y ago
  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.

sanderjd 8y ago

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.

evmar 8y ago
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.)
z3t4 8y ago
JS did already have flavours and with ES6+ we did get an entire new language ;)
SiVal 8y ago
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.

delusional 8y ago

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.

esrauch 8y ago
That was their initial goal, but it's been years since they backed off of Dartium at this point.
- munificent 8y ago
  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.

mwcampbell 8y ago

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

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

candiodari 8y ago

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