Hacker News Reader

Comment by sonnyp | Hacker News Reader

About WebSQL Firefox already had (and still has) Sqlite dependency (it is uses for bookmarks, history, ...) it is not the issue. The problem is that the Web SQL standard states "User agents must implement the SQL dialect supported by Sqlite 3.6.19." [0] which made agents rely on a outdated dependency and non standard (sqlite is not SQL ansible compatible) SQL. A nightmare for Web standards. They made the right (and hard) choice.

NaCl isn't portable (Mozilla is working on Web Assembly)

Dart excerpt taken from Dart FAQ; question: "Will the Dart VM get into Chrome?" response: "No. Dart is designed to compile to JavaScript to run across the modern web, and the dart2js compiler is a top priority for the team." [1]

[0] http://www.w3.org/TR/webdatabase/#web-sql

[1] https://www.dartlang.org/support/faq.html#q-will-the-dart-vm...

View on HN

Just wanted to note that all of Apple, Google, Microsoft and Mozilla are working on WebAssembly, see https://github.com/WebAssembly/design.

Google has the Dart VM running in Chrome and it's called Dartium. If Mozilla had not been so vigorously negative towards Dart the story of Dart and Blink may have turned out differently.

No, Google Chrome people rebelled against the overhead of a cross-language-engine garbage cycle collector. Are you aware of the technical details?

Before this, before Blink forked WebKit, Apple rejected naive DartVM pre-integration changes for the same reason:

https://lists.webkit.org/pipermail/webkit-dev/2011-December/...

Whining for the poor Google-Goliath, blaming little Mozilla-David, is rich. No comment on the Pocket deal or other recent Mozilla changes. On this tangent about Dart, I'm happy that Chrome people prevailed.

>On this tangent about Dart, I'm happy that Chrome people prevailed

I'm not. We are sentenced for another 20+ yrs for lang with broken 'this' pointer

Just because you don't understand the JavaScript this, doesn't mean it's broken. It behaves exactly the same way every time you use it... It refers to the object that called the function (unless, of course you or someone else overrode it).

just because I say 'this' is broken, it doesn't mean I don't understand how it works.

'this' in JS is misleading and confusing - IMHO it's broken design

You might be interested in ES6’s arrow functions, which change the behaviour of this to something you might approve of (you didn’t specify how you thought it was broken):

http://tc39wiki.calculist.org/es6/arrow-functions/

yea there are many different tactics to tackle this issue - still default behaviour is confusing at best - bad design at worst.

Lots of languages, notably including Dart, compile to JS now. WebAssembly will support even more with high efficiency in the next year or two -- not in "20+ yrs".

Enough with pulling victim-faces! :-P.

The Dart team is not a large team and not an arrogant team. Led by Lars Bak, they thought to try and make something that ran faster than JavaScript by doing away with 'monkey patching.' Lars and Kasper Lund took all their experience working with V8 to make something that avoided the bottlenecks. Gilad Bracha designed a good working language and it works without many "gotchas" along the way. It's a pleasure to use. The Google Chrome team was not enthusiastic about it even before Blink, as you correctly state, but what I was trying to say is that if the industry hadn't reacted so negatively to Dart because of some percieved ulterior motive by Google, the Chrome team may have been persuaded to put some more thought into it and make it happen. Lars Bak, Kaser Lund, Gilad Bracha and the rest of the team did something cool and don't get any props for it because they work for Google. Such is life. I recall Mozilla disliked it the most, which I assume was driven by you, the creator of JavaScript. Dart was never going to replace JavaScript you know, because even then they were saying that anything that can be written in JavaScript, will be written in JavaScript. JavaScript is unstoppable, but people should look at Dart for what it is, another tool in the toolkit.

tl;dr -- "Dart is good". A fine view, I agree on parts.

Your words do nothing to address the very real technical problems that kept DartVM out of Chrome.

Stop personalizing everything and study the link I cited.

It's hard not to personalize things like what Oliver Hunt said in [0],

"The issue here isn't "can we make multiple vms live in webkit" it's "can we expose multiple languages to the web", to the former i say obviously as we already do, to the latter I say that we don't want to."

The general tone Oliver had was akin to saying only little-endian machines should be supported on the Web. Not because of some technically proven deficiency in the idea of allowing big-endian machines, but because "we don't want to." I can only imagine if such logic had been applied to other parts of the Web. Technical problems always have a solution.

[0] https://lists.webkit.org/pipermail/webkit-dev/2011-December/...

Oliver is not me, nor has he ever worked for Mozilla. But you are not the OP, so this is all just more mistargeted drive-by and taking-it-too-personally complaining.

There are not multiple GC'ed VMs in Safari sharing the DOM, so I bet Oliver was talking about things like JSC as another way to script Apple stuff than Obj-C (now Swift). But that's not material to the DartVM/OilPan vs. Chrome issue.

Why does the Java VM run in a browser but the Dart VM is too hard?

Please read anything I've written on the topic over the years.

Java runs as a plugin, like Flash. It has no deep DOM integration.

Both Java and Flash have become security problems, so they're in various penalty boxes, beyond the plugin prison.

Back in 1995, when I did JS in the shadow of Java, as a sidekick Robin-the-boy-hostage language, I did the primordial DOM too. Java was in only applets then -- pretty much the same as a plugin. We did connect JS and Java via LiveConnect, which led to the JRI (Warren Harris at Netscape), which led to the JNI. To solve the GC problem, the JRI user had to manage handles for global and local roots.

This did not solve the inter-heap cycle problem, however. Netscape never implemented a cycle collector, but we did at Mozilla, based on [Bacon & Rajan, 2001]. It was required for C++ and JS cycle collection. Around that time, IE would still leak memory if you made a C++/JS cycle by capturing certain global object property references in closures. Their C++ side used COM reference counting, so once the cycle closed through JScript, there was no way to drop the cycle-internal refcount.

Mozilla's C++/JS cycle collector was originally meant to handle C-Python too (and possibly other languages with full XPCOM/DOM access), since we had an optional integration of that engine, courtesy Mark Hammond of Active State. But both the C-Python integration and the polyglot support in the CC got ripped out. Browsers cannot afford overhead, even mostly-dead (but still hazardous in the 0day sense) code.

(Updated to note that LiveConnect is long-gone too. Java is just a plugin.)

I suspect you still have not read Filip Pizlo's post at that lists.webkit.org link I left, or the paper it references. Please take more time to study problems before casting aspersions!

What aspersions? I've noted your opposition to Dart. You've explained that it has to do with memory management difficulties that seem intractable. I now understand this better, so I thank you. The world has moved on and now transpilers are coming into their own, so we do have real choice in the language we use in the browser, which as a programmer is all I want.

What aspersions? Let's start with your "Mozilla disliked Dart", full of personalizing words that obfuscate the objective arguments. Just the "dislike" usage is subjective and vague -- and inaccurate when applied to my comments on HN about Dart.

DartVM never had a chance, I told 'em so and gave concrete reasons why it didn't. Worse, the leaked DASH memo was arrogant and wrong in declaring that JS "cannot be fixed by evolving the language". Anders Hejlsberg gently pushed back against that bogus assertion in 2012:

https://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-...

and events have proven him correct.

Read the leaked DASH memo if you haven't yet:

http://pastebin.com/NUMTTrKj

via

http://lambda-the-ultimate.org/node/4355

(Note that Mark Miller did not write this memo, he just accidentally posted it to a public Google Group thinking that group was private to Google employees.)

A lot of water under the bridge since 2010, and some of it had good effects for Dart users for sure, even with Dart now only a compile-to-JS language. But a lot was wasted. Dart could have used bignums (Dart `int` support) in ES6, for example, and this would have helped JS users too. The lack of it is a direct cost of focusing on DartVM at the expense of dart2js; see

https://github.com/dart-lang/sdk/issues/1533

You are right that I disliked the stinky politics and enormous question-begging on display in the DASH memo. (That's me disliking a set of bad arguments, not me disliking Dart.) It was a statement of intent, to fund a project because some people of note wanted to do that project, even if it wouldn't work cross-browser, and even if it imposed high opportunity cost to JS both in Chrome (the whole V8 team had to be reconstituted in Munich) and in Ecma TC39 (no one showed up to argue for better cross-compiling support in general).

WebAssembly should grow dynamic language support for Dart and languages like it, but that's years out. In the mean time, only JS as compile-from-Dart target is available. ES6 could have used the help.

It's fine for well-funded entities to waste money on boondoggles (well, not really, but I was not a shareholder, and Google is free to "experiment" for any reason it pleases). But I'm not obligated to praise a bogus justification when it leaks, or honor the two-faced way that JS was dealt with in the memo, and evident from the direct and opportunity costs of DartVM.

> That's me disliking a set of bad arguments, not me disliking Dart.

I stand corrected. Yes, I've read all the memos and watched all the videos, including this one when I knew Dart wasn't going to make it into Chrome for the first time. I knew it by Blink engineering lead Darin Fischer's reaction when asked about Dart [https://www.youtube.com/watch?v=TlJob8K_OwE at 17:25] To me it looked like he laughed and sort of scoffed, then he and another member talked Dart down. Maybe it is a failing of mine to look at emotional content when considering issues, but doing so sometimes imparts useful information.

At one point I was passionate about Dart because I thought it hit the sweet spot between JavaScript and Java applets in the browser with optional typing and generics. It turns out TypeScript hit that spot well enough and Anders was right about that.

I understand your frustrations about opportunity costs and lost effort that could have gone into JavaScript, but there is another possibility -- and this is just my opinion, which I voiced at the time -- that the Dart team was more focused on Dart on the server as a Java replacement. This was at a time when Oracle's lawsuit with Google over the Java interfaces was a big question. I thought Dart might be a plan B on the server and why Dart2js was not getting the attention I thought it deserved.

The JavaScript output on the client was unreadable, very large and much of the disdain for Dart from JavaScript devs was for this reason (17000 lines for a "hello world" if I recall correctly - I am not a systems guy but isn't most of that the DartVM translated to JS. Couldn't it be compiled to asm.js and loaded ahead of time if so desired?)

I think we agree on most of this and I apologize. It wasn't my intention to offend you. Dart still has a chance if they can get the translator to ES6 to work, and I don't see why not, so I hope to use Dart when and where it makes sense.

Thanks for the reply and apols -- no hard feelings.

At least the new Dart compiler generates nice JS, and the future efforts on Dart and JS look more aligned. We still don't have a bignum champion in TC39, but we do have great SIMD championing from John McCutchan (who started it) and Daniel Ehrenberg of Google; Dan Gohman of Mozilla; Peter Jensen, et al., of Intel; and others at Microsoft whose names I'm not remembering. This leads to value types as an extension mechanism, so we should get bignums sooner or later.

On whether DartVM was justified as a hedge against Java going away on Google, I've heard that too, but both for Java on the Google server side and for Android Java, I have never seen any evidence to support this notion. I'd want to see an efficient AOT compiler from Java classfiles to Dart, for example. Another example: some convincing work on library/framework parity on the server side to go along with Dart's (very nice) DOM and client side libraries.

Perhaps such work was kept behind firewalls. If instead it was just a case of saying "oh, we may be able to use DartVM if things go south with Oracle", that velleity hardly counts as an intentional, operational Java replacement strategy.

Reply on news.ycombinator.com