1. 22

  2. [Comment removed by author]

    1. 5

      If you’re a backend JS developer (using Node), go off and work on other things and come back, you’re still extremely likely to be on express and regular old javascript. Maybe you’d switch from callbacks to promises, but I’d argue that’s an improvement in readability of your programs with really no learning curve.

      Front-end development is a totally different ballgame, though. The reason for that is because everyone from every background is involved in it, bringing their own ideals and practices from their favorite language. Each of them saying “this is the right way and if you do it another way, you’re stupid.” It’s been going on for years.

      You can either take a wait and see approach on new libraries, or you can try to jump on each new trend and complain about it when a new hotness comes out a week after you finished your v1.

      1. 0

        So I have been polishing the rust off my C++…

        I was stuck in an embedded environment for a while, where I only saw / could do pre-C++11 C++.

        So part of me is going Wee! Grreat! Look at all the problems they have fixed!

        Then reality hits….

        Righto, I need an URI class here…. let me pull it in….

        What!? Is this the ‘80s? Where’s the URI class in the standard library?

        Perl, Python, Ruby, C#, Java… have had things like that since forever!

        Oh you have to choose a 3rd party library and use that.

        Ok. Great.

        Wait, the 3rd party libraries I have chosen don’t even agree on the typedef for an ipv4 address!? WTF!?

        This is part of why an ecosystem like Ruby or Perl or D succeeds..

        They have the guts to say, yup it makes sense to abstract and standardised that concept and abstract away the interplatform crud… we will choose the best in class library available and bless it as part of The Standard.

        And then the rest of the ecosystem stops arguing minutiae and gets on with the job of building great stuff on top of the standard.

        And that’s what has turned the JavaScript ecosystem to shit.

        The standards body is missing in action.

        It allowed itself to be killed by commercial interests.

        1. 3

          You know…

          This whole response could have been one coherent paragraph.

          You could probably have used a little less text.

          Just get to the point…

          There’s no real standards body on the current ecosystem of JS like there is in your example.

          An example en which it was hard to read.

          1. 2

            Yes but

            When you right comments in the

            Style of

            e. e.


            This is

            What you get.

      2. 21

        I’m having trouble reconciling these two dialogues that I see online:


        • A: “everything keeps changing in JS”
        • B: “programming requires constant learning”

        Since about forever:

        • A: “we’ve had a lot of luck switching to Haskell”
        • B: “monads and functors? Who can possibly learn all that?”

        I’m not saying these represent any community in any way, shape, or form. What I am seeing is the “always learning” meme being selectively applied, and this is just the latest incarnation of it: it’s somehow more reasonable to learn about endless yak-shaving (‘progress’) rather than the core concepts of computation (aka, what your job is).

        This is what anti-intellectualism looks like, and it’s high time we call it what it is.

        1. 26

          The things I’ve learned are important and everybody should learn them. The things I don’t want to learn are esoteric bullshit and people should stop wasting their time.

          1. 5

            Leaving aside the issue of people’s attitudes towards learning, I agree with your characterization of the state of the JavaScript ecosystem as “endless yak-shaving”. There’s progress, and there’s change for the sake of change. Most of the changes in the JavaScript ecosystem, I’m afraid, belong in the latter category.

            1. 2

              I don’t think it’s all yak-shaving, as they have some difficult problems, some of their own making.

              The whole “x, but in JS!” thing, for instance, is mostly just yak-shaving. Bundling, minifying, and compiling JS (it hurts too much to say ‘transpiling’) are worthwhile IMO.

            2. 3

              I don’t think what’s happening in JS is really a “requires constant learning” issue. There’s nothing really fundamental changing, it’s just the libraries people are using. You do need to learn things about a library, but it’s not really the same as learning a new fundamental concept.

              With that said, I don’t fold all the newness and hot library bs of JS into the “learning” category.

              Is it easier to learn a new library than a fundamental programming concept? Of course it is. I don’t think it’s anti-intellectualism, though. If people don’t want to learn new concepts, that’s on them.

              1. 1

                Unless you have a decent amount of experience, every flavor-of-the-month library requires some work to use. Each library gains popularity by attacking the problem of managing state and UI changes over time in a different way. However, this difference in approach also means you have to think slightly differently about how to do what you need to do.

                The only way out is to step off of industry’s treadmill of hype, buckle down, and work on understanding the tools in front of you well.

                1. 2

                  Being stuck in the industry treadmill of hype is more of a personal mental state, IMO.

                  Do you care about having experience in all of the new hot frameworks? Do you need to care?

                  I think the answers to those depend on your current employment status more than anything. New dev with no experience? You might want to get some in the new ones. Experienced dev with tons of experience? A cursory look should be fine.

            3. 6

              The only reason this is a debate is because of the lack of choice of platform for web applications. JavaScript is a mediocre language with no real standout features, but it happens to be what runs on browsers so a lot of developers are stuck writing it. I feel there is a lot of angst from people writing JS who don’t want to deal with the language warts, the awful tooling, and the ever-changing state of the language and ecosystem, but for whom there is no reasonable escape.

              If someone has a big problem with Ruby, its performance, the Rails-centric state of the ecosystem, and duck-typing, they just use something else. If they have problems with JavaScript, they write a blog post about it.

              1. 8

                WRT awful tooling and ever-changing state of the ecosystem, these seem to be entirely self inflicted problems. But I guess that’s what the debate is about, at a meta level. Did you need to write in ES2020 and then bundle up a bunch of transpiled polyfills, or could you have held your nose and written in yesteryear’s ES?

                I mean, I just went through a eensy teensy itty bitty version of this. I replaced some code that used jquery to execute $.post() with var x = new XMLHttpRequest() etc. The “hard” part is that x.send() doesn’t form-encode hashes, but that’s literally a seven line function that’s trivial to write. I was using a 90K js library to get one seven line function???

                Now, on the bright side, dropping jquery (and jquery alone) into a project is trivial. So maybe a little wasteful, but I wasn’t wrestling with bundlerifiers or whatever. But at some point, if you’ve invested two weeks setting up your tooling just right, isn’t that two weeks you could have spent just writing code to do what you needed done?

              2. 4

                Author would be more effective if instead of trying to deconstruct why the original author is wrong, instead tried to get at why the original author felt the way they did. Still, a decent counterpoint.

                1. 4

                  Hey look, sanity. How did that get into this discussion? I thought we had chased it all out.

                  But seriously, there is a lot of artificial pressure that people place on each other and on themselves to “keep up” with some perceived onslaught of new and better things. The JavaScript world is young and still figuring out what works best, and the language itself is seeing a more rapid degree of change than it had for a while, and lots of people are involved in figuring out how to make the whole thing better. This is really exciting if you like to be on the bleeding edge and want to help determine how to do JavaScript today. But if you don’t, if that sort of complexity and chaos sounds like the worst thing in the world, you don’t have to do it. The things that worked yesterday still work today. So as the article says, pick a tool, and get to building the thing you actually want to build.

                  1. 13

                    I think you undervalue that pressure to “keep up.” It’s not necessarily just a personal shiny-chasing whim thing; if you’re going to deploy code in production to run a business, one of the key factors you have to consider is whether the sum of libraries and frameworks you’re using today are supportable in the (near to far) future. JS, almost uniquely, makes this decision essentially impossible to evaluate and fraught with incredible risk.

                    You can assert it’s a joyful Cambrian explosion of forward progress, but where’s the proof? Show me the place where the future direction of JS dev is less of a slow churning garbage fire (e.g., http://imgur.com/hjdsstB), and where anyone can put a stake in the quicksand and feel safe in their investment. You’ll struggle. That’s the problem.

                  2. 2

                    The argument presented here seems to be that many tools gives you many choices, and that’s a good thing.

                    One of the biggest problems touched on in the original article (which this article is responding to) is the complexity of development workflow. There are multiple complicated, painful ecosystems around this. The current ecosystem originally grew out of the fact that we don’t have a module system in the browser but we do in Node. This forces people to use bundlers (or other hacks, like UMD) to pull code from Node into the browser.

                    Personally I like JavaScript, and the ecosystem has many pluses that let me to forgive its minuses. And bundlers today are probably a necessary workaround. But ultimately a lot of this complexity could go away if we ever were to get something like an import in the browser compatible with node_modules.

                    Saying that everything is fine with JavaScript seems as hyperbolic as saying everything is wrong with it, in my opinion.

                    1. 1

                      That’s why I love Scala.js:

                      • Great language.
                      • Great IDE support.
                      • High quality libraries.
                      • Sane build system that just works without wrapping a build system in a build system in a build system in a task manager.
                      • Need a dependency? Tell the build system about it, just like all the other dependencies for e. g. the JVM.
                      • You can write useful “isomorphic” code, because the ecosystem isn’t a complete garbage fire.
                      • You actually want to write “isomorphic” code because this is not “I can write JS on the server? Why the hell would I want to so that?”.
                      • Community which has an attention span > 5 minutes.