[galdosdi]

Agreed, TS lasting is really about JS lasting.

I'm not so sure, but I'm also kind of biased because I do wish JS would go away, so I'm probably trying to look for ways it could happen. Realistically it will probably be around as long as the web browser, and the web browser might really be around "forever" by way of continuously adding APIs and shape shifting into whatever the latest thing is. Kind of like C++.

The other way it could finally die though, is if WebAssembly kills it. Right now WebAssembly isn't even usable without JavaScript to access the DOM, so that needs fixing first, but once that's the case, it really will become possible to build a whole front end with no JS, while still integrating with pieces of legacy JS if/when still needed.

This seems more realistic to me than say, C dying of this way, too, because frontends are a lot easier to rewrite and get rewritten or thrown away more often than backend or systems stuff.

By then though, I'll probably be the last remaining person who still has beef with JS...

[grumblingdev]

One thing not to forget about JS is that it has made everything reverse engineerable. WebAssembly will kill this. It's quite amazing to be able to set breakpoints on any website on the internet. To see how any website does something. And it hasn't really caused any problems. I think we take it for granted too much.

What part of JS do you want to die the most? Syntax, runtime, type coercion quirks? And what is your ideal syntax so far? How could JS be changed to your liking?

[galdosdi]

Let me strongly disagree, although I get where you're coming from for sure, and I get that my opinion is contrarian so I hope you'll give it a chance by reading my full rationale:

What about when the JS is minified and/or obfuscated? A good bytecode with lots of symbols that lends itself to good decompilation can be just as good or better.

In my experience I've had a better time dealing with the JVM (Java, etc) world for this because IntelliJ makes it so easy to automatically decompile and jump into your JAR and maven dependencies, and in my experience the quality of decompilation is very good. The nice thing about Java is it is harder and correspondingly uncommon to obfuscate the names of any symbols beyond stack locals, after all, methods calls are linked by name at runtime.

Whereas with JavaScript, if the source is not minified or obfuscated, things are good, otherwise you've definitely lost all the symbols, even the ones that could not realistically be removed in JVM.

Also the vast amount of static typing in the JVM bytecode design forces so many more constraints! This is the huge win, honestly, for people exploring the source code of others. It is a lot easier to figure out what unknown code does when you can safely and reliably map out what calls what, what the types of arguments are and therefore what method calls could be called on them, etc.

So the best case scenario is a little better with JS, I will admit that! But the average and worst cases are far better with JVM even though it is a binary bytecode.

WASM is also a binary bytecode. I am not sure how it will compare on this to JVM though. But I am hopeful.

As for what beef I have with JavaScript, I think the above alludes to it: it is harder to explore a complex unknown codebase than in a statically typed language. I don't mind the syntax or anything superficial like that. It's a nice pleasant easy language to write greenfield code in if you don't have legacy code, sure.

> One thing not to forget about JS is that it has made everything reverse engineerable. WebAssembly will kill this. It's quite amazing to be able to set breakpoints on any website on the internet. To see how any website does something. And it hasn't really caused any problems. I think we take it for granted too much.