I am going to sound crazy, but, if Microsoft would free up TypeScript and every browser added native TypeScript features to JavaScript… and then we all just started calling it TypeScript. Maybe? Then you would see native ts files. Oracle will never give up JS. The funny thing is the number of people who confuse Java and JS.
For years we said bring something sane to browsers instead of trying to salvage js.
At this point, though, why don't they just implement DOM bindings in wasm and make internets a better place overnight?
TypeScript is a really decent language though, I wouldn't feel happier or more productive using Fortran or whatever. Its type system is actually really powerful which is what matters when it comes to avoiding bugs, and it's easy to write functional code with correct-by-construction data. If you need some super optimized code then sure that's what WASM is for but that's not the problem with most web apps, the usual problem is bad design, but then choice of language doesn't save you. Sure TS has some annoying legacy stuff from JS but every language has cruft, and with strict linting you can eliminate it.
It's also better if there's one ecosystem instead of one fragmented with different languages where you have to write bindings for everything you want to use.
> Its type system is actually really powerful which is what matters when it comes to avoiding bugs
It is really powerful as compared to Javascript. It is even really powerful as compared to most other languages people normally use. But not very powerful as compared to languages that have 'proper' type systems. Typescript still relies on you writing tests for everything.
The type system is a huge boon for the developer experience, of course. It enables things like automatic refactoring that make development much more pleasant (although LLMs are getting better at filling that void in dynamically typed languages). But it doesn't save you from bugs in a way that the tests you have to write anyway won't also save you from. And those same tests would also catch the same bugs in Javascript, so you're in the same place either way with respect to that.
> It's also better if there's one ecosystem instead of one fragmented with different languages where you have to write bindings for everything you want to use.
This argument is slightly backwards. This is essentially the argument used for "javascript in the backend" and "let's package the whole browser as application runtime so we can use javascript". The core of the argument is that javascript is ipso facto the best language/runtime to write any code in, including refactoring existing codebases. Bringing javascript out of the browser also means you have to write bindings for javascript and recreate the existing ecosystems anyway.
Even if you approach this from "single codebase across runtimes" angle, the conclusion to bridge the gap between browsers and languages with existing codebase, expertise and ecosystems is much more reasonable than rewrite everything in javascript.
From experience, corporations usually don't give the general public any trademarked name. I assume TypeScript is trademarked right now; and I doubt Microsoft would ever liberate this. So in this regard, the corporations act in the same manner - selfish.
If browser makers offered to put it in the browser if the name is freed, I bet they could be convinced. The main problem right now, is that there isn't a major push to add TS to the browser.
The way I'm proposing it, technically it would be to make JS and TS kind of the same thing, but not fully, as someone else mentioned the goal of TS is still to tell the user (developer) about issues before the code runs. However, if done right TS files still get interpreted like normal JS, and technically you would want to compile them and not put them in the browser "raw" but you could still call it TS.
So then the user gets a type error in their face instead of the page loading? That doesn't really sound better than the developer getting that error while writing the code, which is what TypeScript currently does.
In my mind, the alternative is running TypeScript while writing and at build time. Type checking at runtime is at best redundant, and at worst an excuse to skip type checking and have it blow up in the users' face.
> In my mind, the alternative is running TypeScript while writing and at build time.
Right now, sure.
But if TS is supported natively in the browser, wouldn't your editor highlight the errors as you type? In which case the chance of deploying a broken TS file to the browser is minimal - you'll have to go out of your way to do so, like writing the TS file in plain notepad.
To go even further, having TS supported in the browser does not mean that you are forced to abandon your build step(s). You are still free to run a build step that either:
1. Does the full compilation to JS, and that's what gets deployed.
or
2. Just lints the file, and has the original TS file deployed.
Nothing in "Native TS in the browser" enforces a no-build-step dev process; it just makes it optional.
There's also the fact that, if JS is no longer the target (either browser-byte-code or native-code will be the target), then type-checking can be improved even further because there will be no requirement to allow things purely due to JS compatibility.
Finally, there's an awfully large number of optimisations that can be done if JS is not the target and native-code is.
Yeah that's kinda the point; you get all that, unless you don't run the build-step/in-editor dev process. And the only reason to make that step optional, is to not run it, which is a worse experience.
So I'm not necessarily saying it's a bad thing, it's just that I don't see the point. And given that there's the major downside of having to go through the standards process, both now and in the future, which will likely involve breaking changes and making it harder to update, I don't see it happening. (Edit: I should add that I do think the "types as comments" proposal makes sense. I do see the advantage of being able to run TS code without a build step. It's just the part where we'd throw an error in the user's face that I don't see providing value to anyone.)
I do think TC39 is progressive enough to be OK with changes to JS if those would allow TS to have more effective type checking (as long as they're backwards compatible, of course, which would also be the case if TS got incorporated into JS), so I don't think it's necessary for that.
Performance improvements enabled by optimisations would be nice, but I believe I heard that no major gains would be expected there, especially compared to something like WASM.
> And the only reason to make that step optional, is to not run it, which is a worse experience.
Yeah, but it's an optional "worse" experience.
IOW, for those people who think it's a better experience (because there is no build step), they can opt into it. For those who think it's a worse experience, they can continue using a build-step.
Nothing changes for those who want a build-step.
(I agree about the standards process thing)
> Performance improvements enabled by optimisations would be nice, but I believe I heard that no major gains would be expected there, especially compared to something like WASM.
If TS is compiled in the browser, then it can be compiled to WASM, not to JS.
It's only when TS is compiled on the server that it has to be compiled to JS.
If the browser support TS natively, the compilation target would not be JS (which is what makes the resulting code slow), but either WASM, or naive code.
> a better experience (because there is no build step)
I feel like the way to make both of us happy is to just strip type annotations, rather than doing full type checking in the browser. Which, luckily, is already making its way through the standards track: https://tc39.es/proposal-type-annotations/
> If the browser support TS natively, the compilation target would not be JS (which is what makes the resulting code slow), but either WASM, or naive code.
I was not talking about compiling it to JS; I seem to recall that native support wouldn't necessarily result in big performance improvements. (Consider that JS is also not being compiled to JS.)
Only if you change TS to have actually sound types and it enables good performance instead of enabling you to craft extraordinarily convoluted types for stuff that you should have never written in the first place.
Put another way, I'm fine with the TS syntax (and use TS because there aren't other choices), but the TS semantics aren't a good long-term solution.
I think that’s not crazy at all. You can run TypeScript in Node already and you can run Playwright scripts directly in TypeScript. Next logical step is that browsers start running it directly.
