7 ms·

I agree. And I extend that sentiment to their approach to Web Standards a few years ago too, like WebSQL [0] and NaCl [1], Dart [2]. That felt like NIH [3] or

by oso2k 11y ago

I agree. And I extend that sentiment to their approach to Web Standards a few years ago too, like WebSQL [0] and NaCl [1], Dart [2]. That felt like NIH [3] or some other non-collaborative or ultra-competitive motivation on their part. Not a place of "speak for the Web". IMO, the choice of IndexedDB over WebSQL set the Web back 20 years. [0] https://en.wikipedia.org/wiki/Web_SQL_Database https://en.wikipedia.org/wiki/Web_SQL_Database [1] https://en.wikipedia.org/wiki/Google_Native_Client https://en.wikipedia.org/wiki/Google_Native_Client [2] https://en.wikipedia.org/wiki/Dart_(programming_language) https://en.wikipedia.org/wiki/Dart_(programming_language) [3] https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here

Lazare 11y ago
> IMO, the choice of IndexedDB over WebSQL set the Web back 20 years. 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[1], and now here we are. Thanks Moz[2]. (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.) [1]: 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. [2]: Their blog post justifying themselves[3] 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. [3]: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...
- brighteyes 11y ago
  How would you fix WebSQL? Writing a from-scratch implementation of SQLite seems like the only option, and I don't think Mozilla had the resources for that at the time. I agree the situation sucks, but I'm not sure how to fix it even today.
  - kylec 11y ago
    One thing I never understood is why there needed to be a second implementation of WebSQL. SQLite is public domain, any browser vendor can choose to embed it in what they ship.
    - brighteyes 11y ago
      It's a standards process requirement. A standard must have a well-written spec, well-written enough that multiple implementations are possible. Showing multiple implementations that are compatible is enough to prove that. 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.
    - BrendanEich 11y ago
      More succinctly: SQLite version whatever is specified only by its C source code, and C is woefully underspecified. Lots of Undefind Behavior on top of the memory-unsafe codebase itself. This is not a specification from which two independently implemented interoperable implementations could be written. Ergo, not a standard.
pcwalton 11y ago
NaCl and Dart aren't Web standards.
- oso2k 11y ago
  I agree. And neither is WebSQL. I was speaking to the "approach to Web Standards", not actual Web Standards. My point being that Moz used (IMO) conjecture and FUD to roadblock those technologies. No attempt on their part to experiment with those technologies and prove their value. In return, we've got instead IndexedDB over WebSQL (which many devs choose to wrap), asm.js over NaCl (which v8 team as shown doesn't require a special compiler mode to optimize for), and ES5/ES5.1/ES6/ES7 language bloat over Your-Choice-Of-JS-Successor language or actually fixing the issues with JS.
  - pcwalton 11y ago
    I don't think it's FUD at all. asm.js is legitimately a more practical approach to the problem than NaCl, which is tied to the Pepper API. You can go back to the conversations on the plugin-futures mailing list in which everybody except Google was in agreement as to what should have been done instead of PPAPI; Google went with PPAPI anyway, sealing NaCl's fate with regards to adoption. Nowadays, we have Web Assembly, which Google and Mozilla are both working on, and which combines the best of both worlds. As for ES language improvements, I don't see at all how extending the existing language constitutes "bloat" over having two incompatible VMs. It's strictly less bloat, because you don't throw more VMs into the browser.
  - sonnyp 11y ago
    "we've got instead IndexedDB over WebSQL (which many devs choose to wrap)" 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 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.
sonnyp 11y ago
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 http://www.w3.org/TR/webdatabase/#web-sql [1] https://www.dartlang.org/support/faq.html#q-will-the-dart-vm-get-into-chrome https://www.dartlang.org/support/faq.html#q-will-the-dart-vm...
- michaelwww 11y ago
  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.
  - BrendanEich 11y ago
    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/018811.html 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.
    - tkubacki 11y ago
      >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
anotherangrydev 11y ago
To add another example, I normally do JS using Node and there (and also in IE) you have a very useful function: setImmediate. 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".

by oso2k 11y ago

Lazare 11y ago

> IMO, the choice of IndexedDB over WebSQL set the Web back 20 years. 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[1], and now here we are. Thanks Moz[2]. (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.) [1]: 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. [2]: Their blog post justifying themselves[3] 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. [3]: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

brighteyes 11y ago
How would you fix WebSQL? Writing a from-scratch implementation of SQLite seems like the only option, and I don't think Mozilla had the resources for that at the time. I agree the situation sucks, but I'm not sure how to fix it even today.
- kylec 11y ago
  One thing I never understood is why there needed to be a second implementation of WebSQL. SQLite is public domain, any browser vendor can choose to embed it in what they ship.
  - brighteyes 11y ago
    It's a standards process requirement. A standard must have a well-written spec, well-written enough that multiple implementations are possible. Showing multiple implementations that are compatible is enough to prove that. 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.
  - BrendanEich 11y ago
    More succinctly: SQLite version whatever is specified only by its C source code, and C is woefully underspecified. Lots of Undefind Behavior on top of the memory-unsafe codebase itself. This is not a specification from which two independently implemented interoperable implementations could be written. Ergo, not a standard.

pcwalton 11y ago

NaCl and Dart aren't Web standards.

oso2k 11y ago
I agree. And neither is WebSQL. I was speaking to the "approach to Web Standards", not actual Web Standards. My point being that Moz used (IMO) conjecture and FUD to roadblock those technologies. No attempt on their part to experiment with those technologies and prove their value. In return, we've got instead IndexedDB over WebSQL (which many devs choose to wrap), asm.js over NaCl (which v8 team as shown doesn't require a special compiler mode to optimize for), and ES5/ES5.1/ES6/ES7 language bloat over Your-Choice-Of-JS-Successor language or actually fixing the issues with JS.
- pcwalton 11y ago
  I don't think it's FUD at all. asm.js is legitimately a more practical approach to the problem than NaCl, which is tied to the Pepper API. You can go back to the conversations on the plugin-futures mailing list in which everybody except Google was in agreement as to what should have been done instead of PPAPI; Google went with PPAPI anyway, sealing NaCl's fate with regards to adoption. Nowadays, we have Web Assembly, which Google and Mozilla are both working on, and which combines the best of both worlds. As for ES language improvements, I don't see at all how extending the existing language constitutes "bloat" over having two incompatible VMs. It's strictly less bloat, because you don't throw more VMs into the browser.
- sonnyp 11y ago
  "we've got instead IndexedDB over WebSQL (which many devs choose to wrap)" 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 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.

sonnyp 11y ago

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 http://www.w3.org/TR/webdatabase/#web-sql [1] https://www.dartlang.org/support/faq.html#q-will-the-dart-vm-get-into-chrome https://www.dartlang.org/support/faq.html#q-will-the-dart-vm...

michaelwww 11y ago
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.
- BrendanEich 11y ago
  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/018811.html 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.
  - tkubacki 11y ago
    >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

anotherangrydev 11y ago

To add another example, I normally do JS using Node and there (and also in IE) you have a very useful function: setImmediate. 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".