Hacker News Reader

Comment by oso2k | Hacker News Reader

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.

View on HN

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.

"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

"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.

Reply on news.ycombinator.com