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?

I don't know why anyone has a big problem with JS. Is it the very best language? No, probably not. But what's with all the hate? It's not like it's a hard language by any stretch, and it's not like there isn't a metric shit-ton of tooling to help you, tons of libraries to build on top of, etc. What, you don't like the whole NPM ecosystem? Me neither, but here's a hot take: you don't need it. Don't like the myriad frameworks available? Me neither, but here's another hot take: you don't need them. Is everyone's code so shitty that they're really getting burnt by no type safety? Well, then there's TS, but frankly, hot take #3: you really don't need even that. Just, you know, be competent. Seriously, I'll be the old man yelling at clouds: how bad are all the developers that think JS is the spawn of Satan and HAS to be replaced? Because, honestly, that's what it seems like it is 99% of the time. You don't have to -love- JS, but the outright hatred just seems ridiculous.

@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.

@Lensflare I've been writing JS for ~25 years and I can count on one hand the times I've been burned by type coercion/lack of strong typing (it's considered weekly typed not untyped). Seems to me that if you understand the language you simply account for it correctly, so I don't consider that a flaw but a design decision. Same with 'this', though I admit that's burned me a few times. But again, if you understand the language, you just deal with it, it's not a quirk, it's a design decision. Of course, you can say you don't like the language's fundamental design, that's fine - I don't like Python very much - but 'quirks' implies things not working as expected, not design decisions. If things don't work as expected in JS, I would contend your fundamental understanding of the language is probably lacking (not you personally, I mean this in the general sense). And I only mentioned TS for those who think they NEED strong typing. I contend the need only exists because people don't grok JS.

@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.

@Lensflare I assume that Eich did it that way to keep it as simple and accessible as possible to as many people as possible. If a language can coerce types correctly then strong typing is arguably not necessary anyway, and it's one less thing new developers have to understand. Early on, that was probably true. Given what JS started out as, and WHEN it started out, and how most people learned it back then (including me), the less surface area there is to learn, the less friction there is, and so that design decision doesn't look all that unreasonable in that light. The real problem is that we've started using JS for A LOT more than it was ever envisioned being used for, and these more advanced use cases arguably DO benefit from strong typing (hence why TS exists, and I wouldn't be surprised if we see TS become a first-class, in-browser engine with no transpile step, then JS fades into history).

In short: JS was a product of its time and a narrow focus, where types were superfluous.

@Lensflare And honestly, after I wrote my reply, I realized that you more or less said exactly what I did :) So yeah, I think you're basically right. It was a good decision at the time, and it only is arguably "bad" now because of what JS has become.

It's like how we can look and say "the internal combustion engine is terrible for the environment, therefore it was a bad invention"... no, it's only bad NOW because we realize things we didn't back then, and maybe we're using it in different ways - and certainly we're using it more - than was perhaps envisioned at the start that makes it seem bad in retrospect.