Hacker News new | comments | show | ask | jobs | submit login
“We have decided not to integrate the Dart VM into Chrome” (dartlang.org)
516 points by kasperset on Mar 25, 2015 | hide | past | web | favorite | 285 comments



I think Dart is sort of like CoffeeScript in that it was an experiment and influenced a lot of JavaScript standards people.

A lot of the features of CoffeeScript are being integrated into JS with ES6 and ES7. The same is actually happening to the unique features of Dart such as typing and SIMD and better modules.

Typing is so cool: http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects

SIMD is amazing: https://github.com/johnmccutchan/ecmascript_simd

So, thank you Dart for showing us the way!

My only worry is that the innovators behind Dart are going to be stuck on the Dart project while JavaScript gains their features and even more momentum. I would suggest that they let Dart die and not be stuck with it for years after it has stopped being relevant -- that would be a waste of their talents as they did really see what the future would be.


Good for lulz, but this is really uninformed, if not made up from whole cloth.

The influence of Dart on ES6 and 7 apart from SIMD (John McCutchan shout-out, John did the Dart work and then worked on https://github.com/johnmccutchan/ecmascript_simd; I had some small helpful role to do with the project involving Mozilla and Intel, too) and the courage and validation -- not the idea, which pre-dates Dart -- of giving the for (let...) loop a binding per iteration in ES6 as in Dart, there has been no influence or help from Dart.

Modules in ES6 have nothing to do with Dart, and the work started in 2010, well before Dart ("Dash") leaked. Classes too pre-date Dart, in some ways they go back to JS2/ES4 of the 1999-2003 era, and ES4 of the 2006-8 era.

CoffeeScript owes a lot to Ruby and Python, of course, and I did design-champion fat arrow functions into ES6, inspired in part by CoffeeScript. ES6's for-of loop is responding to the same gravity-well as CoffeeScript's for-of, but it differs in substantial aspects. And so on.

Languages influence one another -- news at 11 -- but Dart did very little intentional uplift work for JS. SIMD is the big and very good exception to this norm. Better late than never, I say. Now is a good time to help get value objects including bignums into ES7.

https://code.google.com/p/dart/issues/detail?id=1533


> Good for lulz, but this is really uninformed, if not made up from whole cloth.

To be clear, I didn't say that Dart or CoffeeScript associated people actively meant to be a guide for JavaScript (I'm pretty sure that having CoffeeScript and Dart effectively subsumed into JavaScript wasn't the goal), but the fact that these languages existed and has neat features did served as a guide for evolution of JavaScript.

Thus I am making the case of much weaker case of languages influencing each other, rather than a stronger case. And there is massive influence going on here, whether intentional or not -- the speed at which features of Dart and CoffeeScript being pulled into JS is very rapid.

I think your comments actually bare this out -- Dart people helping with SIMD, and you being inspired by CoffeeScript.


You wrote "influenced a lot of JavaScript standards people." Please name two.

You wrote "The same is actually happening to the unique features of Dart such as typing and SIMD and better modules." My reply: no, yes (thanks to bottom-up work by John McCutchan, not "Dart people" plural -- there you go again), and nope. Any types for ES7/2016 or beyond are likely to be based on TypeScript, Flow, and V8's SoundScript experiment, not on Dart. Modules in ES6 have no relation to Dart modules/packages.

Really, "exaggeration" doesn't being to capture the false overreach of your first comment, and walking back from it to vague "everything's influencing JS" isn't helping.

Apart from SIMD, Google by investing in Dart at cost to JS (recreated V8 team; replace-not-embrace strategy for ~5 years) missed out on uplifting ES6 to have bignums and other things that would materially aid correctness and performance of dart2js, which is now the only way forward for Dart in browsers.

I hate playing Cassandra, but the good news is that Troy didn't fall: JS prevailed, at some unnecessary cost, and as predicted. See https://news.ycombinator.com/item?id=2982949 et seq.


Weird, I really didn't expect this conversation...

(1) I am referring to the high level features of Dart and CoffeeScript, not the specific implementation of features. Specifically I am referring to the clear reduction in CoffeeScript/Dart positive differentiators over the past few years, mostly because future JavaScript (es6/es7) is moving aggressively to close the gap and then go beyond Dart/CoffeeScript. This is a great thing.

(2) I am a complete outsider to the standardization process - I actually know no one involved in the process. So why did I make the inference then so confidently? I've been doing software product development in competitive industries for a couple decades now. I know how it works. People are always influenced by competitors to push ahead faster and smarter, especially competitors that try to jump ahead.

This comment of mine from two years ago sums up my feelings of Dart and its influence on JavaScript: https://news.ycombinator.com/item?id=5728786


I think what Brendan is trying to say is that Dart simply had no influence on ES6 and ES7 except for the idea of SIMD. That means no specific implementations, and no high level ideas.

Any resemblance you might find between Dart and ES6/ES7 would be because of Darts resemblance to either CoffeeScript or TypeScript, languages that did in fact influence ES6 and ES7.

My personal view: I don't think Dart is the sort of language Javascript wants to be like at all. Also, totally off topic regarding your comment of 2 years ago: Java has never kept up with C# has always been years behind and still lacks many features that C# has had for ages. The only reason people still use Java is that C# had no enterprise backing on non-Microsoft platforms and its main implementation was proprietary. These things are changing, and I think that will be the end (finally) of Java.


"These things are changing,"

There is still no end to end story for dev on Linux/Mac with MS backed tools (Mono is not .NET).

"and I think that will be the end (finally) of Java."

just day after Google will take C# as main dev lang for Android...

IMHO It's more likely that Dart will become new Android's main lang.


Actually, MS recently open-sourced the .NET framework (".NET Core") and announced they will be adding support for Linux and Mac OS X: https://github.com/dotnet/corefx

...seriously. April the first is still 5 days away.


"Actually, MS recently open-sourced the .NET framework (".NET Core")"

I know that. My point is you go to dartlang.org and get the IDE with SDK with single download for Mac, Linux or Windows and use it now.

With .NET you can't do the same now on non-Windows (you can use Mono but it's not MS project) Dart is designed to do webdev and .NET isn't


A last note, I didn't intend my comment to be interpreted in the hard fashion that you are interpreting it -- how could I given my outsider status?

I apologize for it being open to that interpretation. I do view most of your criticisms to be based on this unintentional straw man interpretation of my points: http://en.wikipedia.org/wiki/Straw_man


I did not make any straw-man arguments. You wrote specific words (I've quoted them) that denote things that I know to be false. You now seem to admit this. Are we done yet?


> You wrote specific words (I've quoted them) that denote things that I know to be false.

You admitted both the influence on you of CoffeeScript (e.g. fat arrow) and also that the Dart SIMD standard guy did the ES7 SIMD standard. Thus at minimum both CoffeeScript and Dart have influenced directly what has ended up in future versions of JavaScript via the JavaScript standards people. So that original claim of mine is true at minimum, only the qualification of the influence being significant/large is at question.

Near equivalent features to those of Dart and CoffeeScript are rapidly being added to future JavaScript, including fat arrow, typing, classes, SIMD, Futures, async/await, etc. Whether or not these features are directly based on Dart or not doesn't change the fact that it is happening. So that original claim of mine is also true.

E.g.: https://robots.thoughtbot.com/replace-coffeescript-with-es6

The intensity of this argument about an admittedly overly vague hacker news comment is surreal.

While I respect your work highly, benefit from it significantly, and it wasn't my intention to diminish your contributions or effort or anything else, I can not continue this.


Your original claims, plural, included "typing" which cited ES7 TypedObjects (yet TypedObjects are not "typing" as you used the term: a type system, whether optional or tool-checked), and modules. Both of those assertions are flat wrong.

Again, modules in ES6 started before Dart ("Dash") leaked.

Your original comment said "Thank you Dart for showing us the way." Happy-clappy nonsense!

Why am I on the warpath?

First, sloppy history retelling -- even if just fannish exaggeration -- is bad in itself.

Second, and I've gone on the record about this since 2011, Google chose the wrong "REPLACE JS BECAUSE IT CANNOT BE FIXED" strategy, and wasted years and megabucks. Their choice, but not something to congratulate them over. We could have had even more in ES6 if the V8 team had not been reset and JS back-benched as it was. That cost years.

Third, the meme you're spreading is that JS is incompetent or severely hobbled without being shown the way by enlightened others. This does a disservice to many people including the V8 team (the new team) members working in earnest on JS via implementations and TC39. It's a particular falsehood to which I object as a peer of those people on TC39.

Dart as an intentionally designed, full-time-job-for-60+-people, good and well-done project at Google, creating useful and coherent tools as well as the language itself? A fine thing in isolation, ignoring the actual history, global strategy, and consequent trade-offs.

Dart as the thing that showed JS the way (same for CoffeeScript, but let's defer that and focus on Dart)? A fraudulent claim that covers up real mistakes in strategy made by Google, which cost big time and money, not just for JS and the Web, but bad also (in light of this week's news) for Dart.

Why was the strategy bad for Dart? One example: only now, finally, might bignums get into ES7/2016. They could have been in ES6 and in V8 and other engines by now, since we were working on them since 2010, but without a champion who saw the priority and paid someone to spec and implement them in V8.

Do you see my point? Please do not play games about me "admitting" SIMD and maybe one other something else came from Dart. I've written that many times in multiple threads without prodding, on HN and on twitter. This is not an ego match. It's about accurate attribution of history, work, influence, and causality.


What you are letting a hacker news comment thread determine the history of JavaScript? This isn't how history is written - HN posts are emphera for the most part. Last time I checked you were not exactly powerless and reliant on others to write history for you. You have a megaphone, why not use it and write something authoritative on the history of JavaScript and Dart.

Also, you do realize that I wrote this to a Dart audience to encourage them to return to JavaScript -- and you do not convince anyone to change their minds by being an asshole towards their work.


It's HN, I'm here same as you, to opine and argue. Why are you applying a double standard? :-P


Note that what Brendan Eich is saying is that the influence couldn't have happened that way because the work on a lot of the features in question for ES6 started before Dart was available. You can't be retroactively influenced.


But he is basically saying he wasn't influenced except in the places he was influenced like the CoffeeScript fat arrow and the Dart SIMD stuff in ES7. This is an argument about degrees of influence, not whether or not he was influenced (as he admitted that.) This is not a winnable argument by anyone, I have to move on.


See my reply above. You've changed from multiple false claims of influence, so ginned up to a high degree of influence that you concluded with a fulsome "Thank you Dart for showing us the way!", to "any influence at all", and "don't hassle me about differences of degree of influence!"

So, really sloppy original comment with multiple false claims. Should I just put up with that as part of HN's descent to /. quality? :-(

/be


John McCutchan caught my attention early on and my hat goes off to him. He brought a unique perspective to advancing performance. I went from Dart to TypeScript to pure JavaScript for a variety of reasons, and I must say productivity in Dart is higher, sometimes much higher. However the Dart2js output and interface makes it less attractive despite higher productivity. I took from the announcement that Google will focus on fixing that, which is encouraging. It's really the only way forward for Dart, since no one else, and now Chrome, is going to include the VM.


> I took from the announcement that Google will focus on fixing that, which is encouraging.

That's exactly right. We have a bunch of people working feverishly on more human-friendly JS output:

https://github.com/dart-lang/dev_compiler


Looking fwd to see bignum support in ES7 fingerscrossed


Doing astronomy work in JS?


Very useful for spreadsheets and other financial calculations as well I believe, as well as some forms of custom Crypto.


Definitely (and I'm happy to write a friendlier comment reply, believe me!).

Bignums are good, in Dart as in other languages. On the agenda for "Harmony-era" ECMAScript, going back to 2009:

http://wiki.ecmascript.org/doku.php?id=strawman:bignums

More recent work generalizes value types into an extension mechanism for JS, so you can have built-in and user-defined numeric types with operators and literals.


Aren't decimals better suited for financial applications? That's what I've used in the past in Java land (BigDecimal).

Or are bignums and decimals the same thing? (not sure).


Bignums are closely related to arbitrary precision decimals (aka BigDecimals; "decimal" without more is somewhat ambiguous since sometimes those are fixed size or decimal floating point.)

Most financial applications deal with currencies each of which had a smallest indivisible unit in the application, which makes bignums most appropriate. But bigdecimals (or even arbitrary precision rationals) may be preferred in certain financial applications.


Without bignum it's hard to implement Decimal


Dart is much more full-featured than CoffeeScript. Dart is a completely new language, with much improved semantics. Dart has features such as method cascades, mixins, async/await, optional types, a rich core library, factory constructors, libraries, named parameters, lexical this, Futures, implicit interfaces, generics, and lots more.

[disclaimer: I'm on the Dart team]


I am not saying Dart and CoffeeScript are comparable in terms of features -- not at all, rather I am saying that both Dart and CoffeeScript have served similar purposes in showing where the JavaScript language can evolve towards in the future.


On the other hand, persuing the strategy that Google did with Dart distracted people and effort from the important task of actually improving javascript, so it may well have been a net negative.


If they'd succeeded in replacing it, there would have been no need to fix it. It's a big task, but I wish they'd succeeded and hope they (and/or others) try again.

Whether you like JS or don't, I think we can all agree that it stinks to have only one choice for client-side scripting.


ES7 has async/await. Coffee script has a tighter syntax despite being older than Dart. Typescript has optional types and is being used at both Microsoft and Google. Also: you don't think JS has libraries and mixins?


How about: "ES7 will most likely have async/await when it's finished."

Sorry, using the present tense for things that will be in browsers years later (hopefully) is a common practice that's an issue with me. Let's stick with what people can actually use today.

Also, pointing to features people can use in different dialects of JavaScript is not really fair. Just about everything you can think of has been experimented with and probably deployed somewhere. It doesn't count unless it's all available in the same toolchain and can be used in a unified way while writing a single app.


> Sorry, using the present tense for things that will be in browsers years later (hopefully) is a common practice that's an issue with me. Let's stick with what people can actually use today.

ES7 async/wait is available now via the ES7 polyfill Babel.js: http://babeljs.io/

There are a ton of polyfills available right now for ES6/ES7 features: http://kangax.github.io/compat-table/es7/

BTW I also think that the current state of aggressive polyfills is also influenced by Dart's compile to JS functionality. :)


Comparing Babel.js to dart2js is fair. I'd be interested in hearing more about about how well it works in practice from people who use Babel.js for large apps. (Also, how does it compare to Typescript?)


Anyone creating a new Ember.js application today is using babel by default. It works very well in my experience. I haven't used typescript however.


I think with time Typescript and Babel.js are to be merged, if you through in Strong Script to the mix I guess you have the future of JavaScript.


> Sorry, using the present tense for things that will be in browsers years later (hopefully) is a common practice that's an issue with me. Let's stick with what people can actually use today.

If that's the metric we're applying, Dart fares no better...


How so? You can use Dart today and yesterday and tomorrow.


wycats: IE 10 and up, Safari 6 and up, Chrome, FF, Opera, last 2 versions.


In what browser?


Chrome, Firefox, Safari and even IE!

All via dart2js


Sure but you can also use es7 today (which I did).


Yes, and even compared to ES7, Dart still fares rather well. Most people that doubt this seem to not have actually tried the Dart workflow and core libraries. The productivity gain from those two features alone makes it compelling against all other compile-to-js options, because what it brings to the table isn't just a fancy language with nicer syntax+semantics.


The dart std lib, at least the DOM manipulation bits, are indeed nice.

OTOH: JS has the largest module system of any programming language ever, which also tends to make it pretty productive.


Typescript has optical types

What are optical types? I've never heard of this term and Google turned up nothing on it.


100% sure it's a typo of "optional types".


How boring :-) I'd love to look forward to a language with optical types. I'm sure it's at least as interesting as operand overloading in Intercal.


Optical typing must be like duck typing taken to the extreme. If it looks like a duck then it's a duck, dammit!


Type coercion taken way too far ;)


I was imagining something like Lens in Haskell :)


Optical types are when they shave the bushy hair off of the type system, and it looks an inch longer.

https://www.youtube.com/watch?v=NsbXwzqlqsU


The types aren't optional. The types are always there. The type annotations are optional.


I also think it is great to see innovation from compile-to-JS languages to tickle down to JavaScript over time. This is awesome for JavaScript as well as for the compile-to-JS languages.

That said, there is a glass ceiling of how far you can go with iteratively improving JavaScript.

I'm glad that there are more ambitious languages like Dart that are designed from scratch by people with amazing background in language design & runtimes.

Having worked with Dart now over many months at Blossom (https://www.blossom.co) I can't imagine going back to writing JavaScript (not even ES.next++). Dart is conceptually much simpler. I really encourage you to give it a try.

Dart gives you a consistent and simple platform (stdlib, packages, tooling, …) to build upon that works well 'today'. It is easy to pick up and be productive in (compared to JS and all the things you have to train people on about its ecosystem).

With this new direction I expect the interop story with JavaScript to improve further as well.


Can't agree more.

When a new language is created, its feature set is a product of the times it is created in. i.e. what features are considered useful, popular, best practice etc. Of course times change and with it what this set of desirable features is. Languages evolve by adding support for some of these new features. But adding these new features whilst preserving the old becomes increasingly difficult and the new features tend to be somewhat hobbled and don't fit that well with the older features. For the first 10 years or so this tends to be ok but when languages get to the 10 - 20 year mark they start looking increasingly like frankensteins monster - a mixture of parts from different places / eras, none of which work terribly well and which don't fit that well with others. At some point IMO it's worth jumping to a new language despite the smaller community and package availability. But it's often only when you do try it for a while when you realise how much better the dev experience is compared to the frankenstein languages which have on paper adopted similar features. To me this is where Java, JavaScript, Python etc are now. On paper they can claim many of the features now that Dart has but the experience using them is not that of using those features in Dart. 

I can't imagine there are many decent developers who if they really give dart a proper go, wouldn't much prefer to work with it than JavaScript.


False comparison to ES.Next. Once you accept cross compiling as a premise for Dart the comparison is to every other innovative/productive language out there.


This is only about the Dart VM, not about the Dart language. Everything that’s great about the Dart language is still great, including all of its advantages compared to Javascript, perhaps the single biggest one being Dart’s sane and logical syntax compared to JavaScript’s.

Just because JavaScript is the de facto runtime of the web doesn’t mean we all have to develop in it. I’d much rather write in Dart (or CoffeeScript, TypeScript or whatever) than JavaScript—and then only I have to.


> This is only about the Dart VM, not about the Dart language.

The writing is on the wall already. If Dart hasn't the chance to become a natively supported language, why would anyone pick it as a compile-to-JavaScript language, given there are so many superior options?


> If Dart hasn't the chance to become a natively supported language, why would anyone pick it as a compile-to-JavaScript language, given there are so many superior options?

I don't think that the premise ("given there are so many superior options") is a non-controversial assertion. Which is probably why people who reject it would (and have been) picking it as a compile-to-JS language for web-facing projects.

The focus on compile-to-JS and JS interop for the web announced in the blog post makes Dart a more, rather than less, attractive language for web development, because it eases fears that taking full advantage of Dart might, in the near future, mean "works better on Chrome" rather than "targets the whole web", and because it means that Dart will work better with the universe of browser-targeted tools that aren't all written in Dart.


Dart is natively supported outside browsers. There is the standalone VM, which you can use just like Node.js, and the VM library, which you can embed in native applications.

The VM is crossplatform and it even supports ARM and MIPS.

They are also working on an interpreter which will get around the JIT restrictions on iOS and Windows Phone.


So why would I use this given there are languages which

  - are much better than Dart,
  - run in the browser and
  - run on a crossplatform VM which is much better than DartVM?


I think the obvious answer is that some people disagree with your first point. I think people should be programming in whatever language makes them happiest. For you that may not be Dart. For others, it is.


For me, it is.

Well, its semi-useless enums suck, but other than that I'm quite happy with it.


Nobody on this thread agrees with you that there are "so many superior options".

As far as I can tell, the Dart team set out to create a clean slate approach to what web developers need in a language (front-end and on the server) to address today's complexities. What the Dart team couldn't foresee how many developers would come down with Stockholm syndrome regarding JavaScript.

What people don’t get: adding more crap to JavaScript doesn’t make things easier, it makes things more complex. Think about it: the entire web is depending on a language that was thrown together in like 10 days and renamed from LiveScript to it would contain the word 'Java' because Java was the new hotness back in the day even though it had nothing to do with Jsva.

And now we’re going to add all of the stuff we didn't think about back then when JavaScript was considered a weird, fringe toy language, when the most complex thing anyone did was image rollovers.

JavaScript didn't "win" because it was great; it won because it good enough and we were literally stuck with it.

Not everyone wants good enough; some people want an excellent, purpose built language for the web with all of the goodies we’ve come to expect on Day 1--no polyfills, no hacks, no waiting for a years long standards process to run its course.

I’m looking forward to the Dart conference next month to see what’s next: https://www.dartlang.org/events/2015/summit/.


> Not everyone wants good enough; some people want an excellent, purpose built language for the web with all of the goodies we’ve come to expect on Day 1--no polyfills, no hacks, no waiting for a years long standards process to run its course.

Yes, absolutely; and Dart just doesn't fit that bill.


I find Dart to be far and away the best compile-to-JS language. That's more than enough for me.


Sounds more like you never actually checked the available options.


Sounds more like he has an individual opinion about the things that work best for him.


> given there are so many superior options?

If there are so many, can you list at least 5 superior options for us please.


What do you find superior to Dart?


Scala.js, Elm, PureScript, ...


I'm a big fan of Elm but it's still experimental. Major non-backward-compatible changes to the languages still happen sometimes in new releases. Not the same thing, really.

(Don't know that much about the others.)


Then pick Scala.js.

Solid, mature, great libraries and one of the best languages out there, even when competing against real (in the sense of not compile-to-JavaScript-only) languages.


People are different and not all thinks Scala is great language...


I'm unlikely to give it a serious try because I find the complexity of the Scala language to be pretty scary. Still, I'm curious: how fast is the compiler? Does it generate compact code? Clear error messages?


I started using Scala a few weeks ago. I'm finding it's pretty easy to ease yourself into it. So far I'm not doing much that I couldn't do in C#, but it's more concise in Scala. I was productive with it the first day.

I haven't tried scala.js yet, but I've gone through some presentation slides...they're claiming compact code that runs as fast as javascript, clear error messages that point to the line of scala sourcecode, and even some advantages over jvm scala (though I forget the details). Don't know about compile speed.


Compilation to JS is a few additional seconds during development, and the rest of your comment is right to the point.


Aren't those, with the exception of Elm, much younger and less mature than Dart? I think a language has to reach a certain level before the majority of people will use it in production. And the tooling should be stable also. I think PureScript looks great but it has a different syntax (Haskell like) which may make it a hard sell and I'm not sure they have any debugger at all. When you use a compile-to-js language I think the debugger and editors are important, at least if your language is not very close to js (which Dart is).


Whoo, seems I am getting old. Thats the first time I hear anything of those languages.


> My only worry is that the innovators behind Dart are going to be stuck on the Dart project while JavaScript gains their features and even more momentum. I would suggest that they let Dart die and not be stuck with it for years after it has stopped being relevant -- that would be a waste of their talents as they did really see what the future would be.

I am somewhat sympathetic to what you are saying here. OTOH, the fact that the web is basically all one programming language[1] is a situation that I find a bit unfortunate. Why shouldn't the browser have a PL ecosystem as rich as the desktop? And why couldn't Dart be part of that?

[1] Yes, I know the world is full of compile-to-JS languages. But still, being a web developer today mostly means being a JS developer.


I know absolute fuck-all about dart, but I do know that a programming language is just a tool. At the end of the day, a good programmer should be able to learn to use the best tool for the job, even if that tool resembles a swiss army knife.

It's apparent that Javascript has taken cues from nearly every other modern programming language at this point. The leaps and bounds being made with ES6 and ES7 are simply astounding. Of course, I have no problem seeing the development of languages like Dart, Coffeescript, and Typescript that compile to javascript, but I think there's an argument to be made for the reduced need of these. The development effort being poured into them has shaped javascript, but I think what many people are realizing is that the focus doesn't need to be on creating new languages that compile to Javascript, when it can be on advancing Javascript even further.


>I do know that a programming language is just a tool.

I'm probably going to sound very negative in saying this, but I _really_ hate it when people pull this line out like it means anything. Only in the most narrow, trite sense is a programming language "just a tool." They are the whole reason programmers exist. Language is the single most important development in human history, and computers have touched human life in irreversible and undeniably important ways.

Everything is just a tool, if you look at it the right way, and it takes a particular kind of pointlessness to opt to see the world like that.

Language is the thing that makes the genie grant your wish. If you wish with the wrong words, you get a billion dollar tombstone.


I just wonder, relatively, how big is the part of the ES6/7 driving community which were the people who hated on CoffeeScript because it required a compilation step (and now they love BabelJS). There will be things which you will always hate about JavaScript, visible, on the surface, and that will never go away. Compiled-to-js languages can hide these. This has been the best part of CoffeeScript, where it really shined, and this will carry over future compiled-to-js languages (PureScript, Elm etc.).

Unless it turns out that JS+Flow is actually the best balance between flexibility and safety and the world will reach "singularity".


I don't remember much of an objection to CoffeeScript on the grounds that it requires a compilation step.

For example, here was my statement advising Discourse to avoid CoffeeScript in 2013: https://meta.discourse.org/t/is-it-better-for-discourse-to-u...


> but I do know that a programming language is just a tool.

So I take it you write all your *nix programs in C?


> So I take it you write all your *nix programs in C?

That's the only sane answer if you have any intention of redistributing them.


> a good programmer should be able to learn to use the best tool for the job...

So you think JavaScript is the best tool for the job? I don't think so.


I'm not sure you can argue that Dart is where these features are coming from. SIMD and known type shapes are both very old features that people have been demanding for years. If you follow es-discuss the language you see referenced the most (other than academic ones like E) is C#, by far. The Typed Objects proposal dates back to 2013, possibly earlier, and it's a feature people have wanted for longer than that (ES4 arguably addressed it.) Dart certainly helped influence the SIMD proposal, however, and that's great - it seems like that might have languished for years otherwise.

Regardless, Dart is a great proof-of-concept for strong typing in a browser environment and I'm sure it helped renew faith in it after the disastrous results of the ES4 effort.

I would be interested in seeing Dart's approach to typing attempted as a layer on top of JS. Sort of a 'stronger' TypeScript where the compile pass enforces the kinds of type guarantees Dart provides, perhaps.


To be fair, SIMD in JS was kicked off by John Mccutchan who was on Dart and soon after joined Dart VM team. While there was appetite for SIMD in JS (Brendan, in particular, was a big proponent of John's proposal), I think it wouldn't have happened when it did without Dart and his work.


Confirming what Paul writes here. John tweeted, I tweeted back, here:

https://twitter.com/BrendanEich/status/308343704194781186

SIMD is in all the SoCs of course, which means it has been on JS stewards' radar for a while now (remember River Trail? see my blog post, which had early Dart humor and Dash-memo reaction: https://brendaneich.com/2011/09/capitoljs-rivertrail/).

I worked at MicroUnity from 1992-5 on many high-risk things including a new CPU that was designed to do extensive SIMD and bit-moving instructions; using these in an instruction-level simulator, I implemented 64-QAM demod and Reed-Solomon error correction for the cable-net of the day (TCL, remember them?). Alas the CPU design was unrealizable in hardware.

SIMD has been around quite a while in hardware, so as KGadd says intrinsics for it have shown up in major languages. It was only a matter of time and the right person for JS, and John McCutchan did the job. Thanks, John!

Google funded John's work for Dart and didn't keep him from doing JS uplift, so thanks to Google too.


There is certainly influence in many directions. For example, some of the GWT and Dart compiler folks were inspired to do better by a presentation at Google about TypeScript, and ideas from AtScript were picked up by TypeScript.

"Just stop what you're doing" isn't helpful. People need to write code today, and we have solutions for them.


> "Just stop what you're doing" isn't helpful. People need to write code today, and we have solutions for them.

There is a difference between having innovators on a project versus maintainers.


Less than you'd think. Starting from scratch is easy at first since you have no users and freedom to do what you like. Maintaining a popular project well requires more creativity in some ways because design constraints built up over time.

Improving the web, in particular, requires that people think like maintainers and innovators.


I definitely agree that the impact of dart on ES6+ is perhaps the best reason for its existence; however, I don't think it has outlived its usefulness yet.

That said, I also hope that they reevaluate their position in the world in a couple of years once Javascript has advanced down the road blazed by eg Dart and CoffeeScript.

[also, Dart can just be thought of as an abstraction for the language of JS, and what problem can't be solved by just another layer of abstraction? :P ]


>what problem can't be solved by just another layer of abstraction? :P

Too many layers of abstraction. :P


> Too many layers of abstraction. :P

Not necessarily! That next abstraction may enable you to simplify your implementation, carving out lower layers of abstraction cruft.


A bit unrelated, but yesterday, after beeing fed up trying to fix unexpected behaviors of a js code base, i decided to rename my file .ts and compile it with typescript. Without doing anything, the compiler found type mistakes and variable declaration errors.

And now today i'm coding in typescript adding type informations wherever i think it could be useful, and looking at typescript documentation to see in which way i could refactor my code to make it safer.

That's probably the fastest migration process you could imagine. Maybe dart would be more popular if they chose that route.


Maybe you should use JSHint. You can configure your editor to run it automatically. It is a bit unfair to compare TypeScript with its compiler against raw JavaScript, when the JavaScript ecosystem has tooling, too. I am not argueing, that TypeScript is not the safer or even better choice, I am just saying, that a properly set up JavaScript environment could have saved you the hassle as well.


Interestingly, that's what Facebook's Flow type analyser is built to do: allow you to type-check normal JS code, and add types where needed in the codebase.

[0] http://flowtype.org/


Good! This will quiet the noise, so that everyone can focus on advancing Dart and its ecosystem. Let's be honest: getting the Dart VM into non-Google browsers was always destined to be far, far away if not impossible, regardless of the team's excellent work or Dart's merits. Getting it into Chrome is just a decision, but one fraught with perils, namely that our community has an arguably healthy aversion to go-it-alone on the web, and untamed fear amongst the hoards that Google will shove it down our throats does not bode well for Dart.

And is it really worth it? As someone all in w/ Dart (I chose to build my product with it), dart2js serves me well, and the resulting JS is said to be more performant than raw JS. JS itself is improving (see ECMAScript 6 and TypeScript), which means Chrome's compiled JS will improve with it. Of course, having the Dart VM in a version of Chromium they call Dartium has been important, as it eliminates the need to compile until I care to test on other browsers. But there's exciting work ongoing on incremental compilation, so that in theory you'd just see your results in any old browser (http://goo.gl/EHJcK9) a la interactive programming. Bottom line: the Dart development cycle is already great and always getting better, no VM in Chrome needed.

As well, the Dart team can focus on more important priorities: the incremental compilation I mentioned, better JS interop (it's not bad now), improvements like async/await (coming in 1.9), even better concurrency primitives (see Fletch), Dart for native apps (again see Fletch) and more.

And remember, this decision can change later when the climate changes or other factors are in play. But for now, it makes a whole lot of sense to abandon any push, or notion thereof, to get the Dart VM into Chrome.

IMHO, Dart (I mean the language, libraries and tools combined) is hugely underappreciated. Folks will continue to focus on improving it and building awesome apps with it, and this news should quiet some of the noise.


As the dust settles around this announcement, I'm feeling more positive now than in my initial response. I don't think Dart ever had a chance to compete with JavaScript on the browser, especially as JS is advancing so rapidly with ES6/ES7. I'm a strong believer in what the future holds for JS.

But Dart is something else. Dart showed us what JavaScript would have been if it were designed this decade, and with some thought to its architecture. It's clinical in its cleanliness (have a peek at its standard library and you'll agree). It was pitched as a full stack language for web applications done right, and I certainly felt it lived up to that claim.

Personally, I'm more interested in Dart as a replacement for Node.js. Luckily that dream is still alive: "We continue our strong investment in Dart VM for server, embedded, and mobile."


> dart2js serves me well, and the resulting JS is said to be more performant than raw JS

Actually on most of the official benchmarks, dart2js output is slower than normal JS,

https://www.dartlang.org/performance/

(normal JS is faster on 3, matched on 1, and slower on 1).

Of course, the usual caveats apply regarding benchmarks and real-world performance, especially since those 5 benchmarks are fairly small and probably not representative of large real-world codebases. I'm not aware of any good benchmarks for Dart on that (there is a Box2D comparison, but the latest update isn't recent).


> (normal JS is faster on 3, matched on 1, and slower on 1).

And I would be really skeptical about that 1 where they say dart2js is faster.

They removed a layer of indirection in DeltaBlue when they ported it to Dart (not due to any Dart language feature, just for no reason), then crowed about how dart2js made DeltaBlue faster than the original. Despite being made aware of it years ago, they never fixed this! But the JavaScript VMs got better enough to be faster even though running code with more indirection than the dart2js version based on the optimized port.

So when the one benchmark dart2js is faster on is one they say they rewrote because a direct comparison would be "unfair" it sets off alarms.


Compare the source codes for yourself. It should be obvious that OrderedCollection exists in the js version, left over from the original Smalltalk, and not in Dart. Dart devs don't like criticism.


> the resulting JS is said to be more performant than raw JS.

This claim always bugged me. The output of dart2js is raw JS. Same with CoffeeScript (which makes a similar claim). So these claims are totally reliant on parameters that haven't been defined, ie. what constitutes "equivalent" handwritten code?


Right, I hope people making this claim realize it's not possible in principle for Dart to always be faster.

I've always assumed claims like this are implying that average case code is written poorly and that's how It could be faster.

However as you point out we'd need all the assumptions made clear to believe such a claim.


it is up to every test to specify. I think they did explain what kind of hand written js they compared to and if I recall correctly the tests the dart team mentions is compared do js written by experienced js developers to solve the exact same problem. Of course there is a possibility that the hand written code could be further optimized but the comparison is still interesting.


What am I missing that makes this only a "possibility" rather than a certainty? For any Dart program found to be faster than a JS program, the JS program could be made equally fast by being equivalent to the Dart output, right?


By going through the dart compiler first they can do optimizations that you wouldn't do by hand. Google runs all their js through their Closure compiler for this (JS -> JS compiler) with a ton of optimizations turned on (constant folding, method inlining, deadcode elimination, replacing of multiline conditionals with ternary operator, etc, some of which I believe are in the open source version and possibly some proprietary).

In that case, they literally are writing JS and using a compiler to get JS that is faster than any normal handwritten JS would be. You could write your JS that way but it would be completely unreadable and unmaintainable.


Thank you for the clarification. I think we are saying the same thing.

In principle, it's always a certainty that JS can be written as performant as Dart, never just a possibility. The possibility part only comes in with respect how optimally the JS code is written.

The interesting part here is I think is how often does this happen? How often can significant improvements be made that would be impractical, or even unlikely for a developer to match?


I suspect that depends on your definition of significant. I suspect any legible code can always get a few percent speedup by doing things that would make it unreadable and unmaintainable.


"dart2js serves me well, and the resulting JS is said to be more performant than raw JS."

But is it more performant than raw Dart?


Maybe they'll build an asm.js backend for Dart.


Unlikely. asm.js, at least in its current form, isn't a realistic compilation target for GC languages as far as I can tell.

It may be possible to compile pieces of a Dart program that don't need GC (think pure numeric computation stuff) to use asm.js and use the full JS language for the rest, but I don't know if anyone's seriously looked at doing that.


Here's what I don't understand: why is there any focus on alternative VMs for specific languages? Surely all this effort should be going into a VM for some kind of highish-level intermediate representation that's trivial to generate from any source language? That way no language has a monopoly and there can be peace on Earth.

It seems odd to be arguing for generic computation abilities in the place where most "computation" is done nowadays. Can you imagine what could be achieved if the browser vendors and standards bodies put business considerations aside and spent a good couple of years designing such a thing? We could have an almost endless list of goodies: threads, code isolation, multiple number types...

Just like Intel, AMD, and the rest in effect control (much to Alan Kay's despair) hardware architectures, the vendors & standards bodies are a sort-of natural cartel controlling upwards of, what, 50%? 80%? the code end users actually interact with. The quality of the decisions they make has deep repercussions beyond the tech community and it's simply not possible for any of us to know what they all are. Even if they were bona-fide saints, this would still be too much power to tie up in such a small group.


Ecma TC39 is working on all the goodies you mention, and more (yes, even threads with shared ArrayBuffer memory). In a couple of years, you might have some of them in top JS engines.

Starting fresh would take many more than two years, and very likely end in tears. This assumes browser vendors could spare the effort to do JS and the new thing (most cannot, even Google arguably can't).

For why the best VMs are focused on one language, see

https://www.dartlang.org/support/faq.html#q-why-didnt-google...

and

https://www.dartlang.org/articles/why-not-bytecode/

from the Dart team. See also

http://mozakai.blogspot.fr/2013/05/the-elusive-universal-web...

from Alon Zakai of Mozilla.


Those links are very interesting, I didn't know it was such a common question.

However I still wonder - is bytecode the only way to go about this? Every compile-to-JS language I've used has either been sugar over JS or had JS's semantics/syntax seeping through the cracks...what if the base language was a Lisp? There's a big difference between being bound to the semantics of a language like JS or dart and those of Lisp.

I have no doubt that a new VM would be a herculean undertaking and be riddled with all sorts of problems, but I remain unconvinced that it wouldn't pay off in the end. Maybe I'm being naive, but if what we're doing now really is as good as it gets then it seems either I'm much more ignorant to the issues at play than I thought or this hole is significantly deeper than even I imagined.


JS's syntax wouldn't seep through (backward?) into the compile-to-JS language, which would treat it as safe assembly. You're right that semantic gaps in JS could make the compiler for Blub fall into the Turing tarpit, needing costly runtime -- see Babel's "spec" vs. "loose" (I hope I have those right) modes. The answer here is to fill semantic gaps in JS, which we're doing in TC39.

Evolution can fill gaps in JS, and has: typed arrays are one example; generators another. More to do, but it's not as if the distance x cost to suffer in filling gaps is greater than the distance x cost of doing a de-novo VM among all browsers, on top of keeping JS going. It's much, much less.


Slowly evolving a huge platform to keep backward compatibility at all costs is how Microsoft runs many of it's properties. At some point I think an Apple is going to come along and take a byte out of the HTML/CSS/JS hegemony by introducing a new type of browser that is easier to build applications with.

At least I hope so! As long as the web remains a broken mess of designed-by-committee compromises, I think there will, at least, always be some motivation to invent a replacement. Maybe you disagree that what we have is broken, but maybe you also know too much to think that building something new is a good idea. Many people have succeeded though, by being ignorant of the fact that X seems like a bad idea to the experts.


> Here's what I don't understand: why is there any focus on alternative VMs for specific languages? Surely all this effort should be going into a VM for some kind of highish-level intermediate representation that's trivial to generate from any source language? That way no language has a monopoly and there can be peace on Earth.

I've always wondered: why not LLVM? It's low-level, so the speed is there, and I think should be trivial to compile as it arrives at the browser. Tons of stuff already compiles to it. You can compile it to JS. Of course, you'd need to make sure it doesn't make a syscall that's not allowed (and I'm not sure how hard that is), and that it has bindings into JS APIs and/or the DOM, but aside from that…

I'm sure some people will suggest things like the JVM or the .Net CLR, but I feel like those have certain qualities (e.g., GC) that don't appeal to all languages.


> I've always wondered: why not LLVM?

Because LLVM is not hardware independent.


Also, LLVM IR has undefined behavior and was not designed as a network format (it's large).

LLVM is simply not a good starting point for the problem here, nice as LLVM is for what it does do well.


That didn't stop PNaCl. (Which has its share of problems, of course, but I think it makes the hardware dependence meme pretty moot.)


PNaCL is probably closest to what you want.


I have been wondering the same thing. JS might be a good language. But we should still have a choice to choose other languages.

I'm seeing efforts with asm.js turning JS into a byte code language aka. LLVM IR. I'm not sure if turning JS into a byte code language is the best way either. It is still too high-level language. And it seems like a ugly hack.


There was a talk by Matz about ruby 2 and how they were tweaking the runtime to improve garbage collection. I don't remember the details but a lot of work went into seeking the best collection behavior to match the language, optimizing for the most common cases, checking the patterns favored by the language and tweaking the behavior to ease these cases, etc.

The intersting thing is that there's jruby for the JVM, and it makes the different tradeoffs surface better. Looking at this benchmark for instance [0] it's easy to see how the tweaked runtime gives a very different performance profile from the generic VM.

I have a feeling the highish-level intermediate layer you are talking about would be equivalent to have only some specific tradeoffs despite the optimizations that could be done on a language per language basis.

[0]http://benchmarksgame.alioth.debian.org/u64q/jruby.php


Agreed. A more generic VM seems the way to go.

.NET's CLR does well supporting a wide array of different languages very well C#, F#, IronPython, IronRuby etc


I agree, I thunk this isnt being done because browser vendors believe that the intermediate common language is Javascript and that if they fix JS performance they are killing two birds with one stone. This isnt true because JS lacks many features like synchronization primitives.


Synchronization primitives are being suggested for addition to JS,

https://blog.mozilla.org/javascript/2015/02/26/the-path-to-p...


Spelling is hard on my cellphone. Would be nice to have a longer editing window.


This isn't surprising. Dartium has always been a nifty project, but you'll never get all the major players to agree on a radical change like this. It was always destined to be a "second VM" like VBScript.

asm.js illustrated the right political approach -- build something that degrades nicely now, then get the vendors to optimize it.


asm.js, CoffeeScript, etc are all great examples of evolving development for the web by compiling to JS.

Dart is new 100% committed to that model for targeting browsers.


Agreed. I just changed "Dart" to "Dartium" in my comment to avoid confusion as I realized that it wasn't clear.


So what if all the major players don't agree to it? Someone has to take the initiative.


The Internet isn't a technology; it's a collection of standards. Much like the industrial revolution wasn't about mechanisms; it was about interchangeable parts and standardization of forms, such that they could be usefully combined without eternal one-off customization.

In the short-run, your approach is sound. In the large, a web technology isn't a web technology if my browser doesn't support it. Seems that the people in charge of Dart decided it had crossed the event horizon from situation 1 to situation 2.


I get the impression that other browsers have committed to never supporting NaCl or Dart, so taking the initiative to build a prototype in Chrome wouldn't help.


Not even Google took the initiative. Why didn't Google integrate the Dart VM in Chrome instead of Dartium?


I'm saying that Google should have integrated the Dart VM into Chrome even if it won't be supported by the other browser makers.


Imaging a world with each browser vendor implementing his own incompatible scripting language ... Oh wait it happened in the past and it was so ugly people used a plugin called Flash that ran the same way in every browser ...


So I am assuming you agree with the approach that Microsoft took with all the IE specific features back in the day ?

I know it resulted in some very useful features e.g. AJAX but surely a standards based approach is infinitely better.


I believe a lot of Dart criticism comes from people who haven't actually used it. I personally find it almost always more enjoyable than JavaScript. I've also used other languages that transpile to JS but there some features that I find superior in Dart:

1. Tree shaking. The compiler can detect unused code and remove them automatically from the JS output, resulting in smaller files. (Yes I know that Hello World is a bit big, but real projects are not hello world)

2. A really nice IDE with autocomplete, error highlighting, code formating, refactoring, debugger, profiler. It really makes a difference.

3. A VM that's actually faster than JavaScript useful for writing server side applications.

4. A nice an well integrated standard library.


They're putting a positive spin on it, but it seems Google decided not to focus on Dart, considering all the other javascript's they're invested in.


We try hard to avoid spin.

From the article:

Google Ads, one of Dart's biggest customers, is committed to Dart and supports this new strategy. Scott Silver, VP of Engineering for Ads, says, “We are committed to building our next-generation web apps with Dart, and a renewed focus on generating optimal JavaScript helps us deliver great apps to everyone with a modern browser. Dart has significantly improved our engineers' productivity and our ability to quickly launch and iterate. We currently have one million lines of Dart code and the number is growing fast.” Many other teams inside of Google, such as Google Fiber, Google Express, and Google's internal sales team, use Dart for business-critical apps.


"We realized that the goal of putting Dartium in every browser was monopolistic and made us look bad, even if we had good intentions" would be avoiding spin.

This is a setback for Dart and Dart's mission statement, and everyone knows it, and everyone also knows it's been a long time coming.


one million lines of Dart code? All this work for displaying ads on the web. Something is not right with this world...


"Ads" is a short word but it covers a lot of complexity. There different formats for ads, different kinds of ad customers, different places where ads can be displayed, different ways of buying and selling ads, and then you have localization to different countries, etc. There are complex UI's that automatically reconfigure themselves based on the customer's needs.

A million lines of code is relatively small when you're trying to be all things to all ads customers in the world.

Still, could it be simpler? I hope so.


I read Google Ads as the business unit, not the "displaying ads". I don't really know how anyone would read "Google Ads" and "million lines+" and think wow, all that for banner ads?

Alas, I'm writing this and reading the above..


They make like $72bn annual revenue off the back of that product though so in terms of revenue per line of code it might not be too bad! :)


You do know that is how Google makes money, rigth?

If it doesn't serve ads it doesn't release cool open source projects no self driving cars, no Anjular JS, no google maps, gmail and so on.


Hey, it makes the world go 'round. Bash it all you want, it provides a useful service to businesses.


Google Ads uses Dart for their next-gen web interfaces. That's a good committed user for us to have as a partner. :)

[disclaimer: I work on the dart team]


Does the Google Ads team use Dart on the server-side? The Dart blog post was unclear about the future of the Dart VM.


> Does the Google Ads team use Dart on the server-side?

This, alas, falls under the "nothing to publicly announce" umbrella.

> The Dart blog post was unclear about the future of the Dart VM.

The VM team is still moving full speed ahead. In some ways, their job is easier now because they don't have to worry about the (considerable) complexity of integrating the VM into a very large application that already has another language VM, GC, very large set of API bindings (the DOM), etc.


It's great to see that JavaScript (and the runtimes) are becoming better and better at being a sensible compilation target.

As JavaScript performance and semantics improve over time all the compile-to-JS languages benefit (Dart, Clojure, TypeScript, CoffeeScript, Elm, Scala, …). Win-win.

I'm looking fwd what the Dart team with all their experience in runtimes (& v8 specifically) can pull off with dart2js.

While I would have loved to see the Dart VM included in Chrome I believe we (the web, developers, …) are all better off with this new direction as this way browsers aren't becoming even more complex than they already are.


Google has always been pursuing a two-pronged strategy with respect to JavaScript: 1) improve JavaScript and 2) work on new and better language. What's changed is how programs written in the new language are delivered to users.


Indeed, I was hoping for a new scripting language, and if someone was going to do it would have been Google. We're stuck in a JavaScript only world until something replaces the browser ten or twenty years from now. With (nice) ECMASCript 6 and 7 changes coming and the growing use of (problematic) to-Javascript-compilers and (buggy) source maps, the will to get real language diversity on the web is just dead in the water. I don't want JavaScript everywhere. I like when there are multiple programming languages available.


I'm disappointed. Where is the innovation? We'll be stuck with JS forever.


I was on the Dart team for a while, and even then I felt the best approach to the VM was for the language to become popular first, and for developers and users to demand a native VM.

Dart still has a long way to go towards being mainstream, but I think this will help reduce some of the controversy surrounding it and people can focus on what it brings to developer productivity and app quality.


This comment is taking me off the ledge on Dart a bit. I really felt doom and gloom over the announcement but this makes sense.

I hope this happens. Javascript seems like a depressing future to me - even if it's only a compilation target for major shops.


To me, "JavaScript and Dart" would also be a depressing future. You may hate JavaScript and like Dart, but there are a lot of people who hate both of them and would prefer CoffeeScript or Elm or purescript or JS+macros (sweet.js) or C# or C++ or ...

IMO it is much better to focus on improving compile-to-web support with things like bytecode, better debugging, threading, custom value types, hooks into the garbage collector, etc., etc. - making it feel more like "compilation", less like "transpilation" (to the extent the term implies that you have to look at the output) - than to change the number of blessed languages from one to two. The result, if used to compile Dart (or any other language), might sacrifice a bit of performance compared to the maximum achievable by a dedicated Dart VM, but not that much, and there are myriad advantages.


Really I wish Dart VM were, like the JVM, made to be a platform to be built upon instead of a VM for a single language.

But in the meantime I'd prefer Dart to JS.


Dart is the innovation.

Of all the developers I know that I went to university with a few years ago all with just a few exceptions have moved on from vanilla-js to compile-to-JS languages by now (Dart, Clojure, CoffeeScript, TypeScript, …) and the others are on the fence.

What we need is for JavaScript to become a better compilation target and for even more language innovation. Dart is the most ambitious compile-to-JS option. Take a look at Dart's stdlib, packages and support in IntelliJ.

The better dart2js gets (it is really good by now but I can't wait to see how more focus on it will take it further) the more scenarios where Dart can be used in. Just think about all the places that come with a JavaScript runtime nowadays.

Just think of how the JVM allows people to write Lisp/Clojure in enterprise settings. Having a better and better dart2js story allows people to use the tools they prefer without hitting a bureaucratic wall ("compiles to js? fine.").


> Dart is the innovation.

> Dart is the most ambitious compile-to-JS option.

Wait WHAT?

Not sure if this is supposed to be irony, but if not I'd like to understand your opinion on this.


You're being downvoted because you're adding much more heat than light to the conversation, not because your ideas are taboo.

I'd recommend instead a comment like: "Consider $otheroption, it has $feature1, $feature2, and $feature3. Furthermore, it is entirely committed to $designprincipal, which provides complete safety against $classofmistake when used correctly, without any $kindofdownside."

This way your reader has something to engage with other than your emotional reaction, and they may have learned something along the way.


You can use Go and compile it to JavaScript. I've been doing that the last year.

I gave a talk about it recently if you want to see.

https://www.hakkalabs.co/articles/getting-started-gopherjs


You can also use C++, Java, Kotlin, C#, or almost any popular language. Compiling to JS is not an innovation its a hack and a testament to how terrible the language and ecosystem is.


It's more of a testament of the intellectual laziness of some devs to pick up the language and put real efforts to master it.


Making a conscious decision not to use an inferior language is far from laziness. It's a productivity-oriented decision.


No one is forcing you to write in js. You can write in any language you want and then compile to js.

Why you have such intense and strong feeling toward a programming language?

It's just a programming language after all, nothing more nothing less


I have zero feeling one way or another towards javascript as I made a conscious choice not to deal with it - I write Python and Lua for a living. Just like I made a conscious choice not to deal with PHP, I care very little what happens to PHP.

You're very much the one with the "strong feelings" there, accusing "intellectual laziness" for not putting real efforts in a language which is simply not worth anyone's time - not to mention assuming that people who think the language is inferior actually use it.

As I said, it's a productivity decision. The opposite of laziness.


which is simply not worth anyone's time

If you wanna do any consumer facing web stuff, you gotta code in js in one way or another. So, if you don't do any web stuff that's fine but other people doing any serious front or back end web stuff have to master the language to get the maximum out of their work.

Anyway, good luck with your darling langs


I very much work on frontend as well. I just use coffeescript or dart when I need to. You seem to be missing the entire point of pretty much all the comments, and you keep making more assumptions.

You're 0 for 3, yet you're still acting smug. I'd take a look into that if I were you. Take this as general advice.

Edit: I saw your comment below - I'm done replying to you directly, you're probably not a troll, but it's sad that you behave like one.


So, in a previous statement you said you code in Python & Lua and now you say that you code in CS/Dart which are more or less dialects of js.

You seem very agitated and disturbed for no apparent reason. We're discussing prog langs after all. Maybe you need to explore sports or politics to vent your anger as it's building up and you might explode anytime :L:


Following your logic, all "masters" should code in assembler?


No major language implementation that I'm aware of compiles to assembly. Maybe you are referring to machine language and/or bytecode, which are not targeted at humans, so the 'masters' should not code in them because the 'masters' are humans. Advanced Javascript has many capabilities such as first-class functions and great introspection because of the way objects are. The fact that there is a lot of shitty js code around doesn't make js a shitty language, just like the tons of shitty C from our Commodore-64-childhood don't make C a shitty language.


> No major language implementation that I'm aware of compiles to assembly.

I believe 'gcc -S' would demonstrate not. If my understanding is correct, it produces essentially asm internally regardless of that flag, but subsequently assembles and links it without presenting it externally, -S just makes it stop and dump the asm.

No idea about other C compilers, but it wouldn't surprise me if they have some similar feature.


It is very common not just for C compilers, but for a long range of other compilers.

So common that it is unclear to me which of producing textual asm output or machine code is most common. Certainly there's been periods were the attitude was that producing machine code directly was unnecessarily complex and didn't belong in the compiler.


Correct. GCC always produces assembly and shells out to as; Clang originally did the same, but now goes straight from an internal representation to machine code by default, with the old behavior as a flag. Not sure about other compilers.

In addition to being wrong, the parent's point is also incredibly nitpicky.


Yes I've been reading a bit about GCC and yes, turns out I was very wrong. I'm sorry that my comment sounded overly critical, I was actually trying to defend JS and opposing the idea that somehow "we need to fix JS". Having said that, I can see why there exists a need for "compiling" from other languages to JS - the latter being the only alternative when it comes to running code in a browser - even though personally I consider it unnecessary overhead.


Went through the slides and this is really great. I'd like to read more about code size and performance issues. (Things to avoid, etc.)


JS is getting nearly every Dart feature with ES6 and ES7 and whatever typing system makes it into the standard. There is massive JS innovation going on if you look at the future standards coming.


> JS is getting nearly every Dart feature with ES6 and ES7

With ES8 or ES9, maybe.

By the way, optional named arguments with default values look atrocious in ES6.

ES6: function foo({a = 1, b = 2} = {}) {…}

Dart: foo({a: 1, b: 2}) {…}

Dart also supports things like factory constructors, named constructors, method cascades, operator overloading, SIMD, arbitrary large integers, mixins, implicit getters/setters, implicit interfaces, enums, 'a' - 2 is a type error, [0][-1] is a range error, metadata annotations, and of course also optional types.

ES7 might include SIMD and operator overloading.

Another key point is that Dart's doc comment syntax is standardized. It also has an official style guide, a formatter, and a package manager.

To me, these things are also very important features.


They should take the bad stuff out of JS too then.


They are via Strong Mode and SoundScript: https://developers.google.com/v8/experiments :)


Dart's just as important for what it removes or changes in a breaking way as for what it adds.


Just today I was reminded of how terrible JS is:

       new Date(2015, 1, 1)     
Guess what date that object represents (hint: It isn't January 1st 2015).


To be fair to JavaScript, whilst it is a terrible language, the specifics of the Date API were almost certainly based on the designs of the Java Date class, which is possibly the worst class known to humankind.

http://stackoverflow.com/questions/1969442/whats-wrong-with-...


Brendan has confirmed many times that they were instructed to copy the Java Date API exactly. Here's one: https://brendaneich.com/2011/06/new-javascript-engine-module... "Ken Smith, a Netscape acquiree from Borland, ported JDK 1.0-era java.util.Date (we both just drafted off of the Java truck, per management orders; we did not demur from the Y2K bugs in that Java class)."


Is it that you don't like zero-indexing, or that you don't like it together in the same function with one-indexing? b^)

Actually I think it's pretty terrible how few languages have literal expressions for dates. Once you have to type "new Date(", it's not much more annoying to have to remember that January is zero.


Apropos, you can easily make your own date syntax in Dart:

  class Month {
    static const List<String> names = const <String>[
      "JAN", "FEB", "MAR", "APR", "MAY", "JUN", 
      "JUL", "AUG", "SEP", "OCT", "NOV", "DEC"                                                    
    ];
    final int month;
    const Month(this.month);
    MonthDay operator -(int day) => new MonthDay(month, day);
    String toString() => names[month - 1];
  }

  class MonthDay {
    final int month;
    final int day;
    MonthDay(this.month, this.day);
    DateTime operator -(int year) => new DateTime(year, month, day);
    String toString() => "${Month.names[month - 1]}-${"$day".padLeft(2, "0")}";
  }

  const Month JAN = const Month(1);
  const Month FEB = const Month(2);
  const Month MAR = const Month(3);
  const Month APR = const Month(4);
  const Month MAY = const Month(5);
  const Month JUN = const Month(6);
  const Month JUL = const Month(7);
  const Month AUG = const Month(8);
  const Month SEP = const Month(9);
  const Month OCT = const Month(10);
  const Month NOV = const Month(11);
  const Month DEC = const Month(12);

  main() {
    print(MAR-25-2015);
  }


Kudos! Truly, Dart has redeeming qualities! Incidentally, this code is the best argument I've seen for "American-style" date writing, with the month first. Or would it be as easy in Dart to override integers with a "DayMonth" operator?


I have no issue with zero-indexing. It is just inconsistent. Either everything should be zero index or nothing should. In this case nothing should.


I assume that first versions of JavaScript were written in C, and that's where this comes from:

http://www.cplusplus.com/reference/ctime/tm/

tm_mday = day of month (1-31) tm_mon = months since January (0-11)

Which AFIAK goes all the way back to POSIX standard.

The real problem is that JavaScript as higher level language decided to inherit this awkward convention instead of making their own, consistent rules.

Given the time it took to create the first JS implementation, it is no wonder that some shortcuts were taken.


Yes, that's the strangest, most inconsistent model anyone could come up with.


They could use the Japanese calendar.

  new Date(Heisei, 27, 1, 1)


Any function with positional parameters can look awful taken out of context.


Can you clarify what you mean? The three parameters are year, month, and day. Which I think is fairly intuitive.

The problem is not with parameter ordering. Year and day are literal, month is zero indexed. So you wind up with (month -1) representing the actual month.


Don't you know already the rules governing date-time in js?

It seems to me that you are not doing your homework and studying hard to get things done professionally.


The innovation also happens in ES6, TypeScript, and AtScript.


> and AtScript.

AtScript is dead now. The Angular folks are switching to TypeScript.


Well, they are merging all features of AtScript into TypeScript, which is a great idea. Less fragmentation will simplify adoption of JavaScript typing.


Always bet on JS.

And innovation is right here: http://babeljs.io


Not true. Javascript is being forced to evolve by Dart and CoffeeScript and others who are finding a way better development experience. Where we end up is another thing altogether - to me it looks like Java and Javascript are on a path to convergence.


It's not JS is the only thing in the world of computers which is around largely because it picked up enough momentum to have people try to improve on it rather than replace it.


you wont be stuck with JS forever! I'm working on a super-productive functional language I think you'll like. Couldn't find your email. Mine is cammarata.nick@gmail.com (would rather not post link just yet)


Very pleased to hear this. I'd much rather have resources funneled into making v8 and JavaScript in general more performant. It already has so much momentum behind it.


The problem is still that even with Dart we have so little choice of languages. What is needed is a way to implement any language of choice on the web, probably through a sandboxed low-level virtual machine that supports threading, and which has no garbage collector (so languages can implement their own if desired).


> which has no garbage collector (so languages can implement their own if desired).

The problems with that are:

1. It means every web app basically has to push its own GC down the wire every time the user hits myawesomeapp.com. That's a lot of overhead.

2. You'd have to define what the memory model between the code running in the VM and the browser's native stuff is. What does it mean for the code to have a reference to a DOM element? How does the browser hold a reference to an event handler in the VM?

3. The set of people who can implement an efficient GC is very very small. Forcing each source language to do that themselves wastes a lot of effort. (For example, look at how primitive Python and Ruby's GCs were for most of their histories.)

Now a low-level VM with GC. That's something I'd be excited about.


Interesting points.

1. Caching, content-distribution-networks, and possibly shared-libraries could solve or at least ameliorate this.

2. This is relatively easy. The sandboxed code could "open" handles by calling into an API, and the code could "close" them when no longer needed.

3. In many cases, the GC is tied intimately to the semantics of the language, so enforcing a style of GC could be too limiting in terms of performance. Instead, it could be better to implement a GC'ed VM on top of the low-level one.

The biggest problem is to get something like this turned into a standard, and accepted in all browsers. Perhaps a viable route is to write the standard of this low-level virtual machine for the web (LLVM/W) on top of ASM.js (and implement threading by emulation), and then wait for general acceptance, and for browser vendors to implement LLVM/W directly.


> 2. This is relatively easy. The sandboxed code could "open" handles by calling into an API, and the code could "close" them when no longer needed.

That's easy to specify, but is it good for the user? You've just opened the door to memory leaks on my machine in poorly-written "javascript".


Contrary to popular belief, it is still possible (and in fact very easy) to have memory leaks with a GC. Consider for example this situation: fill a list with a large number of items, and hold on to that list, without ever accessing the items again. In principle, the contents of the list is "unreachable" (since the code never re-visits the items), but the GC isn't aware of this (too difficult to prove) and conservatively assumes that the reference to the list means that the items in it can still be accessed.

So, even in Javascript, it is very easy to have memory leaks.

The main way to deal with this, is to simply set a limit on the amount of memory a browser-tab can use. This limit can be dynamic, and depend on what other tabs (or processes) are doing, but it doesn't need to be. This is also the current way browsers deal with this problem.


What you are describing could be achieved with asm.js, together with threading as proposed here:

https://blog.mozilla.org/javascript/2015/02/26/the-path-to-p...


Yes, I'm aware of this. But what this lacks (imho) is the simplicity to keep the whole system reliable and secure.


Isn't that NaCl?


Almost, because NaCl is only available on Chrome/Chromium.

I guess what we need is something that can be efficiently mapped onto ASM.js (while emulating threads), so that we can transition from the situation where only one browser supports the code to the situation where all browsers support it (and then ASM.js isn't needed anymore).


This is a great move by the Dart team. There is now a single story for the web development, their efforts can be more focused, and accusations regarding trying to break the web will stop. Win-win-win.

After developing with Dart for quite a while, I can just not see myself going back to JavaScript, the platform is just that much better.


Lets instead try getting the Qt QML engine integrated into browsers. I'd love to write webapps in QML instead of mutant document markup =P.


Never let go of your dreams! If you start a petition I'll be the first to sign it.


Good. We don't need another VBScript. Whatever Dart's technical advantages, the standard for browser scripting is Ecmascript. Use it as a compilation target. Don't go breaking the Internet. We don't need another Internet Explorer.


So I'm pretty disappointed now. I didn't hear the reasons why they ditched Dart? Compilation to ES6/7 cannot be the technical reason, as there is a huge run-time and memory overhead by using only ES6/7 compared to Dart. Looks more like a marketing decision, Dart not have gained enough momentum or such.


> I didn't hear the reasons why they ditched Dart?

They didn't.

They ditched plans to integrate DartVM into Chrome from browser-side Dart in favor of continuing to use dart2js for browser-side dart.


Actually the decision was mostly technical and logistical.

I'll have a post up about it soonish at http://work.j832.com


I'm really excited about this new direction.

I also hope some great Mozillians will take a second look at Dart now that the main objection (adding another VM to Chrome) is out of the way.


Let Dart stay and transpile. Let them continue to make Dart better. Even if it exists only to transpile into JS like CoffeeScript and TypeScript and not run natively in the browser -- as long as they keep innovating with the language, the ideas can inspire the next version of JS with ES8 and beyond.

Evolution by inspiration.


Another twenty years of JavaScript. Joy.


It's like Cthulhu instead of a groundhog…


Would you really have been happy with a monoculture based around a very similar but slightly different and less mature language if it had gone the other way?


Why would there be a monoculture? JS would still exist for a good while after that, and if anything, it would've likely inspired more competition to flourish in the browser space.

Secondly, while the language may appear similar, a large number of its strengths come from actually breaking away from the JS ecosystem, and daring to take the 'less mature' approach. Without all that legacy, it turned out with significantly cleaner libraries and APIs, more intuitive semantics, and and an ecosystem+workflow is worlds apart from the JS style. The difference a few small changes can make in simplicity to lower cognitive overhead is astounding. Building a large, complex app in dart actually feels totally manageable! Yet, regardless of how many new JS tools and libraries come out, it always still feels completely overwhelming. Thankfully they decided to keep this part of dart in tact.


It seems logical since no other browser is going to support it. Although it is kind of a shame, as it is clearly an improvement over Javascript, the writing has been on the wall for a while.

Considering the lack of other browsers jumping on board, I think it is better that Google gradually phase out Dart and let everyone concentrate on making Javascript better (both by improving the language itself, and the libraries). I predict they will stop new development entirely within a few years.


This has been pretty much inevitable from the beginning.


This wasn't inevitable at all; you're not giving Google enough credit. They could easily have decided to force Dart VM into Chrome and that would have been bad for everyone.


Like it was with SPDY?


Apparently that was a touch too glib.

But where was the "bad for everyone" when Google rolled SPDY into Chrome and its own services, and showed not only tangible improvements to HTTP/1.1 but also an actual conviction in its efforts? It took a few years, but there was a good amount of industry momentum behind SPDY even before its ordainment as HTTP/2 became certain.

All Dart ever got was a Chromium fork; how was it ever meant to make inroads without Google putting any wood behind it?


I like SPDY and I don't like Dart VM; I think that reflects the broader consensus as well. Dart VM just isn't better enough to justify switching the entire web to it. SPDY is.

Personally I wouldn't support any proposal for a new web VM unless it could achieve no-compromise full-speed execution of transpiled C/C++ code in the web sandbox. That's the #1 most important feature and #2 isn't even close.


JavaScript as a compilation target should only be a temporary measure.


Probably not. While it wasn't intended to be so, JavaScript has become the lingua franca of web browsers and is therefore heading towards a future of being a compilation target. If your program can't compile to JavaScript, it doesn't really run on browsers (in much the same sense as "If your program can't be compiled to x86 assembly, it doesn't really run on computers").

https://www.destroyallsoftware.com/talks/the-birth-and-death...


It seems to me that we should really be looking for browsers to compile (or at least appear to compile, even if they skip this as an optimization) Javascript into a lower-level 'assembly' language, so that Dart can be made to compile to the same form. A LLVM for browsers, basically.

JS is a terrible assembly language. But the work that's been done on making it passable for that purpose is remarkable, so we're getting by with it.


You have to ask yourself if it's easier to get all browser vendors to agree on an intermediate language or to get them to agree on new apis that makes javascript better for that purpose.


It's easier to make them agree on an intermediate language. Mostly because one can make such VM as a BSD licensed plugin.

Just make the DOM available as some virtualized "system calls" and you'll avoid the fate of Java and Flash.


What's a plugin?

Is that one of those things that "nobody" willingly installs in their browser unless they absolutely have to because much of the market doesn't even understand what they are and the ones that do still want to avoid them because they decrease browser stability?


Whatever it is, somehow most people still have Flash installed on their computers, and a lot of them have Java.


Those are two of the exceptions to the rule.

Quite literally; there is a section of the Mozilla browser codebase that actively seeks out those plugins (along with QuickTime, Windows Media Player, and Acrobat Reader) because users who lack them experience a "broken web" (http://lxr.mozilla.org/mozilla-central/source/dom/plugins/ba...).

I'm not saying becoming one of those plugins is impossible---clearly, it's been done more than zero times. I'm saying that I really wouldn't base any business decisions around the assumption that it will happen for your plugin.


Alternatively, make a new type of browser that completely replaces Javascript, make it popular and leave the old world behind.


You'll never get adoption for a new browser that can't parse existing websites, unfortunately. There's no 'clean break' option.


People adopt new things all the time. Look at what happened when smart phones came long - everybody started making apps for them. I think people on smart phones spend more time in apps than they do on the web.

Anyway, the new browser could totally embed another browser engine to show legacy web pages.


New browser that fully supports existing technologies is probably the best option.

Similarly, there's nothing technically stopping someone from building a new scripting core in the browser itself and then implementing the JavaScript engine atop that (other than the need to support a brand-new untested framework in an environment of high-performance already-existing JavaScript engines, of course).


> heading towards a future of being a compilation target

Having to trace/debug compiled javascript from another language is a horrific future. In your analogy, C programmers would have to debug assembly.

I agree it's the most probable future, but let no one call it innovation when it's simply resignation from lack of options.


There's no reason Javascript can't get better at being the assembly language of the web, including making debugging of other languages easier.


You haven't heard of source maps then.


"Having to trace/debug compiled x86 machine code from another language is a horrific future."

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: