Goodbye TypeScript, hello native typing for JavaScript
christopherkade.com
christopherkade.com
1) TypeScript supports a huge set of syntax for describing types, and I would be surprised if the standard ever supports all or even most of that, which would mean you can't skip the build step for most real-world TS projects
2) Most front-end projects will continue to have a build step anyway because of things like JSX, minification, and bundling. And if you've got a build step already, stripping out types is one of the easier things to do as a part of it (and you would want to do it even with this proposal, as a part of minification)
3) On the back-end Deno and Bun run TypeScript natively without a build step. Node doesn't, and it won't be displaced overnight, and it may end up the biggest beneficiary of such a proposal. But even there, build tools like esbuild are fast and easy enough to use that you don't gain much by being able to avoid them (and if you're benefitting from static checking, you're setting up at least one tool already!)
I won't go so far as to say it's a bad thing, but I think it'll end up one of those standards that nobody really uses
So you may be right, it seems typescript will still be around for enterprise at least.
I don't think I follow what you mean here, can you clarify?
In a world where JS has type notation, we'd need a similar command that could analyze the code without running it.
If I could avoid that step and still have type annotations and tooling support, I would be a happier person.
Don't make a type system work around the really bad parts of JS. Instead, don't allow them in typed modules. Don't settle for an intentionally unsound (aka broken ) type system. Add an actually sound (probably hindley-milner based) type system that provides usable type info to the JIT so we can guarantee fast, safe code.
It makes much more sense to use a good language (Kotlin, Rust, Java) and transpile to JavaScript. There's already great tooling for it.
Transpiling to JS is ready for production and widely compatible with all browsers already.
It's also the only language that has a superset language owned by a large corporation with direct influence on standards revolving the ecosystem within which the language is used.
A large corporation that has a history of trying to overtake open communities for monetary or altruistic gain.
And a company that seems not to care about the community's needs or wants and instead manages the priorities of the "OSS" project entirely itself.
Making it so that the js runtime can handle modern code as it is authored- versus having to preprocess- would be a great relief to many.
It would also help library authors, who are today tasked with authoring code in one style, and writing tools & config to allow type-users or regular users. The regular users, and often accidentaly typescript users, get code which has lots of additional processing they may or may not want, depending on what module outputs & setup the library author picked when they ran typescript. Ideally most of these decisions should be deferred as much as possible to the end, to the consumer, and with this proposal that becomes possible. Library authors could just release tbeir code as is, unmolested. That sounds like such a huge breath of fresh air, that allows just in time decision making at the end, versus forcing projects individually to tackle these questions & somehow work cohesively.
Generally yeah, web projects will still want some processing, probably. There's probably a couple KB of code we could shave off, post-compression, and we (very arguably) should. But the overall toolchain complexity experienced by so so so many users, by library authors, by newcomers... it could be greatly greatly simplified, by not needing each library, each link in the chain, to have to face transpilation challenges. This vastly improves & simplifies the js universe.
Software developmemt is bigger than industrial scale web development. This greatly eases the burden in many many many areas of JS dev.
Even industrial scale web development still needs debug builds during development and the fastest debug build is "no build". Faster development builds lead to increased developer productivity if nothing else.
Also, don't underestimate the fact that type annotations generally compress extremely well. Type stripping certainly would shave a lot of kilos off uncompressed sizes, but it may be negligible to unimportant in gzip or Brotli real world conditions.
With compression, I think there's more harm & pain caused by obscuring the source-code to users than there is gain in the very small reduction in size.
But this stance gets quite a reaction, from what I've seen, and I wanted to give a lot more rope to the person I was replying to, rather than try to argue this (fairly nor popular) point too. Which is to say, I hugely agree with you, and good-riddance to industrial web practiced that hurt user-agency (somewhat remediable with source-maps but seemingly few sites have source maps on in prod, and still not as pleasant). It's a small user-base, the view-source folk, but embracing those who take the drive to make the world better (or even to just poke-around-and-learn) is what the world needs!
Minification is especially not sufficient for obfuscation in a world with pretty printers embedded into every Dev Tools in every browser.
Minification is just about reducing the size of the output. Any business that truly cares about the safety of their IP should look into "proper" obfuscators.
(Personally, I don't think obfuscators are generally worth the build time and their output worth the extra bandwidth either, but yes there I understand that security theater generally beats performance concerns.)
And it obstructs people who are going out of their way to improve their usage of your site. It's a pity we only see the risk in that, that the miserly antagonistic corporate dominion attitude rules, that is afraid, that quakes at users doing things not on the l blessed path.
This attitude you've very well spoken for bespeaks a great rot & sadness in the world, one that developers should actively try to work against as much as they can.
Ah well, Javascript was a nice simple language for a while, but I guess it was inevitable that enterprise would ruin it.
What happened in the last decade is that JS from a toy language was promoted to an enterprise grade language and is now used to deliver huge software projects. IMHO on such projects strong typing is a must have requirement, this explains huge popularity of Typescript in recent years. The problem with TS is that they went a little bit overboard with typing: you can have strange constructions like union types and crazy generic type defs - all to provide backward compat with untyped code, that could call func with e.g. string, object and array for the same function parameter. If we add strong typing to JS that _is enforced by the runtime_ we may skip this compatibility ballast and have something more simple.
To which I would ask - why not use Rust or Java instead?
JS is good enough and simple enough to learn as a first language to play around with webpages and maybe later on deliver amazing UI interactivity.
Using it for enterprise projects with massive teams is like attempting to empty a river with a straw - then proceeding to innovate on small pumps to increase straw throughput. Technically fine but why not use tools actually made to draw water in large quantities?
For instance, no classes - all you need are objects, which can serve as maps, arrays and contain functions. Constructor? Loading the webpage. Destructor? Unloading the webpage. JQuery modules got a lot of flexibility and power out of a few simple features. One general syntax for function calls. Prototypes and all-global state made it simpler as well, even though modern enterprise programming eschews them because they make testing more difficult. All you needed to test javascript back in the day was f5 and the debug console. All you needed to handle dependencies was to upload a file and write a script tag, or maybe point to a CDN.
I agree with you completely about Typescript, but that's inevitable when the world insists one small, toy scripting language replace all existing languages and all domains - it has to do everything and please everyone and be as flexible as possible while still being bound to javascript's limitations at the end. But most people's complaints about javascript come from the (also inevitable) pain from trying to force it to be something it was never meant to be.
>If we add strong typing to JS that _is enforced by the runtime_ we may skip this compatibility ballast and have something more simple.
Then every runtime has to support two essentially incompatible languages and call them both "Javascript," and only one will work on the web for backwards compatibility reasons. That isn't going to happen. Just compile the language you actually want to use to WASM or native and leave JS alone.
So far this proposal only supports the basic typing features and isn't enforceable per se.
I guess it depends on how the typing support will evolve.
Or, better still, someone could just write a book on how to wean yourself away from TS.