Children learned how to use it in the 90s from basic web tutorials and reading source code, it isn't that scary.
The real reason is that the web started to become serious business, and that meant javascript had to become a serious language, which led to all of the nonsense it accreted over the years from startups and enterprise. Everyone uses frameworks and compilers and a package manager because a serious language uses frameworks and compilers and a package manager, and all of these look good on a resume.
Have you tried to write a really complex web app without router, state manager, type completion and declarative DOM? And no bundling, so you have tens of <script> tags in the right dependency order to support older browsers? It becomes quite fragile very soon.
But the good news is: you can do without all this. You can manipulate your mutable DOM manually, send and receive messages via native DOM events and mutate your state inside a big vanilla object. You can do without tooling, just Notepad or Vi and a browser. You don't even have to need type completion. You don't even need const or Promise, you can use var and callbacks, everything is still there. If you think tooling is startup-fueled scam (and probably some of it is), there's literally nobody in the world to force you use tooling. The web is entirely backwards compatible, you can do whatever you think is best!
>Have you tried to write a really complex web app without router, state manager, type completion and declarative DOM?
No, but only because I used other backend languages and frameworks for that, because there are much better languages suited to those tasks than JS. Especially in the browser. SPAs exist to serve a specific business case, they aren't qualitatively better than what came before.
>And no bundling, so you have tens of <script> tags in the right dependency order to support older browsers? It becomes quite fragile very soon.
Or just use JQuery and some modules.
You make it seem way more complicated than it was, it was never that complicated. It was never nearly as complicated as the current JS ecosystem. Talking about "tens of scripts" when the current status quo is a brittle dependency tree of hundreds, if not thousands, of scripts for even the simplest task is silly.
>The web is entirely backwards compatible, you can do whatever you think is best!
Yes. This is technically true, but unfortunately tech culture has years of ingrained social pressure leading people to believe javascript is a dangerous language that they don't dare approach without ten layers of abstraction protecting them, and the nonexistent business value in doing so, because the ecosystem is dominated by capitalists. The fact that "vanilla js" even exists as a term demonstrates how pernicious this fear has become - there is no "vanilla x" any other language. Only javascript needs a special term for just using the language because of the deep cultural taboo against doing so.
> No, but only because I used other backend languages and frameworks for that, because there are much better languages suited to those tasks than JS.
Good luck writing highly interactive apps backend-only! (Like Figma or Google Docs). Even with frameworks like Phoenix and runtimes like WebAssembly, you still need a lot of Javascript to get there.
> Or just use JQuery and some modules
This is incredibly ignorant :)
jQuery solves maybe 10% of the problems I listed, and does that imperatively, so you get in the exact same issues, but with a marginally better interface to the DOM. Which is not even true nowadays, as the js DOM interface got a lot better.
> The fact that "vanilla js" even exists as a term demonstrates how pernicious this fear has become - there is no "vanilla x" any other language.
Wait, do you normally write Java with no frameworks? Handle request / responses / queues / threads from scratch?
>Good luck writing highly interactive apps backend-only! (Like Figma or Google Docs). Even with frameworks like Phoenix and runtimes like WebAssembly, you still need a lot of Javascript to get there.
That's exactly the point. 99% of websites don't need to be "highly interactive apps" like Figma or Google Docs. The modern JS pipeline and ecosystem exists for those applications, as it was developed by Facebook, Google and the like, but it's far more complex than most people actually need. The baseline for web development shouldn't be "install NPM and node and n frameworks, learn test suits a,b,c and this completely different language."
>jQuery solves maybe 10% of the problems I listed, and does that imperatively, so you get in the exact same issues, but with a marginally better interface to the DOM. Which is not even true nowadays, as the js DOM interface got a lot better.
I was specifically making a comparison between using JQuery and script tags versus NPM dependencies, but JQuery still solves far more than 10% of the problems most people actually have. Because again, most websites aren't startups trying to optimize to compete against FAANG.
>Wait, do you normally write Java with no frameworks? Handle request / responses / queues / threads from scratch?
I think you're being purposely obtuse here.
People write Java frameworks in Java. It's still programming in Java. You're still expected to understand the Java language to use Java frameworks.
Javascript is primarily compiled from other languages which use their own idioms, often imitating far more strictly typed languages. JS devs are primarily people who hate javascript and wish they were using another language, and much of the unnecessary complexity of the modern JS ecosystem exists to capture the labor market by catering to that desire.
Which is why "vanilla js" is a phenomenon unique to Javascript. Other ecosystems don't have the same culture of alienation and aversion to actually using their language.
Anecdote for anectode, the majority of React apps I encountered needed React (or something equivalent). Lots of web replacements for corporate native applications, which of course are complex, highly interactive beasts with a lot of state and a lot of logic on the client (with the server being glorified CRUD)
> Javascript is primarily compiled from other languages which use their own idioms, often imitating far more strictly typed languages.
I'm not sure which languages are you referring to. Typescript? It's Javascript with types (minus enums, which are discouraged). Elm, Purescript, Clojurescript, Gleam? Great languages, but they represent a tiny fraction of the real world fronted applications
> JS devs are primarily people who hate javascript
Modern javascript? Are you sure you're not projecting the fact that you hate it?
By "modern javascript" I refer to both the language and the ecosystem of Node, NPM, Typescript, and related technologies that have become so ubiquitous as to be inseparable from the language to most people. I don't hate javascript, I'm not one of those "javascript delenda est[0]" people who go off on rants about the language whenever it comes up. However, I don't like what the language and ecosystem have turned into, and I don't like many of the incentives that brought those changes about. What used to be a community driven ecosystem has been captured by VC and corporate interests.
Admittedly, I also don't like a lot of the more recent features added to the language like classes and templates, because I'd prefer javascript remain simple and avoid feature creep.
> ”Good luck writing highly interactive apps backend-only! (Like Figma or Google Docs). Even with frameworks like Phoenix and runtimes like WebAssembly, you still need a lot of Javascript to get there.”
You really don’t need to write JS directly to make a UI like Google Docs with Phoenix LiveView. You can write the whole thing in Elixir. Thanks LiveView.JS, there hasn’t been a need to write custom JS or hooks to avoid a round trip to the server for UI-only interactions for quite a while, either.
For a canvas-based app, which to be fair none of my professional work has been, you’d need to write some JS or hooks to interface with external JS libraries.
Can you give me an example of when you would need a LiveView app to spawn a thread or set up an observer via JS?
Spawning a thread sounds particularly odd given that JS isn’t running on the server. Are you speaking of web workers? Or do you mean doing something from JS code to send a message to the Phoenix server to get it to spawn a process (i.e., a green thread) on the server?
Yeah, I meant web workers. It's easy to find canvas and web workers in any sufficiently complex highly interactive web app. I'm not saying you always find them, but if you're doing some form of graphics you most probably use canvas at some point, if you do non-trivial computation you spawn workers, if you need sound you use the Web Audio API, if you have a complex layout you're better off with DOM Observers, and so on...
The DOM scares the shit out of most developers. Those developers then twist themselves into knots with all kinds of nonsense to justify their aversion. Take the framework away and they panic, like stripping a person of their clothes before they are to give a big talk in front of upper management. You can call that autism, trend chasing, resume padding, cognitive conservatism, or whatever. The result is the same.
Whether or not writing to the DOM directly is easy is entirely beside the point. Their professional existence is tied to an unnecessary process and removing that process leaves them embarrassed, exposed, and extremely insecure.
The real reason is that the web started to become serious business, and that meant javascript had to become a serious language, which led to all of the nonsense it accreted over the years from startups and enterprise. Everyone uses frameworks and compilers and a package manager because a serious language uses frameworks and compilers and a package manager, and all of these look good on a resume.