There are a few cases where syntax compilation is split up cleanly, but when you dig into the internals of preset-env, transforms are rarely that isolated. That being said, "watch this space"...
Most specs have a small number of authors (1-3) and a much wider group of people who have influenced the spec. This is as true for Import Maps and kv-storage as any other. FWIW I think "the web's first built-in module" is a reference to the name of the spec, which is called "built-in modules", not a claim to originality.
Hi! Thank you for your work on the polyfill. There is a healthy inter-vendor discussion in the spec's GH issues, and I believe there is absolutely technical merit to this specific proposal. That's all great and above-board.
I'm mainly and strongly objecting to this degree of external promotion for a Stage 1 proposal, along with positioning it, fait accompli, as part of "the Web."
Mozilla has a storied history of roadblocking Google on principle. This outburst has all the hallmarks of an ideological objection, rather than technical, another in Mozilla's longstanding crusade against Google. If the proposal is a net benefit to developers and users, maybe energy is better spent in including this in Firefox, versus demonizing the semantics of a blog post from the competition.
For the curious, below is a non-exhaustive list of promising tech clearly beneficial to developers and users, killed by Mozilla, on principle rather than technical merit:
1. WebSql - A web port of SqLite - arguably the world's second most used (and loved) tech. Instead, we have IndexedDb, which is such a damn hassle that a million wrappers exist to deal with it's shortcomings and complexity, including the tech presented in this blog post.
2. Nacl/PNacl - A precursor to WebAssembly which already had threads, SIMD, permissions, security ... figured out. By design, most Nacl code will run faster than webassembly, as Nacl's sandbox only excluded certain processor instructions deemed a security threat to it's sand-boxing model
3. HTML5 Storage: A file-system like storage for the browser! Killed by Mozilla...
Sure, we don't want any single entity--including ourselves--to monopolize the foundations of the Web. To allow that would diminish the Web's power as a democratized public resource.
Google was the only vendor that supported NaCl or the Filesystem APIs, and WebSQL similarly failed to gain traction outside of WebKit and Presto. If we were wrong in our assessments of those proposals, we weren't alone. And that's what killed them.
FWIW, I don't believe Google was pushing a patent encumbered web, or H.264. Their VP8/VP9,VP10 funding speaks for itself.
No one wants a monopoly in the browser space, and it seems like Mozilla has some other bone to pick with Google. As stated before, developers and web users come before Mozilla's philosophy, and many of the objections to Google's proposals don't seem to further that mission. Maybe some of it is in Mozilla's self preservation interests, I don't really know. But a lot of Google outrage seems feigned, and contrary to developer and user interest.
If you haven't noticed, most devs here haven't raised any technical objections, instead seem pleased with the offering, that's a hint in itself
Not a great example, since "independent" is the important bit there: browsers just shipped sqlite, and you can't have a spec that says "just ship sqlite".
It's more than memory use - it causes tree traversals to take longer, which means unbounded style recalculations (common) and side-effecting DOM changes take longer.
Preact and Hoodie/PouchDB. Frontend hosted on Netlify, backend on literally anywhere ($5 Dokku one-click installation on a DigitalOcean VM, Heroku, whatever).
Hoodie/PouchDB gets you a pretty easy fix for the "whole DB on page load" issue and pretty good realtime sync across clients.
It's true, the example could be better. However - adding any form of data pruning to the example would immediately show the benefit. JSON parsing happens in the worker, and only a small subset of data is actually serialized and sent back to the main thread.
Yeah, that would be a great way of handling it. The other would be to parse out the data and insert it into the IndexedDB and then in the main thread only pull out what is needed
(I had to do exactly that for a B2B app that was receiving hundreds of MB of data a while back)
