[lenkite]

> It could be the continued lack of DOM bindings that have been considered a key missing piece for several years now, or maybe something else or more fundamental.

No, it is NOT "something else or more fundamental" - it is most certainly the lack of proper, performant access to the DOM without having to use crazy, slow hacks. Do that and frontend web-apps will throw JS into the gutter within a decade.

[codelikeawolf]

> Do that and frontend web-apps will throw JS into the gutter within a decade.

Why though? What's wrong with JS? I feel like it's gotten a lot better over the years. I don't really understand all the hate.

[tpm]

> What's wrong with JS?

Let's not go into that for the millionth time and instead perhaps ask yourself why is TS wildly successful and even before that everyone was trying to use anything-but-js.

[codelikeawolf]

> Let's not go into that for the millionth time

Ok, that's fair. My goal with this question wasn't to open a can of worms. But whenever I see a strong averse reaction to JS, I assume that the person hasn't tried using _modern_ JS.

> why is TS wildly successful

From my perspective, it stops me from making stupid mistakes, improves autocomplete, and adds more explicitness to the code, which is incredibly beneficial for large teams and big projects. But I don't think that answers my original question, because if you strip away the types, it's JS.

> even before that everyone was trying to use anything-but-js

Because JS used to suck a lot more, but it sucks a lot less now.

[tpm]

> why is TS wildly successful

>From my perspective, it stops me from making stupid mistakes, improves autocomplete, and adds more explicitness to the code, which is incredibly beneficial for large teams and big projects. But I don't think that answers my original question, because if you strip away the types, it's JS.

I think it sort of does answer that - if js was not an awful language, there would be no need for TS, even if TS just a band-aid. Even better, if browsers provided a compile target, bytecode/vm spec or whatever instead of a very bad language everyone has to use, we would be spared of close to three decades of evolving tooling that is trying to remedy that bad decision.

[codelikeawolf]

> I think it sort of does answer that - if js was not an awful language, there would be no need for TS.

Eh, I disagree. For me, this statement is the equivalent of saying "if Python was not an awful language, there would be no need for mypy" or "if Ruby was not such an awful language, there would be no need for Sorbet". I don't think mypy or Sorbet improves the underlying languages; they just add some additional DX to prevent those aforementioned stupid mistakes.

I wasn't trying to be disingenuous when I asked what was wrong with JS. You've now referred to it as "awful" and "very bad". I have used other programming languages pretty extensively, and JS seems fine to me. When I asked you why it was bad, you hand-waved it away, saying "let's not go into that for the millionth time". When I see statements like that, I immediately think "oh, so this person is just jumping on the bandwagon without providing objective reasons for why this language is bad". If you think that JS is bad and awful, fine, that's your opinion. But whenever I have a negative opinion on something and I'm presented with compelling evidence to the contrary, I re-evaluate my reasons for why I think it's bad and possibly change my mind.

At the end of the day, if you want to hate on JS and hope for a browser compile target that lets you use any other language than JS to build web apps, that's your prerogative. I was a web dev for almost 10 years, and I've seen the improvements to the language and ecosystem over time. So whenever I encounter the "LoL Js SuCkS" mindset, it grinds my gears a little bit.

[tpm]

> For me, this statement is the equivalent of saying "if Python was not an awful language, there would be no need for mypy"

This analogy breaks down because if Python does not fit your preferences or the needs of your project, you can use any other language. You can't do this for JS if you have to write for the browser. Well technically you can transpile but that is leaky so in some capacity it still will be JS. And that is the issue.

> I wasn't trying to be disingenuous when I asked what was wrong with JS.

I'm just tired after decades of this. I will gladly use any language I have ever used profesionally instead of JS (so no VB please, but give me Perl, Tcl, Java, PHP, C, whatever). Just yesterday there was this: https://news.ycombinator.com/item?id=46589658

I have seen the improvements too. And the language is getting better, but by now the whole ecosystem including TS and all frameworks is hopelessly infected. And I don't even see the meaning of giving concrete examples because it's just so overwhelmingly frustrating I wouldn't know where to begin or end.

[homarp]

> [...] sucks less

so does c, zig, c++, go, rust, python, ruby, php, ada,...

[codelikeawolf]

I'm not sure if this is meant to be snarky or if you're saying that the languages you listed have improved over time. If you're being snarky, you've proven my point by saying several random programming languages are better than JS while providing zero justification.

[homarp]

It's a complement to my other answer to you (about your Q on why ppl would not want to learn/use js and would prefer WASM if there was FastDOM ==> because not everyone wants to be multilingual): I was listing a few languages that people are confortable with and would rather use through WASM than learning idiomatic JS/TS ( it's easy to learn the syntax, it takes practice to learn the idiomatic way).

And yes, I do meant that my listed have gotten better, just like JS/TS.

As for why not comp/transpiling to JS? it is my impression that WASM was born out of that ( Compiled to subset of js (asm.js)) and it's an evolution of compiling to JS.

[homarp]

it is not hate. It is same reason people likes node on the backend: one language to do eveything.

Wasm with 'fast' DOM manipulation opens the door to every language compiling to wasm to be used to build a web app that renders HTML.

[codelikeawolf]

I don't mean to split hairs here, but considering the wording of "throw something in the gutter", I would argue that "hate" isn't really too far off the mark.

> Wasm with 'fast' DOM manipulation opens the door to every language compiling to wasm to be used to build a web app that renders HTML.

This was never the goal of Wasm. To quote this article [1]:

> What should be relevant for working software developers is not, "Can I write pure Wasm and have direct access to the DOM while avoiding touching any JavaScript ever?" Instead, the question should be, "Can I build my C#/Go/Python library/app into my website so it runs with good performance?"

Swap out "pure Wasm" with <your programming language> and the point still stands. If you really want to use one language to do everything, I'm pretty sure just about every popular programming language has a way of transpiling to JS.

[1] https://queue.acm.org/detail.cfm?id=3746174

[SR2Z]

Then why not allow WASM to access the DOM?

[codelikeawolf]

Wasm is essentially a CPU in the browser. It's very barebones in terms of its capabilities. The DOM API is pretty beefy, so adding DOM support to Wasm would be a massive undertaking. So why add all that complexity when you already have a perfectly capable mechanism for interacting with the DOM?

[bloppe]

That "perfectly capable mechanism" is one-off JS glue code, which is so cumbersome that approximately nobody actually uses it even though it's been an option for at least 6 years. It would be silly to mistake that for a satisfactory solution.

From my (outsider) perspective, I think the main roadblock atm is standardizing the component model, which would open the door to WIT translations for all the web APIs, which would then allow browsers to implement support for those worlds into browser engines directly, perhaps with some JS pollyfill during the transition. Some people really don't like how slowly component model standardization has progressed, hence all the various glue solutions, but the component model is basically just the best glue solution and it's important to get it right for all the various languages and environments they want to support.

[codelikeawolf]

I think maybe you misunderstood what I meant. When I said "perfectly capable mechanism", I meant building the app in JS/TS and leveraging Wasm for additional functionality in your language of choice. I'm also not sure if the "one-off JS glue code" you're referring to is the JS file that languages like Go or tools like Emscripten spit out to get Wasm to work with your app, or the WebAssembly Web API specifically. I would agree that the former is a bit of a dumpster fire.

[drysart]

There's not some conspiracy that's stopped it from happening. Nobody, anywhere, has ever said "DOM access from WASM isn't allowed". It's not a matter of 'allow', it's a matter of capability.

There's a lot of prerequisites for DOM access from WASM that need to be built first before there can be usable DOM access from within WASM, and those are steadily being built and added to the WASM specification. Things like value references, typed object support, and GC support.

[ggiigg]

They will not. E.g WordPress and Dajango are 20 years old and still very popular. People don't just jump to hype because hacker news does.