There seems to be a lot of hatret for JavaScript. I fully understand and endorse that.

So how can we get another language supported in web browsers and which language should it be?

by enforcing WASM; and whichever language you chose, since it can simply compile to WASM

*flies away

TypeScript is good and it compiles to JS.
WASM doesn’t do away with JS anyway

None, it's already in the best state.
Another language entering the browser space will either bring a speed halt or a butt ton of RCE bugs due to optimizing the speed, or simply, it will be a addon to javascript like WASM.

@black-kite that doesn’t make any sense. TS is the one that doesn’t do away with JS. Other languages that compile to wasm may technically end up being JS in the browser, but it doesn’t matter because at dev time you don’t have to deal with the crap of JS. With TS, you still have to.
That’s what matters. Who cares about what kind of bytecode will be executed by the browser?

I think wasm IS indeed the best bet for the web.

@Lensflare well consider that if other languages will end up being JS either way through WASM, then might as well stick to the sane superset of it and go with TypeScript. Properly coded TypeScript code does take away a lot of pain points from JS to be honest.

I cannot fathom building web applications with something like Rust, it would be just too much.

I am with you 100% that WASM is indeed the best bet for the web, but of all of the things that we currently have, the one language that shines brighter for browsers seems to be JS/TS, and not by virtue of it being the best. But by it being the most implemented and having a great deal of stake in wasm and things like asm.js

Wasm just isn't there yet. JS is the to make stuff interactive but wasm can't do that on it's own. Need JS to interact with DOM etc.

Wasm and JS have the same peak performance. There are tons of languages that compile to JS. What's wrong with those?

Wouldn't gzipped wasm way bigger than gzipped js?

@tosensei
everyone keeps saying this.
did i miss something, or does everyone keep forgetting that wasm doesn't have access to DOM, so whatever your wasm does still needs to be connected to DOM via JS, and all the DOM (which is 90% of what js code on pages does anyways) manipulation will still be handled by JS, meaning it not only won't eliminate JS, but it won't even really reduce the amount of it?

@Midnight-shcode javascript is used for DOM but not ONLY for DOM.

If we reduce it's other usages, eventually, it won't be doing anything important to be slow.

@Lensflare I wasn’t implying JS should be done away with.
I was responding to the argument that WASM can replace JS. Since it doesn’t, might as well use TS (which doesn’t replace JS either).
Ideally, the best would be to use both WASM for its strengths and JS/TS for the rest (DOM manipulation etc).

@fzammetti ok if you really don’t know where the hate for JS comes from, I’ll try to explain.

Before I go into the lack of types, there are so many small shitty things in JS that it’s impossible to list them all but… here a few things that come into my mind:

It never does the right thing by default. For example there is this rule that has been established to always use === instead of ==. I think I don’t need to explain. Then the implicit automatic conversions of types that you almost never ever want. Evaluation to bool is especially painful.
There are so many memes about this quirks that JS has… and no other language has that many of them.
The meaning of "this" in different scopes and context is another such quirk.

Those are insanely many, but of course the main problem is the lack of a type system. It’s not weakly typed. It’s not typed at all. How people can just say that it’s not a big deal is beyond me. I won’t even start to explain the problems of that.

…

@fzammetti you say we have TS for types…
That is like saying the lack of classes in C is not a problem because there is C++.

We are evaluating JS, not TS.

And even with TS, all the other problems of JS remain in TS.

I don't hate using JS for the front end; for running it in Chrome & Firefox.

I hate how people made it into web server (nodeJS), and made it as choice language for native app. I can understand why they wanted to do it, even though that's not what it's made for.

@Midnight-shcode it doesn't matter - as long as nobody has to _deal_ with javascript anymore in any way.

after all: try programming in assembler. that's _almost_ as horrible as programming in JS. but in the end, everything is compiled to asm one way or another. nobody has to touch asm. and that's why it works - abstraction.

also: you're ignoring that browsers can be updated to add JS-free DOM-handling in the future.

@fzammetti good points. I guess most of JS haters really dislike the design decisions, including me. The perceived unexpected behavior is a consequence of that.
It‘s not a lack of understanding how it works. It‘s just a disagreement of how it should work.

I feel a bit different about types, though. While I know that it is possible to work without types (or with weak types), I don‘t understand why anyone would want to do that beyond small prototyping projects and scripts.

I work with a language with a very strict and powerful type system and I learned to use it to avoid so many types of bugs and make the code secure and easy to maintain. I could probably talk for hours how types make everything better.

…

@fzammetti

…

I can’t understand how missing or weak types can be considered a design decision and not just a limitation. For me the reason is that JS started out as a simple scripting language and was never meant to be used as widely as it is today. So, it could be forgiven to omit types for the sake of simplicity.

Maybe you can explain it to me. I honestly want to know.