robpalmer

The article and (overall) this comments section has thankfully focused on the problem domain, rather than individuals.

As the article points out, there are competing philosophies. James does a great job of outlining his vision.

Education on this domain is positive. Encouraging naming of dissenters, or assigning intent, is not. Folks in e18e who want to advance a particular set of goals are already acting constructively to progress towards those goals.

Congrats, all.

The web has always needed a simpler tooling story, not just an easier one. And the credentials for this attempt are far more favourable than previous attempts.

Glad to see Vite+ is now MIT licensed. That will immensely help with adoption.

The Void.cloud/Cloudflare tie-in is very reasonable for deployment workflows and associated runtime APIs. I think I've heard that everything else in the Vite+ scope (build/test/check/run, etc) will be decoupled (i.e. plugin-based and agnostic of runtimes/hosting providers) which sounds like an important ongoing principle.

Yep. You can learn more about why we created this new blog here:

  https://bloomberg.github.io/js-blog/post/intro/

I hope you like it ;-)

And if it seems like a surprise, you can blame me for not publicising this kind of content earlier given how long we've been working in this area. Thankfully Jon Kuperman and Thomas Chetwin (plus others) found the time and energy to put this platform together.

Congrats to the Boa team! It's great to see an independent open source project thrive and become more widely useful. This is huge impact.

On the integration with Kiesel and Chrome, I'm pleased to see that engines/browsers can share the cost of developing new language features. Temporal is massive! Almost as big as the delta of introducing ES6. There are 4,000+ tests. The functionality does not need to be engine-specific, so it makes sense to leverage reuse.

I believe this is the first introduction of Rust into V8 itself. Which seems like a happy side-effect that hopefully makes it easier to share more Rust libraries in future. This helps keep browser development sustainable.

#private fields are not slow when used natively.

It's true the down-levelled code that uses WeakMaps is slower. The decision to downlevel is in the hands of the user and is controlled by the tsconfig "target" option.

The only environment that needs downlevelled #private fields is IE11.

You're looking at down-levelled code. Babel and esbuild would equally produce similar code. This is not a TypeScript issue.

If you want "native" JS output, use the tsconfig option... "target": "esnext

TCO is coming to V8? Is there a source for this?