"Frontend" is literally the integration of Web Platform APIs.

So you need (1) the knowledge of what platform APIs exist (2) the ability to reason about existing abstractions (3) the ability to define abstractions.

In modern life all three are considered unsafe things. Therefore to prevent people from entering invalid states exists The Framework: useless abstraction layer that does nothing besides be conventional. That's a common enough pattern anywhere population's above Dunbar; whether it's embodied by React or TypeScript or Windows or an entirely different order of lowest-common-denominator monoculture is immaterial.

Thankfully, software maintains an objective material component - the code, which they're trying to now turn into another wishy-washy thing you interact with using endless imprecise human language. Purely in terms of that, it remains possible to propose some ways to get a project off the ground more efficiently by virtue of dodging the toxic mainstream:

TL;DR conventional: native DOM manipulation; state management with Observable; Vite; TDD.

TL;DR forward-thinking: same but in proper static language: write in Rust, compile to WASM.

TL;DR exotic: ClojureScript or another Lispy language that compiles to JS or WASM.

Ofc, unless totally cowboying it, you also gotta be able to counteract the illusion of social proof. Ideally you want to be actively shaming people for building and normalizing bloatware. Preferably packing 1-2 yesmen worth of social proof of your own, just to get basic parity with the "best practices" in close quarters.

As always, depends on what you're building, for what purpose, and, critically, with whom... fuck all that though, the objectively bestest solution is always https://github.com/Matt-Esch/virtual-dom /s

That repo is a milestone of where history took its next wrong turn. I remember it making some waves when it dropped, and it's certainly the first VDOM implementation I saw. I considered it a good, original idea.

IIRC, React came around about that time: to take the simple and sane "VDOM" optimization, apply it judiciously (i.e. where it doesn't), and make it possible to bolt enough shit onto it (redux! teaching you to type the same thing thrice before typescript! SAGA! that one weird DB paper from '74 applied to frontends JS' half-baked half-async "generators", just to demonstrate to people that they should revere the old CS publications, and definitely not anything like read them or reason about them!)

Just so that people could hold bloody bootcamps about it, where they'd be able to weed out any junes capable of reading MDN for themselves. ("Bootcamp" is another cosmic joke like "Instagram" and "Trump". That thing where they harass people into obedience then turn them into socially sanctioned murderers? Ok checks out, let's name our programming learning experience! It's nothing if not profoundly mission-driven!)

Back in those days or a little later, I remember Vue 1 and 2 being pretty great: it somehow managed to do its thing without first having to introduce three whole new dialects of JavaScript and counting.

Overall I'm glad to be out of the frontend space for a good while now and only learning about it from the confused screaming of those still trapped there. (Oh and also Next's "static build" is a Docker container I had to cook up myself, which is a next level of ridiculous; as with VDOM, you first need to have seen the past level in order to recognize it as regress, and I presume a lot of people simply haven't had the opportunity to pursue any form of informed comparison)

(For "agentic workflows" idk -- just don't use them ffs the externalities are not remotely priced in; otherwise you'd be the exact same problem as them -- the designed-by-corporate-committee frontend DX of the past decade certainly strike me as something that'd make more sense to a statistical model than to a human mind.)

▲

tobyhinloopen 4 days ago | parent | next [-]

I don’t think you actually answered the question but I totally don’t mind because it was a fun read.

Old Vue is nice, we still have some Vue apps and they’re just running without major headaches. I do recall some distinct issues with properties introduced on objects after initiating the component not being reactive, but it has mostly been an acceptable experience

▲

balamatom 3 days ago | parent [-]

>I don’t think you actually answered the question but I totally don’t mind because it was a fun read.

That's probably the better outcome here. If you know enough things to find what I wrote entertaining, rather than vexing, chances are you're able to pick right tools for jobs just fine.

Meanwhile treadmills are gonna treadmill; if I've got one answer to everything it's to stay off them. Mighty difficult when everyone's trying to drag you onto one.

I do recall some distinct issues with properties introduced on objects after initiating the component not being reactive

Wasn't that what they fixed using Proxy (making ES6 finally a hard requirement for anything at all)?

>Old Vue is nice, we still have some Vue apps and they’re just running without major headaches. >but it has mostly been an acceptable experience

Better than one could say about the current generation stacks. Big vibe like vendors are trying to cargocult ZIRP-associated patterns (as if those were what produced value in pre-2020s Web and totally not all the human creativity that used to be channeled into the medium before the masks started falling off.)

	▲	tobyhinloopen 3 days ago \| parent [-]
		> Wasn't that what they fixed using Proxy (making ES6 finally a hard requirement for anything at all)? Maybe, but I haven't touched Vue in a long time. > Better than one could say about the current generation stacks. For sure. I still have some projects that use what I like to call "jQueryScript", where there's just a bunch of unprocessed (or only minified) JS files with `$("#foo").click(function() { ... })` stuff everywhere. Looking back, it wasn't all that bad. I just wish there was a pattern that is simple, works with plain, modern JS without any big dependencies (I don't want 600 node modules installing a frontend framework, please) and is easily modular and integrates nicely with other stuff (so likely either manipulating DOM nodes directly or using WebComponents) Out of protest, I have some smaller projects that have their GUI templates stored in `<template>` tags and manipulated with plain Javascript. Anyone that opens the code will see it and think "wtf?" and then be like "oh... uh sure". The largest one I had written was 1000s of lines of code like that, kinda like a classical MVC pattern where a view (class manipulating DOM nodes) renders a model (a JS object or class). The controller would subscribe to custom events (defined by the view), update the model and call `render()` on the view. It had a lot of small classes, which was a bit too verbose to my liking.

▲

balamatom 4 days ago | parent | prev [-]

Hahaha. What post. Forgot to add (!): that I have finally transcended the agony of the frontend space, does not mean a facet of my spirit does not perpetually lurk on that threshold in half-mockery, half-still-agony. (After all, cognitive science is yet to make a pronouncement as to whether it is possible to forget TypeScript.)

Do you want to be a spirit haunting the threshold in half-agony, half-but-also-mockery? It's accomplished by the "Figuring Out How NPM Packaging Actually Works So You Can Write Proper Isomorphic Business Logic" ritual, a fell rite from the forbidden "Uncomfortable Truths About The Presentation Layer" grimoire, and one that a lot of them would be better off with you not knowing, and now you do ;-)