There are some groups out there like Open UI[2] trying to push for this stuff but it seems like the standards bodies have no interest in a decent UI ecosystem instead favoring bloated APIs that make up 5% of your application versus the 95%. I'm mad! I'm mad online!

[1] I'm familiar with the newer carousel CSS/JS stuff but it's kind of clunky. I'll take it either way but damn

[2] https://open-ui.org

> Currently, we live in the JavaScript-heavy reality, where browser runtime looks completely different from source code files we work on.

Okay, in the article they wrote a Spring Boot server application. Does Spring Boot look anything like what actually gets run under the hood? Why did they not choose just plain Java, or hell just write the bytecode for the JVM himself - or write the actual machine code.

Of all the arguments, that one is probably the worst of them all against the current frontend complexity because we abstract literally every language in common use today for the sake of DX.

And note as complexity on the server side of applications have grown, so has the level of abstraction. The difference being backend applications had a hell of a head start.

I get why people like it, and I think it might even have it's place as a niche, but my main problem is that it's an awkward middle ground. If we say component based frameworks (react, vue, svelte) are too heavy, then we can still go a step further and say that htmx isn't necessary for a lot of plain static sites that need some reactivity.

Vanilla js with fetch, getElementById, innerText, is 99% of what people need for these types of simple sites.

If you're making static blog or landing page with HTML you won't hit many of the bad parts.

There's really no chance of fixing the HTML spec though, despite the many attempts, which tend to make it worse. Many of the framework authors know this, and in part that's why they've chosen such a user-space heavy path. It allows working around the bad parts of the platform, and iterating in ways where ideas that don't pan out can be left behind.

10 Brute force medium into doing what it was not originally designed to do

20 Insist on native support for what was once a hack

30 goto 10

On the one hand you could say it's clever. On the other hand you might insist it's foolish to repeat this cycle. I'm not naïve, complaining, nor suggesting I have a better solution, but rather just making a personal observation.

(And regardless, I've been fortunate enough to make a living off this cycle for about 20+ years, having done it for fun for about 10+ years prior.)

1. Big frameworks were pushed from companies to the user base, most of the software stack is, instead, organically created by the programming community. So we have things like Angular and React that are big-company-design stuff that became normal programming. It's like if every site runs on Kubernetes.

2. There was, in big companies, an extreme desire to do two things: totally isolate frontend from backend, because the internal organization of big companies has such a split, and to make applications so standardized that hiring new people, firing old people, is something possible and easy. Fast, highly reactive applications written using semantical HTML and just the amount of required Javascript are, instead, general code, and each app is a little different, or even a lot different. So those two goals are not aligned to producing great web apps, but to internal requirements.

3. We later created a generation of programmers that can't even understand a single language very well in its internals, that is: Javascript, they often know the framework, not the language, nor even CSS well enough. So they are trapped into the ecosystem of knowing React or Angular or something like that. It was enough to have a high paying job. Now, those folks, the way the were trained and the way they work makes of them not really general purpose programmers like you could find 10 or 15 years ago. And now the industry is kinda trapped into this situation also because of people abilities.

Of all that, in theory, I don't care much, I can write my stuff as I want. But:

A) The web is terrible now, it is slow, eats a lot of memory, and is fragile. So this impacts me.

B) The big salary front-end folks culture is also made of a lot of people that don't realize that they move in a very limited field of what they believe programming is, and are arrogant enough that if you do something in vanilla Javascript, fast, well coded and that works well, you will be accused to do things in a odd / old way. Many of them basically actively resist to making the web more sane.

I believe LLMs are going to change this thing, as now there is less direct exposition to the specific code, and things can be more easily refactored in versions of the same app that are saner. We will see. But nothing in programming, in the latest decades, was at the same level of mess as of front-end development.

The irony is that front-end developers highly suffer from all that, for a number of reasons: they are forced to continue learning new ways to do the same button, form, pagination, and so forth. And, also, if they are smart they understand they don't really know what programming really is in most cases, and are not happy about it.

Anyway another thing that kept bugging me when reading this is that web apps and development and performance constraints can be so vastly different that I am not sure this pattern always holds up. What if you have an app that depends on a ton of global state, what if you need web sockets, what if you need a highly dynamic form with partial validation derived from a schema that your drizzle definition spat out. And 2 junior devs that benefit from end 2 end type safety and working in Typescript alone to be productive. Add syncing across tabs, offline first requirements, multiplayer rich text editing, sophisticated auth, caching, accessibility constraints, end 2 end monitoring and logging with open telemetry, animated page transitions scroll timeline animations, pdf generation of certain views and a design team breathing down your neck that has a thousand different extra bells and whistles it wants that are impossible to represent and maintain with tailwind alone. And then the marketing department comes around and wants to track everything, inject their A/B testing framework, wants dynamically updated translations without forgoing SSR and SEO benefits and all of that has to run on a 8€/month Hetzner VPS.

I understand that if you work on software that only needs a handful of those things you can get away with a better stack than what the author seems to loathe. But it you work on a large enough application, then you can’t escape complexity, even if you find some of it remedied by a well suited tech stack.

There is some essential complexity that will arise in this space because a client/server app fundamentally can't abstract over the client/server division. There's not much you can do about that... well... you can overabstract and try too hard to wipe it away, and fail, and make something that will be worse to use than an approach that acknowledges and understands the distinction, which is a modestly popular approach... but there's no way to get rid of it entirely.

There is some complexity that is going to be essential in an app context where the DOM is not exactly the best API for interacting with an application, and there is always complexity where there is an impedance mismatch.

Those two things alone are non-trivial on their own. Exactly how much they account for the complexity of the current approaches is up for debate, though.

At the risk of incurring some ire in replies, it's not clear to me that if someone sat down with a clean sheet of paper and tried to create a new platform that roughly matched the current web platform in capability that they could do that much better. There's a lot of deprecation that could be trimmed off for sure, but perhaps for the purposes of this discussion we wouldn't count that against the current platform too hard. (The new platform will only be missing it by virtue of being too young to have it; over time it'll pick it up too.) Maybe building in some sort of reactive-programming capability at the base. A better version of web components that works well enough to be the de facto standard and prevent too much competition from emerging. But whatever data structure you use to access your app, it's still going to have roughly the complexity that we have today. You could do some better. But I'm not sure you could do that much better, such that it would be heaven compared to today. It's still going to be huge and complicated and have all sorts of weird interactions when you try to put the pieces together.

Trying to build an app in a language that is also trying to be a high-powered layout language (it's not the best, not exactly "commercial quality", but it's pretty capable) that is also a document standard that is also the de facto VM for the world is not going to be simple.

It feels like the jquery years all over again when the landscape was filled with frontend influencers peddling their speaking services to talk about their naming semantics for css or whatever.

Not saying complexity doesn’t exist and maybe some of it isn’t needed but a surface level blog post that conveniently smooths over all the nuances and problems developers encounter in the real world doesnt do much for me. At worse it just adds to the pile of misinformation about front end in non toy applications.

What used to be a simple <form> and a redirect now requires client-side validation, dynamic forms, an API endpoint to POST, reactivity, client-side templating and data binding, etc.

> TailwindCSS to make styling easier

Wait the article complains about complexity and the suggests using Tailwind?

You need to show a real application with pieces of the system that coordinate and complex interactions. Recreate Jira's backlog and sprint board that can have an arbitrary set of business logic for how a ticket moves through a workflow. Put it through its paces, don't give me a toy.

I used jQuery, Angular, Angular 2, React. I did JavaScript then TypeScript. I configured freakin Gulp, Grunt, Brunch, Webpack 1 to 5, and now Vite, idk maybe in the future Eggpancake or something. I even had the unfortunate stint on working on configuring Bazel to a frontend monorepo.

So I get it, I get the pain. As someone who lives and breathes JS/TS, even I myself feel the pain.

I can't tell how many times I looked at other languages like Go, Ruby, Python, or even newer ones like Elixir, to see if I can just simplify this whole madness with HTMX, Datastar, etc.

To be honest. I still haven't found one that's even incrementally better than the current SPA stack (and no, I don't use NextJS or React Server Components). A bunch of the technologies above simply just mix and match with a lot of impedance mismatch.

It all boils down to this fact. Modern web application is essentially 2 apps (frontend and backend) that lives in 2 different environment. Each with its own constraints.

I accept this fact as the ground zero truth, and just surrender to the current way of building things. That is, you have to build 2 things: SPA frontend client and API backend server. Yes, you have to validate and secure both. Yes, you have to test for both.

The end result is much more robust, in error handling, in user experience, in performance (yes), in malleability, in maintenance and extensibility, compared to the server rendered stack with bolt on jQuery/HTMX/etc.