In college, when I began dabbling with my personal website and browsing Orange Website, I formed some opinions. One was on JavaScript. How dare a website have the audacity to load an entire megabyte of JS just to display some text and links? We don't need distracting animations! Interactivity? Nothing a clever <a> and CSS pseudoselectors can't do.
Well, I ended up also requiring PHP. And then I broke my Apache config beyond repair. And nginx configuration makes more sense. But I can't get PHP to work on nginx (I'm trying, don't you worry). So my option seems to be...rewrite everything in React, which I know.
And why shouldn't I? Almost everyone has JS enabled. Accessibility isn't a problem with modern frameworks. And besides, I just _like_ React. Ever since I first touched it two jobs ago it just makes sense to me. Plus, with some SSR via Next.js, I can get my Markdown files to render as HTML without the PHP dependencies I had before.
Don't get me wrong. JS has its issues: loose typing, prototypes are a catastrophic shadow of their proper OOP equivalents, and silently swallowing errors, to name a few. But I'm not gonna pretend that I haven't run into similar problems in my favorite language, C. Memory leaks, segmentation faults, and header file hell aren't fun. But once you get used to the quirks of a language, those issues stop cause you to slip up.
I'm not gonna say I don't appreciate a simple site without JS, like the lovely Midnight here (sidenote: dirty http user here), but sometimes I just want to have fun making something. And for me, JS is the right choice.
I still think that the best and shortest fantasy novel ever written is *JavaScript: The Good Parts* by Douglas Crockford. I don't think it has any good parts. Nevertheless, I'll hold my nose and use it at my day job if I absolutely must.
JS the language is not great, but not horrible. The real problem with it is that the way it's used today, and the way browsers have developed to accommodate that use, is counter to both the spirit of the early web, and the design of its protocols. A web browser is supposed to be a general purpose client for hypertext, and applications are supposed to take advantage of the browser's features: this architecture came to be known as REST (representational state transfer), and one of the most important constraints is HATEOAS (hypertext as engine of application state).
But what happened was that browser use and support for client-side scripting increased at the same time browser hypertext features were stagnating (e.g., no rich type-aware form controls, no way to declare links as asynchronous or fetching hypertext into the current page). So applications started being written as client-side scripts, and that drove browser development in the direction of just being a runtime for client-side programs, in a mutually-reinforcing way.
As a result of that, we no longer have an interoperable meta-client for every web app, we have custom apps and custom protocols that you download and run, just like before the web, but less efficient. Plus, you don't really get any choice about what you download, install, and run; it's just done for you without asking permission. While those programs are sandboxed, the sandbox is frequently leaky, and things like speculative execution attacks mean that nothing is ever really securely sandboxed from the rest of the system.
JavaScript the language doesn't really enter into this. The browser scripting language could have been Scheme (it almost was!), and the ecosystem would still have been just as bad if the same historic pressures were in place.
I love pure clean JS. The language itself is a delight to work in. It's the bloated frameworks that give it a bad name.
Makes sense. Back when I started in web, it was very frowned upon to rely on js, but things (browser standards, computing capabilities) have changed since then. Horses for courses, I reckon. There's a time and place for js and it can be lots of fun.
I've never seen someone attempt to replicate a fully-featured site with CSS.