NaCl isn't portable (Mozilla is working on Web Assembly)
Before this, before Blink forked WebKit, Apple rejected naive DartVM pre-integration changes for the same reason:
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.
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.
"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.
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.
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!
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:
and events have proven him correct.
Read the leaked DASH memo if you haven't yet:
(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
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.
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.
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.
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.
I'm not. We are sentenced for another 20+ yrs for lang with broken 'this' pointer
'this' in JS is misleading and confusing - IMHO it's broken design
Enough with pulling victim-faces! :-P.
Yep. I recognise that this may not have been a winnable fight, but I absolutely judge the people who were on the other side.
WebSQL was a much better tech than IndexedDB. Was the dependence on Sqlite problematic? Sure. But Mozilla had the resources to make a pretty good try at fixing it; instead they refused to even implement it and gave us the relatively terrible IndexedDB instead. Which, in turn, Apple has refused to implement, and now here we are. Thanks Moz.
(I'm less concerned about NaCL and Dart, because it's less clear to me that these were obviously superior technologies that obviously needed cross-browser adaption. You're certainly right that the pattern is suggestive though.)
: Yeah, I know, they claim to have implemented it. Anyone who's tried to use their implementation will recognise this claim as a subtle joke. On us.
: Their blog post justifying themselves has not aged well. I especially love the bit where they say IndexedDB is better than WebSQL because it has better "developer aesthetics", as if anyone is actually casually coding against IndexedDB without using some sort of wrapper or compatibility layer. Or as if anyone actually likes the IndexedDB syntax and API.
I agree the situation sucks, but I'm not sure how to fix it even today.
First, keep in mind that lot of this decision was political; if Mozilla had lobbied for it a lot of fudging could have been done. Instead Mozilla made sure that a strict reading of the rules was used by which, yes, WebSQL clearly failed.
And no, Mozilla probably didn't have the resources to implement SQLite from scratch, but:
1. They could have worked with others. Apple, quite clearly, was much more invested in WebSQL than IndexedDB. Could they have contributed to a join effort? We'll never know.
2. In particular, the rule about needing two seperate implementations is good, but it could have been fudged here; a bigger problem was the lack of a spec beyond "whatever Sqlite does". Did Mozilla have the resources to clearly specify how a reference implementation should work, even if the only actual implementation remained Sqlite? Maybe. Would that have been enough? Arguably.
3. In the event, IndexedDB was not a real replacement for WebSQL; at most it was an important tool that could be used to build one, some day; a process that is still ongoing (eg, with PouchDB) and has no real end in site. Even if we lacked the resources to really bring WebSQL up to par and re-implement Sqlite from scratch, we apparently lack the resources to bring IndexedDB up to par too. If we're doomed to spend years struggling with broken implementations and poor browser support either way, what did we gain with IndexedDB?
Like I said, I don't know that there was a good solution to this. But I feel like Mozilla helped ensure we got a bad one.
The rule of having multiple implementations is an important one.
And it might have been possible - surely Google and Microsoft, who supported IndexedDB, had the resource to write an alternative implementation. I don't know the history enough to know why they didn't.
The best retelling of events, I think, is this one: http://nolanlawson.com/2014/04/26/web-sql-database-in-memori...
Has some very good details. And it's certainly funny to see what was said during the discussion with how things turned out in practice.
Edit: I'd sum it up as "Google and Apple argue for a solution that will work on mobile; Mozilla and Oracle don't care about mobile, are weirdly obsessed with the idea that developers hate SQL, and use political manoeuvring to win the fight". (Oracle's role in this seems especially odd, but perhaps they had some longer term strategy in mind.) In any case, in retrospect ignoring mobile was a bad idea, and ditching SQL seems to have had no real benefit.
It does show the total need for a fast, JITable intermediate language, and the silliness in not having one from the start, or at least long, long ago.
Not entirely true either. From the link:
> Hixie has said before he’s willing to fully spec the SQL dialect used by [WebSQL]. But since Mozilla categorically refuses to implement the
spec (apparently regardless of whether the SQL dialect is specified), he doesn’t want to put in the work since it would be a comparatively
poor use of time.
Even in that article, the a dev says he's queried the SQLite version in order to detect which exact FT options are available.
The argument for it is basically "eh but it's handy", ignoring the idea of the Web.
If you don't want to just use Sqlite (understandable), and you don't want to write something that is as good as Sqlite (also understandable), then you're going to have a crap database implementation. There's just not a lot of other options there. Jonas' comment just reiterates the lack of choices.
But given the three bad choices, the question does arise: Was IndexedDB really the best of a bad lot? In 2009, a lot of very optimistic things were said about IndexedDB performance, adoption, usage on mobile, developer acceptance. It's been 6 years, and I think it's safe to say that IndexedDB hasn't lived up to anyone's hopes.
When there is just a single codebase, even if it is open source, it isn't a standard. Now, not everything needs to be a standard, but on the web standardization is a big part of why it is so successful.
One example of why a single codebase is bad: Imagine that SQLite version X is the implementation of WebSQL, which all browsers must use. SQLite development is of course continuing, fixing security issues and making it faster, etc. Will browsers just keep using SQLite past version X? What if the SQLite community takes SQLite in a direction that isn't optimal for web browsers? Perhaps web browsers will fork it. What if browsers end up not agreeing on the fork, and some use the original project, and others use the fork - or there are multiple forks?
All of that makes it very risky that compatibility issues will appear between browsers. Having a properly specced standard, with multiple compatible implementations, is so far the best way that we have found that can prevent such things.
It doesn't matter how developers choose to use IndexedDB, what does is for a Web standard to be sane and WebSQL never was. See https://news.ycombinator.com/item?id=9978713
"asm.js over NaCl (which v8 team as shown doesn't require a special compiler mode to optimize for)"
I don't see how not requiring a special compiler is an argument against it.
"ES5/ES5.1/ES6/ES7 language bloat over Your-Choice-Of-JS-Successor language or actually fixing the issues with JS"
ES5/ES5.1/ES6/ES7 ARE efforts to fix issues with JS and mostly driven by Mozilla.
A few days ago, when doing some client-side JS I wanted to use it and I saw that it is not part of a standard, not only that, it has actually been REJECTED. It's really sad to see the development of the language crippled for a reason that basically boils down to "No, because it was proposed by Microsoft".