> 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.
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.
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.)
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.
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.
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.
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.
> 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.
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.
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.
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
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.
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.
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.
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.
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.
> 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.
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.)
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.
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.
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.
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.
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
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.
> 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.
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.
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.
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.
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.
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.
Dialog is easy to use with just plain JavaScript.