Modern Front end Complexity: essential or accidental?
by gsky on 4/19/2026, 1:10:51 PM
https://binaryigor.com/modern-frontend-complexity.html
Comments
by: Jcampuzano2
I never really understood this argument:<p>> Currently, we live in the JavaScript-heavy reality, where browser runtime looks completely different from source code files we work on.<p>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.<p>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.<p>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.
4/21/2026, 6:20:19 PM
by: edwinjm
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.
4/21/2026, 6:30:35 PM
by: settsu
I dunno, the "complexity" seems mostly from:<p>10 Brute force medium into doing what it was not originally designed to do<p>20 Insist on native support for what was once a hack<p>30 goto 10<p>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.<p>(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.)
4/21/2026, 6:26:54 PM
by: brap
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.
4/21/2026, 7:14:25 PM
by: Pavilion2095
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.
4/21/2026, 7:07:26 PM
by: schrotie
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.
4/21/2026, 6:12:26 PM
by: telman17
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.<p>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.<p>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.
4/21/2026, 5:59:47 PM
by: jerf
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.<p>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 <i>too hard</i> 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.<p>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.<p>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.<p>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 <i>that</i> 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 <i>de facto</i> 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 <i>that</i> 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.<p>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 <i>de facto</i> VM for the world is not going to be simple.
4/21/2026, 6:30:08 PM
by: ebiester
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.<p>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.
4/21/2026, 6:12:01 PM
by: YetAnotherNick
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.
4/21/2026, 6:14:41 PM