4 ms·

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

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
developer2 9y ago
XHTML was not "dead on arrival"; that is some seriously fabricated FUD. XHTML came at a time when it was entirely positioned to take over as the proper way of doing things. It had its own mime type to differentiate itself from HTML, in order to allow older content to continue to be served as soup during a deprecation phase. The demand for this strictly validatable syntax was incredible; it was absolutely in a place where it should (not could) have become the new standard. It wasn't us web developers who rejected the call to action. We were begging the other vendors to add support for the XHTML mime type. I spent two years of my career preparing for the transition that never came. We were at the point where we served a different mime type depending on the requesting user agent, having refactored everything to return perfectly compliant XHTML responses. That is how seriously the industry anticipated the changeover. It was the browser vendors who turned a blind eye. The childish browser wars, throughout which each company refused to cooperate with the competition out of self-interest to hoard the market, mutilated the web. Had the vendors all agreed to support XHTML within a span of 6 months, today we would have 100% well-formed XHTML. Instead, browsers still parse meaning out of LITERAL GARBAGE. HTML soup is so pathetic that there are no words to describe it. Please show me a programming or scripting language that allows you to write code with syntax errors, whereby the compiler or interpreter never throws an error, instead taking a best guess stab at what you meant to code. It doesn't exist, because... SURPRISE - the level of absurdity required to permit such a thing is unfathomable. And yet that is exactly what we have with html5. Aside: what the actual fuck is up with CDATA elements still being required to be CDATA. The fact you have to write <script src="/main.js"></script> instead of <script src="/main.js"/> is the only thing someone needs to know in order to understand the disgusting origins of the "modern" web.
- deathanatos 9y ago
  > The fact you have to write <script src="/main.js"></script> instead of <script src="/main.js"/> You don't. <script /> is valid, but in XHTML. If you don't get the mimetype right, and the browser isn't parsing you as XHTML, it won't work.[1] In HTML5, self-closing tags are only valid in particular contexts, and this isn't one of them.[2] (Really, for the HTML tags, you can pretend that self-closing doesn't exist in HTML5, so no <script />. Since script sometimes has content, it needs a closer, so </script>. I do find it as annoying as I suspect you do, however.) [1]: https://stackoverflow.com/a/70288/101999 https://stackoverflow.com/a/70288/101999 [2]: https://stackoverflow.com/a/3558200/101999 https://stackoverflow.com/a/3558200/101999

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

developer2 9y ago

XHTML was not "dead on arrival"; that is some seriously fabricated FUD. XHTML came at a time when it was entirely positioned to take over as the proper way of doing things. It had its own mime type to differentiate itself from HTML, in order to allow older content to continue to be served as soup during a deprecation phase. The demand for this strictly validatable syntax was incredible; it was absolutely in a place where it should (not could) have become the new standard. It wasn't us web developers who rejected the call to action. We were begging the other vendors to add support for the XHTML mime type. I spent two years of my career preparing for the transition that never came. We were at the point where we served a different mime type depending on the requesting user agent, having refactored everything to return perfectly compliant XHTML responses. That is how seriously the industry anticipated the changeover. It was the browser vendors who turned a blind eye. The childish browser wars, throughout which each company refused to cooperate with the competition out of self-interest to hoard the market, mutilated the web. Had the vendors all agreed to support XHTML within a span of 6 months, today we would have 100% well-formed XHTML. Instead, browsers still parse meaning out of LITERAL GARBAGE. HTML soup is so pathetic that there are no words to describe it. Please show me a programming or scripting language that allows you to write code with syntax errors, whereby the compiler or interpreter never throws an error, instead taking a best guess stab at what you meant to code. It doesn't exist, because... SURPRISE - the level of absurdity required to permit such a thing is unfathomable. And yet that is exactly what we have with html5. Aside: what the actual fuck is up with CDATA elements still being required to be CDATA. The fact you have to write <script src="/main.js"></script> instead of <script src="/main.js"/> is the only thing someone needs to know in order to understand the disgusting origins of the "modern" web.

deathanatos 9y ago
> The fact you have to write <script src="/main.js"></script> instead of <script src="/main.js"/> You don't. <script /> is valid, but in XHTML. If you don't get the mimetype right, and the browser isn't parsing you as XHTML, it won't work.[1] In HTML5, self-closing tags are only valid in particular contexts, and this isn't one of them.[2] (Really, for the HTML tags, you can pretend that self-closing doesn't exist in HTML5, so no <script />. Since script sometimes has content, it needs a closer, so </script>. I do find it as annoying as I suspect you do, however.) [1]: https://stackoverflow.com/a/70288/101999 https://stackoverflow.com/a/70288/101999 [2]: https://stackoverflow.com/a/3558200/101999 https://stackoverflow.com/a/3558200/101999