domenicd

21 ms·

181.
by domenicd 10y ago
Yes, I found all of your points wrong, as I'm explaining in a medium with more than 140 - @-names characters in this Hacker News thread. See above for a response to your point here.
182.
by domenicd 10y ago
Speculative fetching is a time-honored technique in web browsers. During the tokenization phase of HTML, CSS, and even JavaScript, they speculatively start a fetch for a given URL, so that if the data needs to be evaluated later, it is read
183.
by domenicd 10y ago
It's not that complicated; unfortunately a lot of FUD has been spread about alternate models based on misconceptions, which definitely makes it tricky to explain because you have to overcome that FUD.
184.
by domenicd 10y ago
And I wish you'd try to engage with me instead of jumping to your usual tone arguments. Yes, that is indeed what I am referring to, as engines already do for HTML.
185.
by domenicd 10y ago
It's also based on yet further misunderstandings (in this case not understanding the ability of engines to do speculative fetches).
186.
by domenicd 10y ago
Yes. Let's rephrase that first sentence. "Any module with a dependency on data that it needs to execute will have to wait for that data before it executes." That's a good thing.
187.
by domenicd 10y ago
See elsewhere in this thread for why the comparison to sync XHR is very misleading.
188.
by domenicd 10y ago
Another misconception here is the lack of understanding of engines' speculative loading capabilities. It's very easy for an engine to notice `await import('./foo.js')` or even `await fetch('./foo.json&#x27
189.
by domenicd 10y ago
> The point stands that your entry point has to wait until each of its dependencies and each of their dependencies (&c) have finished before your app can start, and it unavoidably slows down module loading. That's true regardles
190.
by domenicd 10y ago
It would block dependent module execution , but not dependent module fetching , which is the actual expensive part.
191.
by domenicd 10y ago
This is false in every modern browser and environment.
192.
by domenicd 10y ago
Exactly correct. But note that > your entry point would be unable to run anything while dependencies are awaiting is very different from the situation with synchronous I/O (in a single-threaded environment). With sync I/O, n
193.
by domenicd 10y ago
This is basically the same old argument against `await` itself: that it allows developers to write bad code that should be parallelized more (by using Promise.all etc.). It didn't stop await inside async functions, and it's not go
194.
by domenicd 10y ago
> Top-level async would make asynchronous IO no different from synchronous IO! It's the worst of both worlds. That's false. You could still do plenty of things while this asynchronous I/O is happening (including allowing t
195.
by domenicd 10y ago
That's false. It wraps each individual module within an async function. They can each proceed concurrently. (And all of them proceed after any `import`ed modules load.)
196.
by domenicd 10y ago
That's false. Module loading and execution are separate stages. The dependent modules would load before this await is ever reached.
197.
by domenicd 10y ago
The difference is that when you call a function, you can easily know what will happen: the function will execute. You can use your knowledge about the function you are calling (and the functions it calls, etc.) to ensure it does not violate
198.
by domenicd 10y ago
> Why even bother with such half-baked solutions? In almost every case it's utterly transparent that these solutions exist for the benefit of the compiler and runtime author, usually because of intentional or unintentional technical
199.
by domenicd 10y ago
No. Observables are a stage 1 proposal, which means roughly that the committee agrees this problem space is interesting, but that it might see drastic changes in implementation, syntax, and more, or might not make it into the eventual stand
200.
by domenicd 10y ago
Decorators are not an ES7 feature. They are a stage 1 proposal, which means roughly that the committee agrees this problem space is interesting, but that it might see drastic changes in implementation, syntax, and more, or might not make it
201.
by domenicd 10y ago
As always, see https://tc39.github.io/ecma262/ for the up-to-date spec that implementers use.
202.
by domenicd 10y ago
It depends. For HTML all browsers do a form of "preparsing" where they do simplistic string searches for things that look like URLs and start speculatively fetching based on that. You could imagine a similar pass for JS modules.
203.
by domenicd 10y ago
That's not correct, Yehuda. For HTML especially, we work on a rough consensus model wherein features are not added to the spec unless they have multi-vendor implementation interest and review. If you'd like to analogize to the TC3
204.
by domenicd 10y ago
Are you aware of https://javascript.spec.whatwg.org/ ? :) Thankfully that spec is almost obsolete as TC39 has moved much of it into the main spec over time. It used to be the only place important de-facto language features l
205.
by domenicd 10y ago
Although your larger point stands, about the division of responsibilities, it's important to distinguish "specifying browser module loading" from the Loader spec draft. The loader repository at https://whatwg.githu
206.
by domenicd 10y ago
Yes, that's exactly correct. Babel, polyfills, etc. were all just guessing at the future.
207.
by domenicd 10y ago
Well, it's been standardized, but implementation work is still ongoing. Details at https://blog.whatwg.org/js-modules
208.
by domenicd 11y ago
You can also do import * as jquery from '/js/jquery/jquery.js'; or maybe better, set up your server-side rewrite rules so that instead of that you do import * as jquery from '/js/jquery&#
209.
by domenicd 11y ago
Deduplication/memoization is built in to the spec, if that helps: https://html.spec.whatwg.org/multipage/webappapis.html#fetch... steps 2 and 3.
210.
by domenicd 11y ago
There was just a comment on GitHub [1] that updates this a bit: > For cross-platform support, the key target for next six months on the roadmap is to get the interpreter & runtime working. JIT would come after that (don't read i

More ›