Honestly I don't hate the language itself that much (I'm just learning it though so who knows) but developing with it fucking sucks. First npm installs a thousand dependencies, then you have to use it to install an entirely different package manager (yarn) and hope it works.

If you're using npm, you install a package or two that you're working with and get 10+ vulnerabilities. It tells you to run "npm audit fix" so you do it, but it just lists the vulnerabilities again and tells you to run "npm audit fix", so apparently you're just stuck with those.

Then you try running your react app and it crashes with an error about failing to stat a random file in your home directory. It turns out that you mistyped an import, and instead of giving an error about that it recursively backs up and checks every single file to see if it's the one it's looking for. Cool.

  • ComradeBongwater [he/him]
    ·
    3 years ago

    but if you use classes, let, and arrow expressions, all the real language jank mostly goes away

    While those fix many old JS deficiencies, the core problem with JS as a language relates to evaluation moreso than syntax & features. Tons of unexpected jank comes from JS interpretting certain expressions in unintuitive ways that break expectations of any dev unfamiliar with specific JS quirks.

    twenty different bespoke configuration languages, build systems, packaging systems, state management systems,

    Agreed 100%. While not entirely JS's fault (shared w/ browsers, the DOM), it makes JS dev much more difficult. You now need deps for a million things, all configured differently. Entirely plausible a project forces you to write configs in JS, JSON, TOML, & YAML.

    And now half of them are React, which is overengineered, poorly engineered, and not fit to any particular project’s needs.

    I quite like JSX's syntax, but React's lifecycle management has enough quirks that your code often behaves in unintuitive and hard to predict ways. So much of time is wasted on "fuck, why is/isn't this rerendering" that could be spent writing core logic.

    State & lifecycle management is a mess, hence the multitude of deps for it. The advent of hooks helps somewhat, but they're incompatible with class components, so most code cannot benefit without refactoring...a bandaid leaving the core problems in place, but now forcing you to manage multiple vastly different design in your code.

    Styling is absolutely fucked, with another set of deps for that too. All you want is dynamic styling & responsive UI but you have to choose between writing a fuckton of CSS classes or using CSS-in-JS...which always seems to add weird edge cases that recompute loads of shit if you use values from the browser or DOM. Anything outside CRUD apps with standard UI becomes exponentially harder than necessary.

    • Owl [he/him]
      ·
      3 years ago

      Tons of unexpected jank comes from JS interpretting certain expressions in unintuitive ways that break expectations of any dev unfamiliar with specific JS quirks.

      I agree with this, but the most egregious parts of that go away if you use the more modern syntax. Like there's nothing inherently better about "let" instead of "var" syntactically; they're the same thing. But var is evaluated in a way that, if you use it to call an inlined function in a loop, will make your hair fall out. Same with arrow notation - it's cuter syntax than function(), but it also doesn't bind "this" in JS's wacky way, and that's the real advantage. Class also makes "this" behave like a normal person would expect.

      Styling is absolutely fucked

      Styling is so incredibly fucked.

      I use raw CSS though, because as shit as it is, all the weird js ecosystem deps you can pull in just add more things that can break, without actually addressing any of CSS's core problems. Especially now that there are CSS vars.

      • ComradeBongwater [he/him]
        ·
        3 years ago

        Luckily I didn't start writing JS until about the time ES6 came about, so I pretty much used those syntax features from the start. But I didn't originally know the this binding quirks and just thought it was syntactic sugar, so I had a rough time wondering why my code wasn't evaluating how I expected.

        Raw CSS is looking more appealing now that CSS vars are standard. CSS-in-JS has caused me so much pain back when I was a noob. I dread frontend because of the rerendering bugs that would happen because I read DOM data to generate the CSS which then altered the DOM data.