1. 16
  1.  

  2. 8

    I found it a bit hard to understand what exactly the author was complaining about. This is the most concrete example I could parse out of the rant:

    Some weeks I spend literally hours debugging and researching all kinds of weird, arcane bugs or conceptual hurdles related to performance, hosting, payload sizes, full-stack architectural gotchas, and the list goes on and on and on.

    Are they complaining about the language? Is it the ecosystem? Is it the community? What does “immaturity” mean to the author? Without more concrete examples, it’s hard to judge the author’s complaints for myself.

    1. 3

      I have to wonder if the issues the author describes (if I understand them correctly) are due to hype-chasing behavior more than Javascript or its ecosystem. I’ve been developing applications using the same runtimes and libraries since node 0.10 and React 0.8. I can think of two major breaking changes in that time (constructing Buffers in node, and the deprecation of React.createClass). Unless you’re constantly chasing the next great thing there just isn’t that much churn. Maybe the problem is more of a discoverability issue, finding the right libraries to rely on?

      1. 3

        I sort of recognize the problem but at the same time not. Some projects are rock-solid like you said, with React being a shining example.

        However, speaking of churn, there is a pattern in the JS ecosystem where older projects get abandoned as soon as someone comes up with a new way of doing things. For example, before people settled (for how long remains to be seen) on Webpack there was a lot of churn in the JS build system space.

        On one hand, starting over might be the fastest way to get a new idea to market. On the other hand, this creates a lot of double work and bad experiences for users who have to learn a new system.

        It’s been a while since I last looked into this, but this article lists five different Webpack alternatives: https://blog.logrocket.com/the-top-latest-build-tools-for-javascript/

        Did we really need five? Couldn’t some of these have been contributions to Webpack instead?

        1. 2

          Yeah we do need Webpack alternatives because despite having sizeable buy-in, it’s

          • littered with arcane config that isn’t declarative
          • can’t handle the most basic front-end like CSS files (why at v5 do I still need a fork in my configuration to load MiniCssExtract plugin where it’s configured in one place and a ‘loader’ in another just to get a CSS file instead of a JS one in my build tool?)
          • not their fault but a lot of the plugins are quite low quality with many dependencies including dowloading random, incompatible binaries from the internet
          • and it’s slow because in its generation, all JavaScript tooling had to be built in JavaScript. While V8 (and the other engines not for Node) are highly optimized, it’s not great for massive text parsing

          I’m happy to see the new generation of tooling built in faster options like Rust, Go, Zig, et. al.

          1. 1

            But did we really need five of them?

            1. 2

              Give it some time. There was 10^8 frameworks til React got standardized, then only a small number could compete with what it was doing. It would seem esbuild and those built atop it (e.g. Snowpack) may be poised to overthrow Webpack’s dominance in a new wave.

              Prior to tools like Parcel made some parts easier and some harder making a switch a tossup. Parcel is faster, but not an order of magnitude like esbuild and Parcel comes with so many dependencies and requires the brittle node-gyp.

      2. 1

        I can certainly relate to this. One example that springs to mind, is the other day, I was looking for a library to generate random strings, and came across this one, which describes itself as minimalist generator of random strings, perfect! Turns out, it’s a 98 kilobyte, beast, with a massive API.

        I think there are a couple of main factors in play here. Javascript developers tend to be front-end focused, and they tend to be younger.
        Front end devs are more interested in aesthetics, and are attracted to being styish and fashionable, also being younger, they are less experienced and may not be familiar with how problems might be already solved in other languages and ecosystems.

        1. 3

          Maybe this characterization was true at some point, but there’s a sizeable faction of people that grew up in the javascript world and are now hard to classify with some story like this.

          1. 1

            Doing front end in my forties,…

            1. 1

              Yeah.. so did you ever resemble his description? I suppose now you have a decade of experience and are familiar with how problems are solved in other ecosystems..

              1. 1

                If typescript is stylish and fashionable - perhaps. But not really that much, maybe when I was a teenager out in school. I understand a lot of things differently because I grew up with programming before I ended up in it as a career.

                When I started my career in my thirties it was really more practical things that I recall driving it. I do like being on the stable side of bleeding edge which at first meant pushing our product towards newer technologies - so integrating asp.net MVC into a webforms app for example.

                But always managing the risk of not being too new and shiny.