alt.hn

4/19/2026 at 1:10:51 PM

Modern Front end Complexity: essential or accidental?

 https://binaryigor.com/modern-frontend-complexity.html

by gsky

4/21/2026 at 8:14:51 PM

One thing that has been driving me bat shit as an FE for years is the lack of browser engine implemented basic UI elements as default HTML. The fact that we still need to build custom carousels[1], tooltips, and other common patterns instead of just dropping a <carousel><slide></slide><controls></controls></carousel> or <tooltip/> is baffling to me. Stop making me write so much JS to do something that we know as a community is going to be a pattern! Just gimme the damn elements and a decent API to manipulate it reasonably! Not to mention all the custom, half ass a11y implementations I see.

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

by gibsonsmog

4/21/2026 at 8:51:17 PM

> I'm familiar with the newer carousel CSS/JS stuff but it's kind of clunky

I think you've just answered yourself why.

Browsers are the most used applications on the planet. They have one chance to get an API right ("don't break the web"). They iterate on a new API for years. When they finally launch it, devs call it "clunky".

by dalmo3

4/21/2026 at 9:17:06 PM

The CSS-only Carousels have gotten really good and easy to drop in lately.

Most tooltips can be handled by ancient `title` attributes and the ones that can't should generally be popovers anyway. Firefox support for anchor positioning is out now so HTML+CSS-only/mostly popovers are in a great state today.

There's always more UI controls people think they need. The web will be forever chasing that. But so much has happened in recent years it feels good to stop a moment and appreciate all the little things like details/summary working great for JS-free expanders and accordions.

by WorldMaker

4/21/2026 at 9:32:44 PM

Counterpoint: the standardized surface area of a browser is already enormous, and while these components seem simple, there are a billion different options, variables or alternative implementations to consider.

At some point, functionality needs to exist in user space, even if it's common.

by lukev

4/22/2026 at 8:31:44 AM

Yes, please! But browsers need to make it easier for things to exist in user space. That means reviving CSS Houdini, particularly reviving the animation and layout worklets. (It got abandoned because browser vendors (Chrome in particular) found them too difficult to implement. They would need to rearchitect a good chunk of their rendering pipeline. Instead we got a bunch of very limited but easier to implement features like scroll animation timelines)

by YmiYugy

4/21/2026 at 9:38:52 PM

I'd really like to see some FE folks kicking around what sorts of new form elements they'd put into HTML 6. I miss WinForms, component libraries, Silverlight, WPF, that sort of thing. Browsing the sea of components somebody like Telerik or Infragistics or DevExpress give you brings so many ideas to my mind. The web has nothing to show for decades of being in the limelight. We have buttons, textboxes, checkboxes, drop down lists... the end. Oh I guess we have date pickers now, and reasonable large text areas. I mean we build apps this way so it's not impossible to live like this. I'm just jealous of folks with Blazor and a component library license.

by JohnDeHope

4/22/2026 at 1:19:19 AM

> lack of browser engine implemented basic UI elements as default HTML.

I'd argue that browsers already have full set basic UI elements.

But the thing is that "basic set" is different for each developer / site and that is OK.

Attempt to make a browser to include everything is a path nowhere. Today we have carousel as the thing, tomorrow something else.

That's the moving target. And don't forget about versioning. Each feature has to have a fallback:

   <carousel>
      ...
   </carousel>  
   <nocarousel>
      ...
   </nocarousel>
Old browsers and old machines are still there.

Instead we should have really handy component system like

   <section class="carousel">
      ...
   </section>  

   <style>
      section.carousel {
        controller: Carousel url(/js/carousel-desktop.js); 
      }
      @media handheld { 
        section.carousel {
          controller: Carousel url(/js/carousel-mobile.js); 
        }
      }  

    </style>

by c-smile

4/21/2026 at 6:20:19 PM

I never really understood this argument:

> 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.

by Jcampuzano2

4/21/2026 at 8:16:52 PM

I don't like this argument either, but in its defense, it's presumably comparing modern web page source code not to Java, but to historical web page source code.

by tshaddox

4/21/2026 at 7:48:10 PM

> we abstract literally every language in common use today for the sake of DX

The fact that the Javascript ecosystem is not any different than the others is a huge missed opportunity.

by JodieBenitez

4/21/2026 at 7:37:43 PM

(Did not read the article, can’t speak to the exact argument the OP made)

I like this argument in the sense that JavaScript & HTML were/are awesome because you can learn from websites that you like the look of. You can just pop open inspect and directly see how to do something.

Modern frameworks have largely broken this to the point that it’s pretty difficult to understand what’s going on on a lot of pages

by coffeeindex

4/22/2026 at 6:17:22 AM

Yes, but it's not the fault of these frameworks. If people wanted to they could ship source maps on purpose and not just accidentally. Not exposing source code was one of the early drivers for tooling.

by YmiYugy

4/21/2026 at 7:38:50 PM

Ok, this article is basically about htmx, and htmx style web dev rather than being about front-end dev as a whole.

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.

by preommr

4/21/2026 at 8:39:50 PM

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

But it's not only for simple sites. Don't underestimate the power of, say, a SSE stream using brotli compression: this can stream a shitload of data for serious apps (like real-time financial data).

Resource usage on the client-side is also close to nil with a SSE stream and minimal JavaScript and on the server-side it hardly changes anything: that data was going to be sent to the front-end one way or another anyway.

And if you take something like DOM morphing and, say, Datastar: it's not conceptually that different from React. The DOM reconciliation doesn't happen at the same place and not in exactly the same manner, but it's not entirely dissimilar IMO.

It's not just htmx: there's are different projects and, interestingly IMO, developers from many different languages who are now beginning to tackle this problem of Javascript (way too) heavy frameworks.

I think it's a bit early to say this is a niche.

by TacticalCoder

4/21/2026 at 9:44:46 PM

In my (small) experience, SSE is a bit finicky: 1) Firefox kills a webpage's SSE connection when you close and open the laptop lid, making you write code to reconnect, unlike other browsers; 2) there's no way to see the HTTP status code if something went wrong; 3) proxies can still mess things up sometimes: https://dev.to/miketalbot/server-sent-events-are-still-not-p...

If you have a constant stream of data, SSE does make sense. But if your goal is to have events arriving infrequently or a irregular times, then good old long polling will work in strictly more cases, at the cost of maybe 2x more resources.

by cousin_it

4/21/2026 at 6:26:54 PM

I dunno, the "complexity" seems mostly from:

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.)

by settsu

4/21/2026 at 6:30:35 PM

The article started with showing how complex the frontend is. And then moves the complexity to the backend, with tools that aren’t well supported and putting extra load on the server. For some applications, this is a good solution, for most, however, it’s not.

by edwinjm

4/21/2026 at 6:40:40 PM

> with tools that aren’t well supported

This is an odd thing to say about the backend choices. Spring is ... well let's just say there are a few folks in and around that area.

by jacques_chester

4/22/2026 at 7:06:05 AM

I think it's totally fair, but I would assume that most Spring projects make significant DX tradeoffs compared to a full JS stack or serve an API rather than html. 1. Spring + Handlebars: You can either write the html template in a string loosing syntax highlighting and other LSP stuff, load it from a file loosing colocation. 2. Handlebars + webcomponents. They simply bundle all the web components into a single file, which breaks down when they get large and you don't need every component on every route. 3. Tailwind: Looking online you can get it working with spring boot, but the route chosen here is a script to run the cli, which again means every route ships every tailwind class used anywhere.

by YmiYugy

4/21/2026 at 10:40:19 PM

> putting extra load on the server

This is precisely where the publisher has the most control over the user experience. Putting load on the browser makes a user's experience dependent on their hardware & software stack.

by runako

4/22/2026 at 6:28:08 AM

Part of what makes a good user experience is is working nicely with the users hardware and software stack and that's much easier on the client. The user would like the website to have native scroll physics, respect their system preferences, react to changing window sizes and with different input methods, screen readers and so on.

If the key to a good user experience was server side control, than the hallmark of a good website would be being an RDP stream and prefers-color-scheme wouldn't be a CSS feature but a HTTP header.

by YmiYugy

4/21/2026 at 7:51:07 PM

Reasons why the web is such a shitstorm:

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.

by antirez

4/22/2026 at 8:07:38 AM

1. I think it's pretty clear that the frameworks sold themselves, because it's possible to see the DX benefits with anything beyond a hello world. You don't need Meta's scale. It came from the big companies because they needed it most, not because they are the only ones who benefit.

2. I agree that the frontend-backend split caused a lot of harm and it seems most places are moving on, but it

3. It's a fair assessment that many people don't understand JS well. But it's also a super quirky language with many features that probably should be considered "do-not-use". Things like messing with the prototype chain, purposefully using == instead of === etc. CSS is even worse. The defaults are weird, which is why everyone uses some form of CSS reset, many things have surprising names and refactoring in a codebase with complex usage of selectors and cascading is a nightmare.

But I wouldn't call people trapped in frameworks. It's pretty easy to switch between React, Svelte, Angular and co.

A) The gone by days of Java Applet's and Flash weren't so snappy either. Our websites also do much more. A tab of Google docs isn't slower or use more memory than a Word instance.

B) No group is ever immune to arrogance. But sure, if you write vanilla JS instead of TS, I'd think that's an odd choice. I'm not saying you can't make good things with Vanilla JS, but I don't see how that makes the Web more "sane".

LLM: When it comes to coding tools LLMs are not so different from humans in what helps them. They benefit just as much from the cleaner control flow of reactive frameworks (compared to jQuery), colocation of JSX and tailwind and typechecking of TS as us humans.

Mess: Has the Web really been such a mess lately? I think most of the messiness is far behind us. JS+HTML5 winning out against Flash and Java, standardization across browsers, XML or HTML. Was it worse than Microsoft reinventing their Windows UI framework every couple of years?

by YmiYugy

4/21/2026 at 7:30:09 PM

Is there a good reason browsers could and or should not support ts out of the box? I think even node does to some extend.

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.

by Escapado

4/21/2026 at 8:15:16 PM

I would guess that the big reason is Microsoft is the owner of Typescript. Apple, Google, and Mozilla probably don't want to be tied to the whims of someone else's language specification. It's the same reason Dart isn't a browser language, NaCl doesn't exist anymore, ASM.js development wasn't widely adopted but sowed the seeds for WASM.

Web standards get worked on by committee where those four companies each have some pull, and standards are voted on.

Node's typescript support is by default just stripping all of the type information out of the source text. There is experimental support for some transformations behind a flag.

https://nodejs.org/api/typescript.html#full-typescript-suppo...

by ppseafield

4/22/2026 at 1:49:08 AM

> Is there a good reason browsers could and or should not support ts out of the box?

Yes, there is a reason. Most critical requirement for the "language-behind-web-UI" is to be efficiently parseable (parsing speed and memory). So it should have one-pass compiler/interpreter without the need of building AST (syntax tree). Speed of execution and type strictness is on the third and tenth places correspondingly.

JS matches that basic requirement but TS is not.

by c-smile

4/22/2026 at 7:10:33 AM

There are proposals with some traction that would enable webbrowsers to parse TS, but simply ignore the types. I think it's a bad idea, because tooling handles that perfectly well and I think browsers should generally avoid building functionality that could be equally well provided outside it, but I guess enough people have been asking for it, so it might happen.

by YmiYugy

4/21/2026 at 7:52:44 PM

> Is there a good reason browsers could and or should not support ts out of the box?

Because it’s a Microsoft product and Microsoft still follows Embrace, Extend, Extinguish process. Once every browser supports TS, what prevents Microsoft from revving TS with a license change? Who’s going to take over the TS fork?

by bevr1337

4/21/2026 at 6:30:08 PM

One can observe that even the proposed alternative is still awfully complicated compared to the web apps I remember making circa 1999. Much more capable, but still more complicated. Of course the entire "typescript -> compile -> minimize -> pack -> etc." pipeline is yet more complicated.

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.

by jerf

4/22/2026 at 8:14:52 AM

I think cutting the legacy and doing things with the benefit of hindsight would make for a much nicer platform. For example something like CSS Houdini (making CSS extensible) might have actually happened if browsers where designed for it and would make Web Apps a lot nicer.

by YmiYugy

4/22/2026 at 6:40:46 AM

The article lists, things like transpilers, polyfills, tree shaking, minification, CSS transformation, then declares that this is all super complex and that we need to start over. To me as a dev these are elements that have started to work transparently a long time ago. It just isn't something I worry about in my day to day frontend work, the same way a Spring + HTMX user doesn't care about the Java -> JVM -> Assembly pipeline. The most complex things I deal with as a frontend dev is 1. Browser issues 2. Server client communication.

by YmiYugy

4/21/2026 at 5:59:47 PM

Too often I read something frontend related on HN and am disappointed to find it’s full of hyperbole and/or just a lack of experience or knowledge at what having an actual job writing code on the frontend of a real software customers pay for is like. And half the time their “solution” is swapping out some predetermined mashup stack (usually nonsensical or worse, thrown together by a first year grad) for some other trendy tech.

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.

by telman17

4/21/2026 at 6:15:04 PM

The HTMX route that this article is advocating has some value.

My YOShInOn RSS reader works that way and I think it is great -- but it is my own thing and I don't have customers and managers coming to me with requirements and I can build everything with that architecture in mind.

As I see it the basic front end problem is that you click on something and then the page is updated and this updating could be really simple (like you are typing into an autocomplete box and search results appear under it) or it might impact a large number of elements spread all over the page and some applications might be very dynamic and updating dependent on the UI state and can't be figured out ahead of times (imagine a developer tool which has lots of property sheets and tool windows)

HTMX is very simple for the simplest cases, requires some back end framework for harder cases (like a page might have 20 partials in it when it draws for the first time, 3 partials need to be redrawn when you click on something, you need to format a response packet that draws those 3 partials in the right place) and breaks down for the hardest cases. Part of the React puzzle is that we often use React for apps that don't need its full power but hey, even for something CMS-adjacent why fight with unintuitive Markdown (face it!) when you could write

   <MyElement attributeThatMattersToMe="yes">Here's the content</MyElement>
which conforms to your needs.

As much as I love HTMX, I got into it when my dissatisfaction with React was at its peak, more recently React is my go-to for anything from whimsical personalized landing pages to biosignals application that use Web Bluetooth, USB and Serial. Why? I use it at work all day and know how to get things done. I can draw anything at all, even 3-d worlds with A-Frame. That frustrating build system is clearing up.

by PaulHoule

4/21/2026 at 6:47:46 PM

> Here is an idea: UI mostly server-driven, server-side rendered with the use of HTMX

Yeah it's more HTMX evangelism.

I agree with you, but I can sort of see their point. I have successfully advocated for and implemented very barebones static HTML/CSS pages for some clients in the past, but that's rarely the right choice. They wanted deep control of the exact markup and style because they cared the most about SEO, WCAG compliance, responsive mobile design, and legacy browser support. They did not have much interactivity apart from a couple of form tags. They even worked flawlessly without javascript enabled.

I know that sounds appealing to the naive and stubborn types who hate all other web dev, but there's a catch. The "simpler" a web page is, the more testing there will need to be. You're not reducing the complexity, but just moving it somewhere else. These pages were micromanaged into oblivion with frequent audits by large teams each with their own specific concerns. The majority of my time was coordinating a circus, not writing code. In that kind of situation, there is no other choice. It was an absurd amount of testing to make that work. All that for pages that barely did anything, and questionable business value. If you want your "bullshit job", look no further than that type of web dev.

The misunderstanding I see over and over is not realizing how broad web development is. I wouldn't be doing my job if I didn't optimize for maximum flexibility of the most actively developed implementation details the client cares about. The higher value web dev is interactive functionality, not bullshit marketing pages.

All I can really say is HTMX is not a tool I see myself ever reaching for any serious production use case. It will never beat plain static pages on flexibility, speed, or scalability. It will never beat serious web app frameworks like React or Vue on developer ergonomics and tools. More generally, server-side rendering is shooting yourself in the foot the moment you need to host off a CDN or migrate. The list of downsides is endless.

by sublinear

4/21/2026 at 6:12:26 PM

The reason things look the way they do is certainly historical, but it's not developer's desire for great DX or user expactations - the later at least not directly - that drove us here. It's the requirements of enterprise processes that got us here. The popular stacks very much carry the mark of enterprise. BTW, you did this in Spring: another prime example of enterprise driving development process architecture. If you want to enhance that, you should focus more on requriments such as separation of concerns, developer replacibility, user tracking and marketing chances than UX and DX.

by schrotie

4/22/2026 at 1:42:31 AM

You can still work with vanilla PHP, jQuery, and vanilla CSS if the project allows it. Things are more complex typically because the requirements are more complex.

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?

by pier25

4/22/2026 at 1:57:38 AM

Bootstrap is immortal

by danny_codes

4/21/2026 at 7:07:26 PM

The argument that the code typescript developers write isn't exactly what browsers eventually execute isn't convincing. Don't we have compilers and other tools in pretty much all mainstream languages? The tooling isn't an issue, and we don't even need HTMX for SSR.

by Pavilion2095

4/21/2026 at 7:14:25 PM

Is mobile dev more or less complex than web? If less, why? Genuinely asking. Seems like they’d have more or less the same constraints.

by brap

4/21/2026 at 7:55:03 PM

I am a primarily frontend learning fullstack guy. I've been working in this space for about 10 years.

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.

by frontenderdude

4/21/2026 at 10:46:00 PM

> Modern web application is essentially 2 apps (frontend and backend)

This doesn't have to be the case, though. We all use e.g. banking & telecom sites that worked fine before being rebuilt using "modern architectures" and now are memory hogs. There is no reason many/most sites cannot go back to simpler architectures (other than programmers have forgotten how to build those sites, which is in fact a real problem).

I do hear the argument that when you start building, you don't always know whether this simple brochureware site will evolve into a multimedia player platform, so just start with the assumption you will need the capabilities of a complex FE stack. But in the majority of cases this will end up being the wrong choice, and clients/employers will end up spending too much money managing too much complexity.

by runako

4/21/2026 at 8:22:46 PM

If I'm building something for myself it's always Django + HTML/jQuery, it's crazy how productive that is for me.

For work it's react/TS/express/...

Both have there uses and places.

by johsole

4/21/2026 at 6:14:41 PM

Author took the most simple application and managed to make it so complex beyond belief. If he needed all this for 1 modal, I don't even want to imagine what would he had done if he had 10 different types of modal with 10 different rules as any half complex application has.

by YetAnotherNick

4/21/2026 at 6:37:18 PM

Funny I have modals on my mind this afternoon and boy does it drive me up the wall that mainstream React frameworks still aren't using the <dialog> element and without that you will fail WCAG because all the other schemes that are supposed to hide the rest of the page don't.

It isn't even that hard, like I've been able to update the parts of MUI and reactstrap that my applications use even to calculate coordinates for portalized flyovers correctly. I could send but I just don't want to do the 5x work to do all the other components I don't use and then face the politics of a community that probably doesn't care if disabled people can use their products or even if they can check the boxes and pass WCAG. <dialog> is easy to use with HTMX and just a touch awkward with React because React insists on being level-triggered in edge-triggered situations but once you have it coded up <DialogsThatReallyWork/> just work.

by PaulHoule

4/22/2026 at 8:25:03 AM

I tried to use <dialog> and found it to be a pain. I wanted to close it when clicking outside, but Safari doesn't support closedBy. Some Safari versions on iOS broke when trying to style my backdrop with tailwind. The tailwind CSS reset didn't include <dialog>. I get the allure of just using a position: fixed;

by YmiYugy

4/21/2026 at 7:05:22 PM

Dialog is easy to use with just plain JavaScript.

by grebc

4/21/2026 at 7:44:16 PM

It's just plain easy. It boggles my mind that nobody uses it.

But then again it boggles my mind that you can pass WCAG with those "is this a motorcycle?" things or that stupid anime girl you see on Linux pages or a GDPR popup and you can. People will say "what if you have to support WCAG and GDPR?" and I say "sometimes you have to make a choice", I mean a11y work is damned if you damned and damned if you don't, just damned all the time and personally the EU screws up my life a lot more than Iran ever did.

by PaulHoule

4/21/2026 at 8:42:05 PM

WCAG is lot lot more than just using <dialog> and unless you do a thorough review with a professional in this field, <dialog> won't solve anything. Do you know how many other WCAG guidelines your app or your site misses. No one knows that.

by YetAnotherNick

4/21/2026 at 9:46:51 PM

We do pretty good on Siteimprove and similar checkers although these are frequently wrong and in some cases I think think the specs are actually wrong or miss important things for political reasons. We have customers who send us bug reports and we fix them, we catch others preemptively ourselves.

It is a problem that the experiences of disabled people are erased by the current regime, I haven't once seen an organization actually ask a disabled person if they can use the site or how it can be better.

Also I think accessibility tools are trash. If I start NVDA on my dev machine I have to power cycle it to get control back. Microsoft Narrator sorta works but the more you use landmarks and other aria-markup the more it starts blurting out things like "LANDMARK NAVIGATION LANDMARK!" in the middle of reading something even thought Siteimprove thinks it is all peachy. Is it a fail? Or did the tool fail? My tester or myself can look at an application as a sighted user and test it in Firefox/Chrome/Safari and say "it works" but it is not clear at all what the "definition is done" for testing with screen readers.

I hear JAWS is better than the others but it costs about as much as a car. In the meantime though I know when we don't use <dialog> we fail and I've seen a lot of third party modals that don't use <dialog> that all fail.

by PaulHoule

4/21/2026 at 9:32:27 PM

HTMX is just a bad advice and non-starter for any modern web application. It becomes more complex faster than you think. Just dont.

by GGO

4/21/2026 at 9:33:36 PM

front end (react etc) feels completely wrong to me. after all this computer science advancement that feels like the spot i point and say yeah thats duct taped together.

by trueno

4/21/2026 at 6:12:01 PM

Okay... you're an HTMX fellow. We live in the age of AI so if you're going to make an example, don't show us the trivial things we know HTMX can do.

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.

by ebiester

4/21/2026 at 6:31:46 PM

I'd point to that being a particular bad example. For one thing, you are going to have to enforce that business logic on the back end or your data structures will get shredded.

If one thing drives me crazy about the current situation it is the techniques you found on the most advanced web sites in 1999 are effectively lost, like the techniques used to build the Egyptian pyramids. Redrawing the whole page can be amazingly fast over a fast network (LAN/localhost which is a real situation in the enterprise) if you aren't loading 50x more CSS than you need and not loading 300 trackers or having a real time auction with 10,000 bidders for ads -- that kind of app can feel more responsive than many desktop and mobile applications today.

I have no doubt whatsoever that you could make an issue tracker with HTMX which would embarrass JIRA.

What amazes me about React though is that I can literally walk around inside a React web page, see

https://aframe.io/

and when I look at things like Vue and Svelte I see a lot of things that "look like a good mental modal for everyday web applications" but with React I can "draw anything I want" Thing is that people mostly want to make form applications and the framework that would serve them best is something like react-hook-form with a simpler substrate than React underneath it.

Right now I am working on biosignals demos where I might have a radar that reads respiration and a heart rate monitor and a myoelectric sensor and it is really easy to snap together a few components in JSX and write a little bit of code that fetches data from the devices and uses a library of functions to process it for the components. It should be just as easy to drag and drop a few components from a visual palette and configure them on the fly but React is not good for that.

Back in 2006 I was working on Javascript systems such as decision support applications and knowledge graph editors that were that flexible and... the rest of the world just hasn't caught up.

by PaulHoule