You could have a similar experience with virtually any other language/platform. “Someone who doesn’t know anything about C had a lot of trouble running some arbitrary C code they downloaded” wouldn’t raise a single eyebrow.
Turns out your kids actually manage to use the tools they built just fine.
> You could have a similar experience with virtually any other language/platform.
I'm sorry but I don't believe the issue is as bad in other environments.
I've managed to pick up and make small patches/enhancements to projects written in Java, C, Ruby, Python - none of which I use regularly beyond the bare minimum I need (usually to patch some tool I'm relying on).
"Modern" javascript is just a huge pile of WTF with "Are you fucking crazy?" frosting to my eye.
> Turns out your kids actually manage to use the tools they built just fine.
The kids have a "new tool" every week because the "old tool" from last week has some problem. That's hardly a sign of "just fine".
It is quite easy to pick pick up and make small patches/enhancements to projects written in JavaScript with minimum knowledge. When you are at the point when you are patching tools you rely on, you already know a lot. It is also much easier when you are starting with properly set up existing project.
The situation in article is equivalent of trying to add maven dependency to raw java project without maven, because you dont know maven exists and then wonder why other dependencies are missing or project is not imported correctly to eclipse. That is literally John from article.
> When you are at the point when you are patching tools you rely on, you already know a lot.
I think you misunderstood. I am talking about making patches/enhancements to tools written in languages I do not regularly use. So I didn't "know a lot" about the language or environment or toolchain involved, I generally knew nothing (from a dev POV) about it. The small exceptions there would be a Java project (StanfordNLP) and a C project (the PHP language/runtime), where I had use the language in question to write 'hello world' type programs as a student, as part of my Network Engineering diploma, close to 20 years ago.
> The situation in article is equivalent of trying to add maven dependency to raw java project without maven, because you dont know maven exists and then wonder why other dependencies are missing or project is not imported correctly to eclipse.
The first command "John" runs in the article is: `npm install packageName --save`, as recommended by the package’s README.
> The first command "John" runs in the article is: `npm install packageName --save`, as recommended by the package’s README.
Likewise, java library would have "add this dependency" in its README followed by xml snippet. It would not start from "create maven project" nor explained how you get pom.xml. It is assumed you know what maven is.
> I am talking about making patches/enhancements to tools written in languages I do not regularly use. So I didn't "know a lot" about the language or environment or toolchain involved, I generally knew nothing (from a dev POV) about it. The small exceptions there would be a Java project (StanfordNLP) and a C project (the PHP language/runtime), where I had use the language in question to write 'hello world' type programs as a student, as part of my Network Engineering diploma, close to 20 years ago.
That is exactly what I am talking about. You do not need to know a lot. In java world, you need to know about maven existing and that maven dependency means you have to have maven project.
In JavaScript, you are expected to know that npm dependency means you have to have npm project.
The kids have a "new tool" every week because the "old tool" from last week has some problem. That's hardly a sign of "just fine".
The old tool(s) will actually still work just fine, and plenty of people use them. Kinda like Python 2 and Python 3. You're not forced to use the absolute newest set of packages. I'm not as familiar with Java and Ruby but the I know the C/C++ ecosystem has gone through many changes over the decades. Perhaps the situation with JS is currently overwhelming and maybe it will settle down over time, but I don't think it's a bad thing that lots of people are motivated to keep iterating and improving the tools. Personally I find the JS development experience very smooth and enjoyable, and I know many of the people building all these crazy new things do as well.
The biggest WTF for me is you want to solve problem X. Great someone has written some code in a library to solve X. You want to understand it. Cool, let's look at the source. It uses source transpiler #2 of the big 4, bundler #1 of the big 5, ui library #33 of the big 50, and oh yeah it uses proxies to make everything return a promise so g'luck debugging that.
And yet, we didn't have these issues for the first 20 years that JS was around. It was only when all these things started being created around JS (babel, webpack, node, npm, typescript, etc.) that all the complexity and insanity was introduced. In what I still consider to be the good old days, any JS code would just be in an external JS file and you would just link to it. No transpiling needed. No build process needed. No module repository needed.
I used to work for a company that developed a JS widget people could stick on their site with ease (and not just little sites either, this was on microsoft.com, nfl.com, starbucks.com...)
As such I got to deal with getting our code to play nicely with the dozens of other scripts that inevitably existed on these sites as well. Being a third-party on a site with not just first-party code but also other random third-party code was truly a hostile environment.
Nobody was doing anything correctly like loading scripts in a way so that they'd never interfere. Some script would load the version of jQuery it wanted, which would shadow the version some other script wanted to use, and stuff would break (but only sometimes, because it depends on timing).
This was before anyone was using webpack. Bundlers thankfully solved this issue (unless you really go out of your way). I'm sorry to say what you consider the good old days were in fact quite bad. If you're making a personal website for yourself? Sure, all this seems like overkill. As soon as you introduce anything third-party? You need lots of tricks to be bulletproof. So from my perspective, things are much improved.
Its almost like Javascript begat a developer eco-system which then required further tooling and ancillary applications in order to keep it all in order.
What a pity this was done within the browser-as-OS context rather than OS-as-OS, as a thing... What you described is just like the good ol' days of DOS were: you could write some code, sometimes, that would work on everyones machine - but then of course there were special cases and developers had to take into consideration other members of the ecosystem - standards had to be proposed, formulated, and met - competing players needed to play nice together, and so on.
The trouble with Javascript today is that precisely NONE of the lessons learned in any of the other places where PRECISELY these issues were experienced, have been applied - even less, paid any attention. And, especially not, by any of the so-called 'new school' of developers who think such disasters as the left-pad fiasco are Just Fine™.
The cognitive load of Javascript today is equivalent to that of, lets say .. assembly on DOS in the 80's. "Anyone" can do it, and no doubt there will be great advances in applications for the user - but don't come screaming when the big ball of mess starts costing you more than if you'd just written it properly in the first place. That means, packaging and abstracting things properly. It means putting the modules in a place where the world will find them over time. It means having release planning procedures that work, and aren't in the hands of a mindless entity. This was how it was on DOS, and then Windows, and now the Web .. less so on Linux, because Linux has always had great solutions to the kinds of problems Javascript is now manifesting.
I blame the OS vendors, personally: Apple, Microsoft, et al. If they hadn't had such a hard-on for removing basic compilation capabilities from a default OS install, we wouldn't have all been corralled into the web, and thus relieved to 'finally' have a dev tool for the common man available to us, in Javascript.
The cognitive load is the same. The ecosystem is a disaster, however. I'd rather just be writing plain ol' Linux apps, producing binary-file based installers, personally .. the tipping point for the effort to invest in Web development is there. I just need users willing to run real operating systems, and who realise that the web isn't just about the browser. I feel that is a more worthy investment of the intellectual capital of developers, today.
Of course, none of this matters to the billion-dollar Javascript churn industry. The customers don't need to know how bad it is: as long as they feel they're getting the user base they need/deserve for having paid so much/little for a bit of Javascript hackery ...
C has much more of an excuse to be difficult & fragile. It's surgical. Web tech is designed to be abstract. If your abstraction introduces too much fragility or complexity or cost or overhead then it isn't worth it. Abstraction is a tax, it has a cost. Save the disrespect, in my experience greybeards understand that a lot better than we do.
Nope, I was able to lear C with 18 years, make cross-compilation from a PC to Dreamcast and some basic OpenGL stuff with 20 years (dial-up internet days, no youtube tutorials/platforms).
I was able to pickup PHP-Mysql with 22 years or so, and move from that to Python/Django, even some Ruby in-between.
Javascript? I just can't wrap my head around it. And I've tried.
The rapid pace of change present in the javascript ecosystem (and related developments like Typescript, coffeescript, etc) definitely make it hard to grasp. What might have been relevant years ago may no longer be relevant.
If its hard for people who already have a background in programming and some basic computer knowledge to learn and pick up, I can't imagine how hard it would be for someone with no experience.
The moment you go beyond making a simple website like you might learn in a beginner javascript class (using just basic javascript embedded in an HTML document) you become pretty lost
C has its problems, and in many ways has avoided this hell hole by solving them in clever ways, but they are nowhere near equivalent to the burning trash pile that is the modern Javascript developers stack and tooling.
If all you've ever done is become a professional Javascript developer, I'm sorry: you still have a long way to go before you'll match the style, elegance and productivity of basically any other language. Javascript dev is an atrocious mess, and anyone who has done anything productive in any other language or framework should know that by now.
Turns out your kids actually manage to use the tools they built just fine.