For the front-end I write SPAs.

I rely on the TS compiler to bundle into a single JS file, so I avoid bundler (etc).

I build a simple framework that meets my needs that I can essentially vendor and keep in my head. I'm would love to use an established framework rather then my own (don't get me wrong, there are serious downsides to rolling my own), but it must be small enough I can read it easily in a single sitting. I will not touch the NPM ecosystem. I sometimes will pull a dependency in by manually copying in the parts I need (preserving licenses, etc).

There are real downsides to doing what I do, but I do it to keep myself sane. I do not touch the npm ecosystem.

I also review every line of code I pull in from any language (Go, TS, etc). An ecosystem that makes this difficult or impossible is just a non-starter.

This is been the sanity-saving solution for me. I roll 100% of my own stuff in TS and web components. It sounds awful -- unless you compare it with fighting someone else's dragons.

This way, the only dragons I have are ones I created and ones I can slay. The more I write my things in functional style and build only exactly what my application needs, the company's "framework" continues to evolve AND our apps continue to work!

No one is going to change any of the "ecosystem" out from under me because there isn't one. Everything is compiled in Vite (automatically and hot reloaded) and I only ship a minified, static, single index.html file with my entire app in it. There are no globals that I didn't make, no functions that are required unless I required them, etc. It's a HUGE timesaver when debugging or adding new things the team requests.

I'm able to continue to write new, cool stuff in both our public-facing web app and in our internal web tool (game dev), both on the same framework.

I once suffered from Javascript fatigue, had to work with frontend anyways, and had the privilege of picking my own tools.

That's when I started experimenting with Elm, Bucklescript (now ReScript) and Clojurescript. It was a very insightful journey that made me enjoy frontend development again.

Today, Clojurescript is my favorite method of working with frontend code and, as long as I can pick my own tools, that's the one I'm sticking with.

For those suffering of Javascript fatigue, I highly recommend playing around with these alternatives. Try doing a simple, small side project in them. It may reignite your joy for programing and who knows, maybe you can find a job to work full-time with these tools.

It's worth stating: you can write frontends without buying into the ecosystem at large. I've been working on a multiplayer video game using Go + websockets in the backend, and a JS frontend with zero dependencies.

IMO JS is really fun to program this way. You program straight to the capabilities of the browser. All of the problems people promised I'd face by avoiding their framework of choice didn't show up after all.

If you don’t like JS/TS then just don’t do front end? There’s plenty of backend only jobs.

Or remember that there are actually frontends other than web browsers.

Yes, there are web browsers and then there are electron ones.

Just learn Next.js (Vercel), TypeScript, and MUI and don’t use anything else. Make sure you also understand CSS flex-box and such.

[upvoting solely for your username]

I stay away from all the JS dependency bullshit as much as possible.

I use vanilla JS & CSS wherever possible, usually in a Go template.

If I have to create a SPA then I use Vue - I've found it's the least complex of the front-end frameworks. I build it using ESBuild from the flat JS files downloaded from the Vue site and stay as far from yarn/npm as possible.

I'm trying to work out how to compile Go to WASM and manipulate the DOM easily from there, but so far it's more complex than just writing JS.

Any Go WASM solution will come with big performance costs and complexity that are worth considering:

1. Since WASM doesn't yet expose a feature to share GC with the host, the GC functionality with necessarily be bundled with your outputted code, making your WASM size larger than ideal.

2. All calls from WASM have to go through a JS layer in order to interact with the Web APIs anyway, so now you actually have _two_ GCs to run.

3. The developer experience is going to be poor unless you write a shit ton of wrappers for the existing DOM API.

I say the above not to dissuade you, I find WASM an attractive value proposition and use WASM in all sorts of ways in personal projects. Good luck

I'm not bothered about GC's - the size is a problem, but I've never had to worry about GC performance issues yet.

Everything else is spot on, that's the pain!

You probably know about this, but it might be worth trying TinyGo[0] for WASM, given that WASM is basically an embedded environment.

0: https://tinygo.org/