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/

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

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.

There isn't much of a difference between regular enum and const enum when it comes to the usage of the enum keyword. The big difference is what they compile to - where const enum evaporates by inlining the values into the usage sites.

enum is a keyword that is reserved in ECMAScript and therefore may one day clash with TypeScript. It's unlikely any ECMAScript-defined semantics for enum would match today's TypeScript enum. So it's not on any standards track.

There is already a proposal for JS enum that has different semantics to TS enum, and it was created by someone on the TypeScript team: https://github.com/rbuckton/proposal-enum

So the const form doesn't really change the hazard.

Whilst TS does technically contain breaks, these are normally simple increases in the power of the type-checking. It's finding more errors in code that previous seemed fine. Think of it like adding more ESlint rules.

It's rare for there to be a breaking change in the JS emit.

The TypeScript team work hard to preserve compatibility. Breaking changes are explicitly managed and communicated ahead of time. There is a concept of a breakage-budget per-release. This means if you stay up to date, the cost of each upgrade should not be huge. Orta and Nathan on the TypeScript team talk about this in this podcast episode: https://dev.to/devteam/devnews-s1e4-typescript-4-0-gitee-chr...

So "keeping up" is not too hard.

What about VS Code?

That's an excellent suggestion!

It's true you could just have every package publish the raw TypeScript source-code. So that when an app imports a library, it type-checks against the original source code of the library. No need for DTS files from your dependencies!

I have never seen this done in practice for a large system. It's not as scalable as using bare-minimum type declarations that you find in DTS files. It requires more parsing, and potentially more time to accumulate the types. Whereas DTS emit in TypeScript can flatten the resulting type into the DTS file.

But if performance didn't matter, I think this would probably work. And it would eliminate the class of bugs where the generated DTS files are not 100% semantically identical to the original source code. That's another edge-case finding I omitted from the document but hope to write up another day.