>Modern frontend development provides many opportunities for failure

I think this is the important thing here. Everything feels less stable, and more prone to breaking, on the modern web. You write some simple HTML, style it with CSS, and write vanilla JS for the parts that need it, and everything feels solid. You start a new project with a framework, and it seems like there is this whole area of your project that is essentially a black box, ready to break (or misbehave) any time.

Is anyone aware of a tool that would allow me to manually walk my entire app and any css that doesn't get used can be flagged for deletion?

I find that even with well behaved libraries and tree shaking, my output css still includes a lot of stuff I don't need. (Eg. Yes I use Foo.Button but I don't need all the css for the styles of Foo.Button I never use like circular or large or withIcon)

I absolutely despise writing any kind of GUI/graphics/layout code in React's clunky long-form declarative style, but for whatever reason it's really starting to take off. I guess it's a sign of the times: there are developers these days that have quite literally grown up on React. It's starting to feel like XML (used everywhere, even when it might not make much sense).

But to me, the code is longer, more unwieldly, more prone to error, and to top it off, it also inherits all of React's annoying idiosyncrasies. It's weird to even type this out, but Java's Swing felt more intuitive than seeing D3 on top of React.

For example:

      <circle
        cx="150"
        cy="77"
        r="40"
      />

Just the fact that this could technically be written as draw.circle(150, 77, 40) in any sane programming language should give you some pause.

The trouble generally is that JS is used despite the content being static, or independent of client behavior/usage.

That is, JS can be used to do everything but it is not optimal, or even near optimal (or even remotely close to) for many use cases. In terms of runtime or simplicity. But because it is capable and available, it has encroached into every niche (of html/css) until like any invasive species, it consumes and shreds through all available resources, collapses the whole ecosystem, and all complex creatures give way to a fresh start with new fairly rudimentary biology (wasm) trying to evolve towards and find a new stability point — hopefully one that does not invite a similar destructive species, but we’ll see how it goes

For those interested, I built a "falling notes" style web interface that works with a midi keyboard. You can mark a split in the keyboard and just practice one side or the other. Most of the controls I've baked in use the keyboards other buttons (Novation Launchkey 61).

It's open source so feel free to adapt as needed.

https://benkaiser.github.io/learn-piano/

I've found it works well for my wife and I playing simple songs together, she never learned sheet music (and I'm not great at it) so this format is very easy to follow.

There's a increasingly larger amount of web developers who are only "trained in React/Angular/Vue" and are unable to understand how to use or the trade-offs of regular websites using just HTML+CSS with only a little or no JS (that goes for both templated or fully static sites), and a surprising number of them even thinking they are some kind of "legacy technology".

At the very least, this kind of article is informative for that crowd.

It's funny to see us remembering that things can be done on the server. The trend to render everything client-side has always been troubling to me. Such a waste of resources (but it's not your resources, so developers don't care). Sure, things that are truly dynamic or are different for every user is probably usefully done on the client. But a static page with code samples can easily be rendered on the server, with syntax highlighting, and then cached. You only need to do it once, rather than hundreds or thousands of times on every client device.

We went away from node as a backend technology for a bunch of reasons. Here's a list of the biggest pain points:

- Lack of a good standard API; compared to environments like Java, C# or Go, node's standard library is significantly sparse.

- The tendency for small libraries/frameworks leads to a very high number of third party code with all the problems attached; bigger attack surface, licensing challenges, it's economically impossible to vet and review dependencies

- There's a tendency in the ecosystem to abandon projects rather soon (~1-2 years) and to keep changing things. Further, we have had several situations where maintainers did not respect semver, combined with npm's approach of updating patch versions upon installation, we have had too many broken builds from one day to another w/out code changes. The state of documentation of a lot of projects is non-existent.

- Lack of multi threading. We have used all the options, including RPC implementations, but that doesn't even come close to approaches like Java threads or go routines. Neither in performance, nor in maintainability.

- Lack of typing. That's probably the biggest one. Yes, we use TypeScript, quite extensively even. But TypeScript brings its own problems. First, it's only declarative. If you have a `something: number`, there's no guarantee that it's actually a number upon execution, so if you have a bug in a layer interacting with another system, that might fail a couple levels deep. You hence end up with type checks at some places and you cannot really trust it anyway. Second, TypeScript's tooling is slow and has some annoying quirks (e.g. aliases not being resolved upon compilation). Having aliases allowing to shorten import paths is a big, big win, though. Third, the typing, given the complexity of JavaScript, can be confusing, sometimes even seemingly impossible to get right.

Is node a bad technology? Not at all. I'd not chose it for enterprise, big or long-lived projects, though. It's a very good technology for a lot of things, especially smaller projects. We are building on Java + Spring Boot now.