Goodbye TypeScript, hello native typing for JavaScript
christopherkade.com
Goodbye TypeScript, hello native typing for JavaScript
1–10 of 31 posts
Re: Goodbye TypeScript, hello native typing for JavaScript
#2Is there a point to this? Wouldn't you always want to strip those from your code before shipping to the browser, both for size and compatibility, making support irrelevant?
Re: Goodbye TypeScript, hello native typing for JavaScript
#3Is there a point to this? Wouldn't you always want to strip those from your code before shipping to the browser, both for size and compatibility, making support irrelevant?
You are only considering decent sized web development in your considerations. There are many more JS users out there. People doing shell scripting (the ZX folks dor example), people doing some data science, or who have a js engine embedded in their other project for scripting. Or hobbyists or small site operators. Or library authors! None of these people have the same complex pipeline you are assuming. They might never have to transpile at all, with these changes, might not need any build tools. The simple cases get orders of magnitudes simpler, and that counts for a lot.
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.
Re: Goodbye TypeScript, hello native typing for JavaScript
#4Is there a point to this? Wouldn't you always want to strip those from your code before shipping to the browser, both for size and compatibility, making support irrelevant?
You are only considering decent sized web development in your considerations. There are many more JS users out there. People doing shell scripting (the ZX folks dor example), people doing some data science, or who have a js engine embedded in their other project for scripting. Or hobbyists or small site operators. Or library authors! None of these people have the same complex pipeline you are assuming. They might nev…
> 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.
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.
Re: Goodbye TypeScript, hello native typing for JavaScript
#5Earlier quoted context omitted.
You are only considering decent sized web development in your considerations. There are many more JS users out there. People doing shell scripting (the ZX folks dor example), people doing some data science, or who have a js engine embedded in their other project for scripting. Or hobbyists or small site operators. Or library authors! None of these people have the same complex pipeline you are assuming. They might nev…
> 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. 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 f…
I actually am on the no-uglification bandwagon with you!
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!
Re: Goodbye TypeScript, hello native typing for JavaScript
#6Depends how much one really gets from Typescript.
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.
Re: Goodbye TypeScript, hello native typing for JavaScript
#7I say this as a huge proponent of TypeScript and static types in general: I'm fairly bearish on this proposal
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
Re: Goodbye TypeScript, hello native typing for JavaScript
#8I say this as a huge proponent of TypeScript and static types in general: I'm fairly bearish on this proposal 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 thin…
Regarding point 2. Also, there's no way to run a build/compile step for running 'javascript' to catch these type errors before runtime. Would we bring Node into the CI just to catch those errors?
So you may be right, it seems typescript will still be around for enterprise at least.
Re: Goodbye TypeScript, hello native typing for JavaScript
#9I say this as a huge proponent of TypeScript and static types in general: I'm fairly bearish on this proposal 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 thin…
Regarding point 2. Also, there's no way to run a build/compile step for running 'javascript' to catch these type errors before runtime. Would we bring Node into the CI just to catch those errors? So you may be right, it seems typescript will still be around for enterprise at least.
> there's no way to run a build/compile step for running 'javascript' to catch these type errors before runtime
I don't think I follow what you mean here, can you clarify?
Re: Goodbye TypeScript, hello native typing for JavaScript
#10I say this as a huge proponent of TypeScript and static types in general: I'm fairly bearish on this proposal 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 thin…
Even if they don't get further than the basic types and user-defined types, that would be enough to make my life dramatically easier. I honestly avoid making stuff in typescript, not because I don't love it, but because setting it up is such a pain in the ass.
If I could avoid that step and still have type annotations and tooling support, I would be a happier person.