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.

Bloomberg are currently sponsoring Igalia to work on adding native Decimal number support to JavaScript.

https://github.com/tc39/proposal-decimal

This is an active proposal and was last discussed in the September 2023 meeting.

>Once it is part of the language, that will help a lot :)

If you want to follow along, the proposal to allow type syntax to be part of JavaScript is here:

https://github.com/tc39/proposal-type-annotations

(To repeat Daniel, there is still a huge amount of work ahead)

The FAQ addresses this:

https://github.com/giltayar/proposal-types-as-comments#shoul...

https://github.com/giltayar/proposal-types-as-comments#shoul...

The idea is to avoid hampering competition, evolution, and innovation in the type-checking space.

#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?

There is at least one more Evan working in this space who should be on that list.

Evan Martin created the Ninja build system and works on making JavaScript builds fast at Google. He has blogged about it here:

http://neugierig.org/software/blog/2020/10/scaling-typescrip...

This is interesting. The things you list as problems are the same set of things we tried to solve:

- automatic compilation that is fast

- sourcemaps work

- decoupling of packages to help compatibility

- automatic tsconfig management

I wonder if you would have a different conclusion with these things taken care of.

I agree that TypeScript makes it easier to have functions with complex parameters - because they are now documented and more understandable. So yes, this demands more discipline on the API designer to keep APIs simple.

I'll offer one advantage we have nowadays, which is to permit writing and atomically deploying apps that have both client and server parts - there's no need to preserve compatibility or worry about coping with independent versions.

Our platform allows you to write this all inside one project - so the ability to use a single language across both sides helps app developers maintain mental flow and reduces context-switching. It's even better now that we have TypeScript to perform instant type-checking across the client-server boundary.

Gary Bernhardt shows off similar powers in his awesome video "End-to-End TypeScript: Database, Backend, API, and Frontend": https://www.youtube.com/watch?v=GrnBXhsr0ng

For our purposes, the primary problem with enums is not the runtime overhead. The runtime code for TS enums is a little verbose but it's not huge. The semantics are a little wacky as described in Axel Rauschmeyer's article: https://2ality.com/2020/01/typescript-enums.html

The primary problem is the potential conflict with future ECMAScript. Multiple TypeScript team members have talked about how this feature is now regretted. The article features Orta's famous meme-slide communicating why runtime features (specifically calling enum) should not really be in the TypeScript language. Anders talked about it three weeks ago during the Q&A session at TSConf: https://www.youtube.com/watch?v=vBJF0cJ_3G0

enum is highly unlikely to be removed from TypeScript because of the strong commitment to backwards compatibility. But that doesn't mean we should encourage proliferation. Especially when many use-cases can be served more simply by string unions.

  type Color = "red" | "blue" | "green";

Busted.

It's true. The Big TypeScript lobby has been secretly working for years on a product called TypeScript Enterprise Edition. Many jobs will be created to support all those AbstractVirtualFactoryManagers.

Undeniable evidence: https://twitter.com/drosenwasser/status/1259946589902106624

This is just as serious as Bjarne Stroustrup's famous leaked interview in which he revealed why he created C++: https://www.stokely.com/lighter.side/stroustrup.html

The scenario you are describing (TypeScript diverging from JavaScript) is unlikely in my opinion.

Orta, a member of the TypeScript team, describes the reasons why in his video "How Does the TypeScript Team Try to Avoid Negative Effects on the JS Ecosystem" https://www.youtube.com/watch?v=qr0TnQ2mHwY

It directly answers the question of "What would a malicious version of TypeScript look like" and explains why this is unlikely to occur.

I can empathize with this view.

JavaScript is bound by backwards compatibility. It is expressed by the soundbite "don't break the web". I would love for typeof null to not be "object", and it seems appealing to say "well if JS won't fix it, maybe TS should."

The problem is that this outcome has many negative effects including loss of trust. Orta (a member of the TypeScript team) describes this exact scenario in his video "How Does the TypeScript Team Try to Avoid Negative Effects on the JS Ecosystem" in which he talks about TypeScript "Embracing and Extending" JavaScript: https://www.youtube.com/watch?v=qr0TnQ2mHwY

The TS team seem to be firmly going in the direction of ECMAScript alignment and the JS + Types model, which is something the article advocates for too. Overall this increases my trust in the technology.

On a related topic Bjarne Stroustrup once said "There are only two kinds of languages: the ones people complain about and the ones nobody uses."

Thanks for the feedback - I'm pleased you enjoyed it.

It's true the codebase has some gnarly advanced types (generic, conditional, mapped) for expressing types for constructs created prior to TypeScript being introduced. I suspect we are pushing the limits of the compiler - quite literally TypeScript has fixed limits on recursion depth that have caused us breaks in the past. Hopefully as we refactor code with TypeScript in mind we can reduce the overall type complexity.

And only because you asked... if you wish to join us, please check out https://careers.bloomberg.com

No one should interpret a deep-dive article like this to indicate a language monoculture - we also use many other languages on the server-side including Python and a lot of C++.

Yes, you're right the JS@Bloomberg origin story deserves to be told in full. Probably by Andrew Paprocki. SpiderMonkey has a starring role.

Until then this is as much as I can share right now: https://news.ycombinator.com/item?id=25068119

Also to be clear, we don't have a language monoculture. The app layer and hundreds of services use JS/TS. But the majority of the backend remains C++.

In the early 2000s it was recognized that the C/C++ code-build-run-debug development feedback loop was taking too long for efficient application development. 10-30 minutes to try out changes. It would have been risky not to try something new.

JavaScript revolutionized this, bringing the developer feedback loop time back down to a few seconds. Andrew Paprocki's 2011 JSConf talk demonstrates this. https://www.youtube.com/watch?v=ODgs0eWAIKc

The main competing technology at the time was Lua which would probably have been a fine alternative. JS won. Four years later Node was released which took server-side JS to a mainstream audience and helped validate the choice. Ten years later saw the ES6 renaissance and the rise of JS as a credible language for application development. Now TypeScript takes it to the next level, enabling large robust systems to be efficiently built using JS.

I'm pleased we bet on JS.

That's a very real trade-off and something we have to carefully make a judgement call on every time. In this specific case the decision is made a lot easier due to the fact that string unions are often a simpler alternative.

  type Color = "red" | "green" | "blue";

Glad to hear you appreciated the article!

The server-side JS architecture created in 2005 was presented at JSConf 2011 by Andrew Paprocki.

https://www.youtube.com/watch?v=ODgs0eWAIKc

The talk describes the system architecture and shows how the IDE is used to create applications.

Glad to hear you are finding TypeScript useful too!

Just to expand on the conversion, whilst all of our apps (and hundreds of services) were migrated from C++ to JS, we still have much more C++ on the backend than we do JS. Thankfully it is not a language monoculture ;-)

I would never say never for any potential ECMAScript feature. Each time people say "JS will never do x", a few years later it does. Brendan Eich has a slide on this.

https://www.slideshare.net/BrendanEich/jslol-9539395/110-Alw...

In terms of whether JS will introduce things that conflict with TS, it's hard to say. TypeScript team themselves are active participants in TC39, championing recent features such as Optional Chaining and Nullish Coalescing. So if there were any conflicts, or even opportunities for confusion, it would all be managed way ahead of time. Several TC39 delegates are users of TypeScript so there is no risk of accidents here (in my opinion).

The majority of breaks are due to the checker getting better. So code that passed now errors. Most of the time pre-existing published DTS files still operate fine.