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.

▲

friendzis 6 hours ago | parent | next [-]

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?

▲

chpatrick 5 hours ago | parent | next [-]

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.

	▲	9rx 3 hours ago \| parent [-]
		> 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.

▲

giancarlostoro 4 hours ago | parent | prev [-]

I love WASM, I do appreciate that it is slowly but reasonably growing into its final destination.

▲

hajile an hour ago | parent | prev | next [-]

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.

▲

shevy-java 7 hours ago | parent | prev | next [-]

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.

▲

onionisafruit 7 hours ago | parent | next [-]

TFA says Microsoft offered the JScript trademark to be used in place of JavaScript, so there’s some indication of willingness to give up a trademark.

▲

Someone1234 7 hours ago | parent | prev | next [-]

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.

	▲	giancarlostoro 7 hours ago \| parent [-]
		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.

▲

georgeecollins 6 hours ago | parent | prev [-]

If you can find the clip on you tube where he says it, it's even funnier. But sadly also true.

https://simonwillison.net

▲

culi 4 hours ago | parent | prev | next [-]

Native type annotations in ecmascript is a serious proposal that gained some traction for quite a while but seems to have fallen off

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

▲

ozim 3 hours ago | parent | prev | next [-]

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.

▲

michaelcampbell 6 hours ago | parent | prev | next [-]

> The funny thing is the number of people who confuse Java and JS.

Is it? My experience in the past decade is that there are more memes about people who confuse the 2 than people that confuse the 2.

	▲	jjkaczor 2 hours ago \| parent [-]
		Heh - it depends on the "Project Damagers" you have to work with...

▲

morshu9001 3 hours ago | parent | prev | next [-]

Was going to say the same thing. I'm fine just using Typescript with types disabled (which is not the same as using TS without specifying types)

▲

Vinnl 7 hours ago | parent | prev [-]

An important feature of TypeScript is identifying problems in your code before the user runs it, i.e. before a browser even comes into play.

▲

array_key_first 6 hours ago | parent | next [-]

No runtime type safety bites people often and in unexpected ways. It should just be standardized.

	▲	Vinnl 5 hours ago \| parent [-]
		Sure, but that's an orthogonal concern. That sounds more like a call to standardise Zod.

▲

lelanthran 7 hours ago | parent | prev [-]

So? If supported natively by the browser the browser could compile it on download.

You'll still get all the strong typing without have to wait for it to run.

For example an error in a little used branch would cause an error before the branch even runs.

▲

Vinnl 5 hours ago | parent | next [-]

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.

	▲	lelanthran 3 hours ago \| parent \| next [-]
		> So then the user gets a type error in their face instead of the page loading? The alternative is not "User sees no error", it's "user sees the error at runtime". In which case, yeah, having the user see the type error is vastly preferable to having the user see a runtime JS error.
	▲	zdragnar 5 hours ago \| parent \| prev [-]
		Not to mention the penalty of the browser having to re-execute the type checking every time the files aren't loaded from cache.

▲

6 hours ago | parent | prev [-]

[deleted]