4 ms·

We could've had that years ago if Mozilla had not (as all the browser vendors do depressingly often[1]) decided to torpedo NaCl for nonsensical reasons that boi

We could've had that years ago if Mozilla had not (as all the browser vendors do depressingly often[1]) decided to torpedo NaCl for nonsensical reasons that boil down to "NIH," in favor of creating a far-inferior, crippled spec practically designed to be aimlessly bikeshedded for years. [1] Mozilla usually pulls such NIH moves to sabotage the introduction or use of languages (even DSLs) other than JS on the web. See also: WebSQL, Dart, HTML5 vs plugins, HTML5 vs XHTML2. Whether you agreed with their position on those disputes or not, you have to admit there's a pattern. Again, not picking on Mozilla, everyone's an offender: Microsoft generally slows things down so their browsers don't get too outdated, Apple pursues vendettas against competitors and is myopically focused on moving mobile forward while neglecting desktop, Google's constantly attempting to muscle through user/privacy-hostile misfeatures and highly-specialized features that improve their own web apps more than the web as a whole.

hutzlibu 9y ago
Erm, "Mozilla usually pulls such NIH moves to sabotage the introduction or use of languages (even DSLs) other than JS on the web." maybe it is also because their ressources are limited and implementing a new language like dart is somewhat expensive. And NaCL even more I think. But I actually have some anger as well on them for enforcing indexedDB and killing everything else. So now we have to use f indexedDB for storing things locally. You apparently would have prefered WebSQL, I would have liked FileAPI. Still, I don't believe it is out of evil attempt, just limited ressources mixed with stubbornness.
- smitherfield 9y ago
  Again, if it were a one-time thing it'd be different, but it's a pattern with Mozilla. > maybe it is also because their ressources are limited and implementing a new language like dart is somewhat expensive. And NaCL even more I think. If I recall correctly, Google offered to donate their engineers' time to implement Dart and/or NaCl in Firefox and Mozilla still refused. Also, WebAssembly is enormously more complex to implement than NaCl. And, both of these events occurred while Mozilla was napalming skyscraperfuls of $100 bills with their Firefox OS nonsense. BTW, of the things I mentioned the only ones I'm really "angry" at Mozilla for are WebSQL and NaCl, the others I can see both sides.
  - hutzlibu 9y ago
    "Google offered to donate their engineers' time to implement Dart and/or NaCl in Firefox and Mozilla still refused." I did not know that - that is really a bad move. "while Mozilla was napalming skyscraperfuls of $100 bills with their Firefox OS nonsense." Well, I do not believe Firefox OS was nonsense. It was maybe just too ambitious and too many mistakes were made, like focus on low end. But allmost all of the development for Firefox OS directly helped also the Web in general, because most work, was work on WebStandards anyway. Just the ones for calling and sms you cannot really use, but all the other things like battery were beneficial.
- TheAceOfHearts 9y ago
  IndexedDB is seriously one of the web's biggest mistakes. WebSQL was awesome, and most people already know how to work with a relational database and SQL. A virtual file system API would be great. It's definitely one of the core features still missing from the ecosystem.
  - hutzlibu 9y ago
    "A virtual file system API would be great. It's definitely one of the core features still missing from the ecosystem" yes. combined with an easy ability to make real files out of them.
bzbarsky 9y ago
XHTML2 was dead on arrival. Mozilla didn't do anything to sabotage it; it sabotaged itself by completely dropping backwards compat in such a horrible way that you could only implement XHTML2 or something that would render existing websites, but not both, unless you jumped through some pretty ridiculous hoops. It turned out, no one wanted to jump. Plugins were killed by most browser vendors more or less at once, and Mozilla wasn't even the first one. Dart was opposed by every browser vendor who wasn't Google, though the reasons may have differed. Same thing for NaCl. WebSQL is the one thing that I am aware of that Mozilla in fact opposed when others were broadly in favor, but the reason was not NIH. It would have been pretty simple to implement WebSQL in Gecko. The opposition came down to two things, I believe. The first was a simple observation: the W3C process at the time required two interoperable independent implementations, and there weren't any for WebSQL; the only implementation that the spec allowed, if you were going to achieve interoperability, was a particular version of sqlite. There were various ways to solve this problem, including abstracting away the database more (i.e. developing an actual Web SQL with well-defined semantics that were not tied to a particular implementation), but none of the WebSQL proponents were willing to go ahead and put in the time to do that, as far as I can tell. The second issue was the fact that WebSQL had synchronous database queries going on. The storage API really should be async, if it's going to be accessed from the "main thread" (the one the Window object lives in). I do think we could have done better than IndexedDB, though. It, like many other recent web specs, feels way over-engineered to me. [Disclaimer: I work for Mozilla, and did back when most of the things you mention were being discussed, but was not actively involved in the WebSQL/IndexedDB discussions.]
- gsnedders 9y ago
  > Dart was opposed by every browser vendor who wasn't Google, though the reasons may have differed. Same thing for NaCl. Heck, Dart was opposed by the Chrome team: there's a reason why it never made it into Blink. NaCl is slightly different insofar as the Chrome team didn't actively fight it.
- smitherfield 9y ago
  >>>the W3C process at the time required two interoperable independent implementations, and there weren't any for WebSQL This is a convincing argument that's a stupid rule, not a convincing argument against WebSQL. Standardization processes are and ought to be a means, not an end in themselves. If standards body rules are blocking progress on new features which are eagerly anticipated by developers and significantly improve the experience for users, that means the rules are broken. Standards bodies work for the community, not the other way around. Also, this particular bit of standards-lawyering was a blatantly-hypocritical dodge. Virtually every web technology was first implemented in one browser before it was in others. This is an all-purpose, substance-free objection that could've been, and can be in the future, made against any significant web technology, including those promoted by Mozilla. Also, every browser, including Firefox, implements IndexedDB with ... sqlite. One of Mozilla's actual arguments was "we surveyed front-end webdevs, and they said 'ZOMG, SQL isn't webscale!! XD'" Apparently browser development is to proceed on the Idiocracy principle. But leaving that aside, Apple and Google did their own surveys and found that developers (who had actually used or knew of WebSQL) were overwhelmingly positive. Whereas impressions of IndexedDB are overwhelmingly negative, especially vis-a-vis WebSQL. To this day, 7 years after its deprecation, and still never having been implemented in a Microsoft or Mozilla browser, developers have voted with their feet for WebSQL; it remains far more frequently used than IndexedDB. Even as a cross-browser solution, the default remains LocalStorage while IndexedDB languishes in much-deserved obscurity. >>>the only implementation that the spec allowed, if you were going to achieve interoperability, was a particular version of sqlite. Good thing then that sqlite is one of the most mature and stablest programs in existence. sqlite's query API has broken backwards compatibility less in 17 years than most any web API does in 5. It wouldn't even be particularly burdensome to track sqlite in near-real-time. Implausible worst-case scenario, you have to fork sqlite at a specific version. sqlite currently has 3 part-time maintainers.[1] The costs associated with maintaining a fork would be a pittance for an organization Mozilla's size. Also, sqlite is free software, unencumbered by patents — there's absolutely nothing preventing anyone from making their own independent reimplementation of sqlite, it's just that there's no reason to because the original implementation is comprehensively battle-tested and of excellent quality by any metric. sqlite is so good that, forget about sqlite's dialect, nobody feels the need to develop a competitor in its niche of embedded RDBMS, period. This is an excellent reason for using sqlite, not against. >>>There were various ways to solve this problem, including abstracting away the database more (i.e. developing an actual Web SQL with well-defined semantics that were not tied to a particular implementation), but none of the WebSQL proponents were willing to go ahead and put in the time to do that, as far as I can tell. I'd have preferred an ActiveRecord-style API, which in addition to being more ergonomic also would've been independent of a specific backend, but you can't let the perfect be the enemy of the good. Or abandon both perfect and good in favor of unusable garbage. >>>The second issue was the fact that WebSQL had synchronous database queries going on. The storage API really should be async, if it's going to be accessed from the "main thread" (the one the Window object lives in). This is incorrect, WebSQL's API is entirely async. But even if it weren't it wouldn't matter because it's blazing fast, around 50x faster than IndexedDB and as often as not it's the Javascript engine that struggles to keep up rather than the reverse. >>>I do think we could have done better than IndexedDB, though. It, like many other recent web specs, feels way over-engineered to me. That's one of the less colorful ways of putting it, yes. This one's getting quite long so I'll address your other points in a separate reply. [1] https://www.sqlite.org/crew.html https://www.sqlite.org/crew.html

hutzlibu 9y ago

Erm, "Mozilla usually pulls such NIH moves to sabotage the introduction or use of languages (even DSLs) other than JS on the web." maybe it is also because their ressources are limited and implementing a new language like dart is somewhat expensive. And NaCL even more I think. But I actually have some anger as well on them for enforcing indexedDB and killing everything else. So now we have to use f indexedDB for storing things locally. You apparently would have prefered WebSQL, I would have liked FileAPI. Still, I don't believe it is out of evil attempt, just limited ressources mixed with stubbornness.

smitherfield 9y ago
Again, if it were a one-time thing it'd be different, but it's a pattern with Mozilla. > maybe it is also because their ressources are limited and implementing a new language like dart is somewhat expensive. And NaCL even more I think. If I recall correctly, Google offered to donate their engineers' time to implement Dart and/or NaCl in Firefox and Mozilla still refused. Also, WebAssembly is enormously more complex to implement than NaCl. And, both of these events occurred while Mozilla was napalming skyscraperfuls of $100 bills with their Firefox OS nonsense. BTW, of the things I mentioned the only ones I'm really "angry" at Mozilla for are WebSQL and NaCl, the others I can see both sides.
- hutzlibu 9y ago
  "Google offered to donate their engineers' time to implement Dart and/or NaCl in Firefox and Mozilla still refused." I did not know that - that is really a bad move. "while Mozilla was napalming skyscraperfuls of $100 bills with their Firefox OS nonsense." Well, I do not believe Firefox OS was nonsense. It was maybe just too ambitious and too many mistakes were made, like focus on low end. But allmost all of the development for Firefox OS directly helped also the Web in general, because most work, was work on WebStandards anyway. Just the ones for calling and sms you cannot really use, but all the other things like battery were beneficial.
TheAceOfHearts 9y ago
IndexedDB is seriously one of the web's biggest mistakes. WebSQL was awesome, and most people already know how to work with a relational database and SQL. A virtual file system API would be great. It's definitely one of the core features still missing from the ecosystem.
- hutzlibu 9y ago
  "A virtual file system API would be great. It's definitely one of the core features still missing from the ecosystem" yes. combined with an easy ability to make real files out of them.

bzbarsky 9y ago

XHTML2 was dead on arrival. Mozilla didn't do anything to sabotage it; it sabotaged itself by completely dropping backwards compat in such a horrible way that you could only implement XHTML2 or something that would render existing websites, but not both, unless you jumped through some pretty ridiculous hoops. It turned out, no one wanted to jump. Plugins were killed by most browser vendors more or less at once, and Mozilla wasn't even the first one. Dart was opposed by every browser vendor who wasn't Google, though the reasons may have differed. Same thing for NaCl. WebSQL is the one thing that I am aware of that Mozilla in fact opposed when others were broadly in favor, but the reason was not NIH. It would have been pretty simple to implement WebSQL in Gecko. The opposition came down to two things, I believe. The first was a simple observation: the W3C process at the time required two interoperable independent implementations, and there weren't any for WebSQL; the only implementation that the spec allowed, if you were going to achieve interoperability, was a particular version of sqlite. There were various ways to solve this problem, including abstracting away the database more (i.e. developing an actual Web SQL with well-defined semantics that were not tied to a particular implementation), but none of the WebSQL proponents were willing to go ahead and put in the time to do that, as far as I can tell. The second issue was the fact that WebSQL had synchronous database queries going on. The storage API really should be async, if it's going to be accessed from the "main thread" (the one the Window object lives in). I do think we could have done better than IndexedDB, though. It, like many other recent web specs, feels way over-engineered to me. [Disclaimer: I work for Mozilla, and did back when most of the things you mention were being discussed, but was not actively involved in the WebSQL/IndexedDB discussions.]

gsnedders 9y ago
> Dart was opposed by every browser vendor who wasn't Google, though the reasons may have differed. Same thing for NaCl. Heck, Dart was opposed by the Chrome team: there's a reason why it never made it into Blink. NaCl is slightly different insofar as the Chrome team didn't actively fight it.
smitherfield 9y ago
>>>the W3C process at the time required two interoperable independent implementations, and there weren't any for WebSQL This is a convincing argument that's a stupid rule, not a convincing argument against WebSQL. Standardization processes are and ought to be a means, not an end in themselves. If standards body rules are blocking progress on new features which are eagerly anticipated by developers and significantly improve the experience for users, that means the rules are broken. Standards bodies work for the community, not the other way around. Also, this particular bit of standards-lawyering was a blatantly-hypocritical dodge. Virtually every web technology was first implemented in one browser before it was in others. This is an all-purpose, substance-free objection that could've been, and can be in the future, made against any significant web technology, including those promoted by Mozilla. Also, every browser, including Firefox, implements IndexedDB with ... sqlite. One of Mozilla's actual arguments was "we surveyed front-end webdevs, and they said 'ZOMG, SQL isn't webscale!! XD'" Apparently browser development is to proceed on the Idiocracy principle. But leaving that aside, Apple and Google did their own surveys and found that developers (who had actually used or knew of WebSQL) were overwhelmingly positive. Whereas impressions of IndexedDB are overwhelmingly negative, especially vis-a-vis WebSQL. To this day, 7 years after its deprecation, and still never having been implemented in a Microsoft or Mozilla browser, developers have voted with their feet for WebSQL; it remains far more frequently used than IndexedDB. Even as a cross-browser solution, the default remains LocalStorage while IndexedDB languishes in much-deserved obscurity. >>>the only implementation that the spec allowed, if you were going to achieve interoperability, was a particular version of sqlite. Good thing then that sqlite is one of the most mature and stablest programs in existence. sqlite's query API has broken backwards compatibility less in 17 years than most any web API does in 5. It wouldn't even be particularly burdensome to track sqlite in near-real-time. Implausible worst-case scenario, you have to fork sqlite at a specific version. sqlite currently has 3 part-time maintainers.[1] The costs associated with maintaining a fork would be a pittance for an organization Mozilla's size. Also, sqlite is free software, unencumbered by patents — there's absolutely nothing preventing anyone from making their own independent reimplementation of sqlite, it's just that there's no reason to because the original implementation is comprehensively battle-tested and of excellent quality by any metric. sqlite is so good that, forget about sqlite's dialect, nobody feels the need to develop a competitor in its niche of embedded RDBMS, period. This is an excellent reason for using sqlite, not against. >>>There were various ways to solve this problem, including abstracting away the database more (i.e. developing an actual Web SQL with well-defined semantics that were not tied to a particular implementation), but none of the WebSQL proponents were willing to go ahead and put in the time to do that, as far as I can tell. I'd have preferred an ActiveRecord-style API, which in addition to being more ergonomic also would've been independent of a specific backend, but you can't let the perfect be the enemy of the good. Or abandon both perfect and good in favor of unusable garbage. >>>The second issue was the fact that WebSQL had synchronous database queries going on. The storage API really should be async, if it's going to be accessed from the "main thread" (the one the Window object lives in). This is incorrect, WebSQL's API is entirely async. But even if it weren't it wouldn't matter because it's blazing fast, around 50x faster than IndexedDB and as often as not it's the Javascript engine that struggles to keep up rather than the reverse. >>>I do think we could have done better than IndexedDB, though. It, like many other recent web specs, feels way over-engineered to me. That's one of the less colorful ways of putting it, yes. This one's getting quite long so I'll address your other points in a separate reply. [1] https://www.sqlite.org/crew.html https://www.sqlite.org/crew.html