Google throws a 180 on its plans for Dart language Back in 2013, Google felt the Dart language deserved a native virtual machine baked into Chrome, because it felt JavaScript couldn't deliver the speed it craves. It therefore started the process of getting Dart turned into a standard to help things along. Fast forward to Wednesday and the Dart team, which Google supports but …
It would be far better just to use an IDE/editor which highlights/forbids dodgy JavaScript and enforces type consistency with comments. That seems to be the objective of all these languages which perch on top of JavaScript so you might as just well do it in JavaScript.
I think the problem is that many problems with Javascript can't be detected while writing it. Hence the preference for preprocessors that take the guess work out of writing reliable Javascript. The situation is very similar to using a compiler over writing machine or byte code. It's just that the output here is Javascript.
I suspect the reason for the compiler/transliteration approach is because of the limits of what you can do in the IDE. If you look at how compact TypeScript transliterates to verbose Javascript you can see the limits of what you can reasonably expect in the IDE and still expect to keep developers on board. The verbose JS itself is replete with hints which are essentially for the JIT.
It's the local darts championship. The champion goes up to the oche, and the commentator is ready.
He throws a treble-top.
"SIXTY!!"
Next, a single twenty.
"EIGHTY!!
The third dart hits the wire, bounces out, crashes through a nearby window and hits a passing nun right between the eyes.
"ONE NUN DEAD AND EIGHTY!!!!"
Google spooked devs as soon as they started talking of separate runtimes and integration into Chrome. I'm sure many developers had flashbacks to the days of VBScript where Microsoft tried to fragment the web by shoving their own scripting language in their own browser.
Ironically Microsoft seems to be the winner this time around with Typescript. Typescript is a compiler that outputs JS but adds keywords for classes, static typing and modules. So it's familiar to JS (and Actionscript) devs while still adding useful functionality.
I don't rate JS or TS much as a language (binding and scope rules are a minefield) but sometimes pragmatism trumps idealism. TS has mature tools, thousands of definition files for calling popular JS libraries and has become a mainstay in many projects.
"Nothing to do with the writers of Actionscript and Typescript being in the standards group for ECMA???"
So you mean this was all a conspiracy and a mere 12 years later they sprung the steel trap shut?
More likely it was to do with the general craptitude of JS in browsers at the time and concerns about implementing a new radical version of it while still supporting older versions.
these last 3 years, between node, emscripten, asm and multi-step/partial compilation, javascript performance has seen heaps and bounds of performance boost. Not any javascript, mind you. However precompiler/transpiler ouput code that the js compiler like.
I mean, now you have unreal engine games running in javascript in the browser. This is quite crazy, if you ask me.
I was nosing around online to see if there was a port of dot/Graphviz to render svg, or at least test dot, online. Turns out there had been such a discussion, someone wanted to port it to js. But someone else just chucked emscripten at its codebase and, presto, online graphviz. Impressive.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
