I've been in therapy for over a year and one of the most valuable things I've learned as a fellow "problem solver" is to run through the "three H's" when something comes up:
1. Do you want to be Helped?
2. Do you want to be Heard?
3. Do you want to be Hugged?
I'm still trying to get in the habit of using this approach more often with my partner, and as I do, it has noticeably improved our relationship. It turns out most of the time, she just wants to be hugged.
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.
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.
>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.
> 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.
> 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.
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.
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.
Ah, my bad. I apologize if I came off as too aggressive. I know these comment threads can get heated.
As far as the comp/transpiling thing, I was referring to something like ScalaJS, ClojureScript, Kotlin/JS, etc. I'll admit that the JS output isn't always pretty, but it's still JS. I think that compiling to a Wasm module is different than transpiling, because Wasm is more of a black box.
I think it's fine to ship a `.wasm` file that does some kind of computation and complements the app. But I think shipping a `.wasm` file that builds your UI is like using a drill to install a nail: technically, you could do it, but it's harder, slower, and you'll probably end up damaging something or hurting yourself.
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.
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?
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.
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.
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.
> Did you (rightfully) want to tear your eyes out when some LLM suggested that you script with .mjs?
I respectfully disagree with this sentiment. JS is a fantastic Python replacement for scripts. Node.js has added all kinds of utility functions that help you write scripts without needing external dependencies. Bun, Deno, and Node.js can execute TS files (if you want to bring types into the mix). All 3 runtimes are sufficiently performant. If you do end up needing external dependencies, they're only a package.json away. I write all my scripts in JS files these days.
The problem is that only Deno can type check single file scripts. Otherwise with Node and Bun you need a project to use tsc. Python can type check single file scripts (even with PEP 723 deps) with ty. Otherwise, I love TS for scripting, especially with Bun shell
Fair point. If I'm writing scripts, I normally opt for a JS file with JSDoc annotations if I want autocomplete for types (you don't need a tsconfig/tsc installed in WebStorm). Most projects I've encountered with TS scripts were already TS projects to begin with.
It's called motion interpolation, but a lot of TVs call it "motion smoothing". It artificially increases the frame rate. I don't really know how to describe it, but I find it a little disconcerting and I immediately turn that feature off when I buy a new TV. It almost makes the motion look more "real life" in a bad way.
I spent about 9 years in web/frontend development and when all the AI coding things started coming out, I was admittedly concerned and defensive. I thought the output was gross, it couldn't help me with what I was working on, etc. I recently switched over to the backend, so now I'm dealing with an entirely different set of technologies, architecture, and problems to solve. I've found that, so far, about 80% of my time is spent planning, discussing requirements, determining how to integrate new features into the system or how fixing a bug may affect something else, etc. I use AI for the coding part because the code is sort of an afterthought. I've fully leaned into it and the experience has been fantastic. I ask Claude Code questions and bounce ideas off it. I ask it to write some code for me and I review it and make minor adjustments. The TLDR is I'm not really worried about it taking my job anymore, but I recognize that _not_ using it is going to become very obvious in the near future (it already is). This article pretty much nailed it. Engineering isn't just about pumping out lines of code, the code is just the output of your skills which provide the most value. Once I started looking at things that way, my stress level dropped considerably.
As someone who has spent a lot of time trying to gain a11y expertise and learn best practices, this messaging drives me a little bonkers. There is so much inaccessible content on the web. The official ARIA guide tells you "you're better off doing nothing". All of the example patterns in the ARIA Practices Guide (APG) tell you the code isn't for production use [1]. They provide an explanation which points back to..."you're better off doing nothing".
When I need to add a toolbar to my app, and I want it to be accessible. I look at the APG, the APG has a toolbar example with markup, CSS, and JS, but apparently I'm not supposed to use it. I've been at this for years and it's incredibly frustrating. I usually use the APG code in production anyways. It's probably not catastrophically wrong, but it always makes me feel like I'm screwing something up. The alternative is to use a bunch of divs, spans, and buttons because not all of the patterns have semantic HTML equivalents.
I'm getting a full neuro-psych screening next month because my therapist suspects I may have OCD. It's a 4-6 hour series of tests/interviews (and probably other stuff, I'll find out). I'm guessing that's what they're referring to?
> Most of these students are claiming mental health conditions and learning disabilities, like anxiety, depression, and ADHD.
Well, considering * gestures broadly at everything *, I'm sure more than 38% of students are struggling with near-debilitating anxiety and depression. The future doesn't look very bright right now. I can't imagine what being in college must feel like. I've been doing this job for like 20 years and I feel incredibly uncertain about my future most days.
