new | show | ask | jobs Github

tobyhinloopen 5 days ago

[flagged]

▲

tomhow 5 days ago | parent | next [-]

Please don't post unsubstantive comments here.

▲

balamatom 5 days ago | parent | prev | next [-]

JavaScript was made insufficiently expressive on purpose (see Eich, Sun, Scheme).

He still ended up sneaking some metaprogramming capabilities into it, though he stopped short of something recognizable like macros.

So when the highest grade vendors started taking front end extra seriously since I'd say 2008-2010, what they built basically bulldozed over the things that made JS per se tolerable. Instead, they built frameworks out of the standard imperative primitives in JS, which take things in more of a C++-inspired direction.

The "growth hack" is here, as with vaunted Apple, vertical integration. The only way to couple markup to state management to server/client flow does not amount to a framework; it amounts to no framework since the Web was not invented by VCs.

To get a framework out of it, i.e. couple developers' practical knowledge to your ecosystem (turning it from general to domain specific but fuck devs right), you also need to couple things in your stack at the wrong places, as exemplified by the already much-maligned misfeature explored in TFA.

I.e. for the onboarding flow of a hosting business to work in 2025, you first need to have been teaching bad architecture for a generation. (It's why Meteor.js didn't take.)

On the one hand, pragmatic of Vercel to exist in the long shadow of the React/TS monstrosities. On the other hand, it's just one more company whose mere existence in this world has contributed for my work and life becoming harder for no real reason, even though nobody I'm within a handshake is even their customer.

Like many, I only learned of them only when I googled, "who the hell made this horrible thing the frontend team over is now stuck with, it's 0.01xing their velocity and frying their brains besides" and, well, now they're here. I would like to remind them to try and measure their externalities.

▲

tobyhinloopen 5 days ago | parent [-]

Is there a solution? What do you consider the least bad interactive frontend solution?

▲

balamatom 4 days ago | parent [-]

"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 ;-)

▲

5 days ago | parent | prev | next [-]

[deleted]

▲

globnomulous 5 days ago | parent | prev [-]

Thank you for censoring the word "shit." We try to keep Hacker News clean, for families and children.

	▲	tobyhinloopen 5 days ago \| parent [-]
		You’re welcome