There’s nothing quick or easy about these steps. Linking to a jQuery CDN and getting working code immediately is easy.

You also don't need to include packages that are poorly engineered and maintained. For what you do decide to use, you are getting visibility into the warts that you may have blissfully ignored in the past.

The issues you are describing are not really problems anymore unless you let your app get woefully out of date. The web and browsers are a moving target, so it's critical that you minimize running legacy code wherever possible. Npm/Yarn and Webpack is a huge step in making that manageable. jQuery has been on autopilot for years because it has limited usefulness. We've collectively moved on except for a few holdouts.

If you have a use case as simple as the author is advocating, this only take about 15 minutes to grok. If it takes longer then you probably don't have enough front-end experience to productively contribute to this conversation. That is a little harsh, but the FUD in the JS world is incredible, mainly by people that have very little experience and understanding.

Sincere no-snark question from someone who's been out of the frontend game for a while: Why do I need Node in order to do "quick and dirty" frontend development?

(FTR I'm with you that jQuery is silly these days. Today's built-in web APIs do pretty much everything jQuery ever did.)

Because using current JS standards while moving the vast majority of the “make it work across a moving-target set of browsers” concerns to build toolchain configuration settings is a simplification from either explicitly managing all the compatibility issues and/or restricting to least-common-denominator JS features. Yes, build toolchains are themselves a source of complexity, but in net they can be a simplification.

When you just sling jQuery on a page and try to use spread syntax or async/await, shit's gonna break.

(Thank you for your patience with this backend dev who finds your whole world very confusing.)

Node js and the the package manager are inextricably tied together. Node js provides a local js runtime environment for the e.g. dev time packages to execute. It's also the api for interacting with the filesystem. Somewhere down there, yes, Node js is a web server, but it's kind of 'the' javascript execution environment for building local packages ("plugins"?) against.

The whole ecosystem is built up on javascript. If you're running grunt or gulp or webpack, it's all javascript. When you install packages globally they're put in a global folder. There are exceptions (I'm looking at you Cypress) that have native assemblies instead of js, but by and large there it's js, and it's stored locally. There are some pretty simple conventions (e.g. the 'node_modules' folder and the hidden '.bin' folder inside that) When running npm it feels like passing a one-liner javascript command into node's javascript repl/environment. The .bin commands are ambiently available.

It makes a lot of sense how it's grown organically... why there haven't been efforts to separate the constituent parts... I don't know. At some point maintaining the 'working thing' with <large degree of> complexity is easier than following a more rigorous, provable set of tools. I think it's a culture thing. Probably the same reason most of the problems are fixed by deleting node_modules and re running `npm i`

JS is interpreted by the browser, but we compile locally so that the code produced implements workarounds for missing language features. The code produced is typically minified so that the payload sent to the browser is much smaller than it would otherwise be.

Node is analogous to Python, Ruby and PHP... they all can run webservices, power desktop apps and compile/build projects.

  python -m http.server my_cool_cli_thing

Thanks again.