Hacker News Reader

Comment by samwillis | Hacker News Reader

Love htmx and this talk is a brilliant run down of where it works well.

But as always it’s about choosing the right tool for the job. Server rendered pages/fragments solve so many issues around security and time to develop a product, however it only gets you so far.

Ultimately I think the decision when choosing a stack comes down to how much state you need to managed in browser. The vast majority of sites needs very little client side state management, htmx and other tools such as Alpine.js are perfect for this. But eventually as you reach a more “app like” experience with multiple layers of state control on the front end you need to reach for a front end JS framework.

Now that doesn’t always mean going all in on a full SPA covering the whole of your product. It could just be a small fragment that requires that level of interaction.

Point is, don’t pick a tool because it’s “in vogue”, pick one because it lets you build the best possible product as efficiently as possible. For 80% of websites that could be htmx, and for the next 15% htmx probably works for 90% of their pages. It’s the 5% where htmx is not one of the right choices at all.

View on HN

> as you reach a more “app like” experience with multiple layers of state control on the front end you need to reach for a front end JS framework

I think that if you fully embrace HTMX's model, you can go far further than anticipated without a JS framework. Do you really need to be managing state on the client? Is it really faster to communicate via JSON, or protobuf, whatever, rather than atomic data and returning just small bits of replacement HTML -- inserted seamlessly that it's a better UI than many client-side components? Why have HTML elements react to changes in data or state, rather than just insert new HTML elements already updated with the new state?

I think you're describing a, let's do React in HTMX mindset, rather than let's go all in on the HTMX model. And I might be giving HTMX too much credit, but it has totally changed how I go about building web applications.

Oh, I completely agree with you. The vast VAST majority of sites don’t need that level of client side state management.

I’m currently working on a bio-informatics data modelling web app where htmx would not have been the right choice. But it’s in that 1-5% where that is the case. That’s kind of my point.

Outside of that project, I’m all in on the the HTMX model of server side rendered fragments.

Oh god please let’s not go back to JSF

How was it worse than the current state of affairs of complexity with React? Bowser, npm, typescript, obfuscation, compressors, build pipelines.. it’s a lot. Life at the front-end today is so discombobulated, creating a bunch of backend APIs which will generally only be used and consumed by a single browser front-end.

I’m genuinely curious, because I never used JSF except for a single school exercise

Frankly, with yarn, typescript, and a packaging / compressing tools of your choice, web frontend development is pretty pleasant and efficient these days. (To say nothing of using Elm, if you can afford it.) Typescript is particular is nice compared to, say, Python, and even to Java (though modern Java is quite neat.)

The only unpleasant part is dependency management, but you have the same, or worse, with Python or Ruby, and neither Java nor Go are completely hassle-free either.

Really curious, how is it worse with Ruby?

With bundler, Ruby dependency management is excellent. I don't think I've ever had a problem setting up an app where the Ruby dependencies are the issue. I certainly can't say the same for JavaScript apps.

Typescript nicer than Python? Bc of speed? Python has typing module + mypy to be warned about typing mistakes.

It may have improved significantly since I last used it (9 months ago?) but mypy was a world away from the ergonomics, quality of tooling and maturity of TypeScript.

I’ve used JSF when it was still beta. It was chosen by an external “architect” as the front end for a big site with millions of views (he was anticipating that JSF would be come popular, and a big project with it would be good on his resume).

Salesforce (classic) is JSF.

It’s full of bugs and quirks. But it’s kind of nice in certain situations.

The big problem here is performance load on both client and server. State is sent back and forth and it that kan be huge, and needs to be deserializes, altered, and serialized back again every action. It also doesn’t reflect any http verbs. Everything is POST

The big site was technically running on JSF, but in such a way that it wasn’t JSF any more

> Salesforce (classic) is JSF.

Here's a little bit of trivia... The Visualforce framework (that customers can write interactive pages in, and a small minority of the standard UI is build in) is based on JSF, but most of Salesforce classic standard UI is written in a home-grown system that generates HTML described in imperative Java. It's more akin to an HTML generating Tk.

Makes sense and they had a few big architectural changes of their front end. Lighting is unbelievably slow

Primefaces makes it a bit more tolerable, but JSF is an ancient, slow, buggy beast that's hard to integrate with anything. Managing state on the server for every little thing is not scale-able, even for a measly number of clients. You don't have to grow to be a Facebook to feel the effects of the bad design of JSF.

I think that if you’re building tools and you want to do anything nice like optimistic rendering it’s not possible in HTMX, so I always wonder what kind of user experience is actually delivered on an HTMX app

Like this?

https://htmx.org/extensions/preload/

Sort of. It’s more like when you create an object, you can display the object inline immediately with a JS layer, plus show some status attribute or however deep you like.

This explicitly only works with GETters and I can’t imagine how you can show async state with a tool like HTMX easily

What if combined with this?

https://htmx.org/examples/lazy-load/

With respect to showing a loader, it’s a solution. Not fully sure I understand the mechanism - is it based on the class or does all content of the div with hx-trigger get replaced? Or even worse is the image still there with opacity 0?

However, this doesn’t solve the optimistic rendering situation at all. In general the approach of HTML over the wire clearly seems barred from solving that, you need a client layer for that

IIUC I think it's possible, but maybe a bit clunky. Htmx let's you choose the swap target, and you can replace any part the page, not just the section that triggered the swap. You can also replace multiple targets.

https://htmx.org/attributes/hx-swap-oob/

Also, there's nothing stopping you from writing a bit of JS to handle something htmx can't do.

For example, the initial GET could return two partials, one hidden by default until a user action triggers a JS swap while htmx performs the request and eventually replaces the div again along with any other out of band div(s).

The slippery slope that scares me (as a React developer) about htmx (or Hotwire.dev, in particular is the one I was looking at), is that you start making the assumption that the client's internet is fast.

There was demo that showed it normally takes ~100ms to click a mouse, and if you attach to the on-mouse-down, then by the time the mouse has been released (100ms later), you can have already fetched an updated rendered component from the server.

And while that's very cool, my second reaction is "is it ever acceptable to round-trip to the server to re-render a component that could have been updated fully-client side?" What happens when my internet (or the server) is slow, and it takes more than 100ms to fetch that data? Suddenly that's a really bad user-experience. In the general case this is a subjective question. I personally would rather wait longer for the site to load, but have a more responsive site once it did.

There's not a perfect solution to this, because in a complex site there are times that both the server and the client need to update the UI state. But having the source of truth for the UI located in a server miles away from the user is not a general-purpose solution.

(I'm not advocating for the status quo, either. I just wanted to bring up one concern of mine.)

For a real world example of this, GitHub uses server-side rendered fragments. Working with low latency and fast internet in the office, the experience is excellent. Trying to do the same outside with mobile internet, and even with a 5G connection, the increased latency makes the application frustrating to use. Every click is delayed, even for simple actions like opening menus on comments, filtering files or expanding collapsed code sections.

I'm actually worried about developers in developing countries where mobile internet is the dominant way to access the Internet and GitHub is now the de facto way to participate in open source, that this is creating an invisible barrier to access.

Side note: in Thailand and the Philippines, at least, mobile internet is blazing fast and not more expensive.

That's not universally true in all areas for both countries though.

As someone living in one of those countries, I beg to differ. Cheap maybe, but mobile internet is neither fast nor stable.

It's mostly the metal roofs everywhere blocking the signal.

I'm guessing that's Philippines :-] It's still been good enough for me to get work done, video calls, etc. And mostly better than hotel/coffee shop WiFi.

In Vietnam it is also fast.

Github does? Maybe that's the reason why I often get the error message: "page took too long to render" after ten seconds of waiting.

example: https://github.com/pannous/hieros/wiki/%F0%93%83%80 this is admittedly a complicated markdown file, however it often fails on much simpler files.

that's a good reason to invest in self hosting! https://git.jeskin.net/hiero-wiki/file/%F0%93%83%80.md.html

oh, thanks for cloning! but [[links]] dont work and other (internal)[links] don't link to markdown.md.

gah, you're right. perhaps that could be fixed with a few clever grep/sed incantations. very interesting repo if you're the author, by the way.

I hate it when devs implement their own timeouts. That’s handled at the network level, and the socket knows if progress is being made. I was stuck using 2G data speeds for a couple of years and I loathed this behavior.

Sometimes the infrastructure causes this. For a long time (and now?) AWS Api Gateway has a hard cap of 30 seconds, so the sum of all hops along the way need to remain under that.

A timeout at that level should mean “no progress” for 30s, not that a request/response needs to finish in 30s. An naive timeout that a dev randomly implements might be the latter and would be the source of my past frustration.

I love HTMX and similar technologies but I think GitHub is a particularly telling example of what can go wrong with these techs. The frontend is so full of consistency bugs that it's appalling: https://youtu.be/860d8usGC0o?t=693

As someone who has been writing code for 30 years and has been developing "web apps" since the late 90s, it's really funny to me how things come full circle.

You just described the entire point of client-side rendering as it was originally pitched. Computation on the server is expensive and mobile networks were slow and limited in terms of bandwidth (with oppressive overage charges) just a few years ago. Client-side rendering was a way to offload the rendering work to the users rather than doing it upfront for all users. It means slower render times for the user, in terms of browser performance, but fewer network calls and less work to do server-side.

In other words, we used to call them "Single Page Web Applications" because avoiding page refreshes was the point. Avoid network calls so as to not consume bandwidth and not make unnecessary demands of the server's limited computational resources.

Now things might be changing again. Mobile networks are fast and reliable. Most people I know have unlimited data now. And while computation is still one of the more expensive resources, it's come down in the sense that we can now pay for what we actually use. Before we were stuck on expensive bare metal servers and we could scale by adding a new one but we were likely overpaying because one wasn't enough and two was way overkill except for peak traffic bursts. So we really scrambled to do as much as we could with what we had. Today it might be starting to make sense to make more trips back to the server depending on your use case.

To address your concern about latency or outages, every application needs to be built according to its own requirements. When you say "there's not a perfect solution to this", I would say "there is no one size fits all solution." We are talking about a client / server model. If either the server or client fails then you have failed functionality. Even if you can get yourself out of doing a fetch, you're still not persisting anything during an outage. The measures that you take to try and mitigate that failure depend entirely on the application requirements. Some applications strive to work entirely offline as a core feature and they design themselves accordingly. Others can accept that if the user does not have access to the server then the application just can't work. Most fall somewhere in between, where you have limited functionality during a connection interruption.

People always take a good idea to far.

There's nothing wrong with loading a page and then everything on that page loads data from the server and renders it.

Where the issues come in is that modern SPA claims loading a new page is unacceptable and that somehow doing so means you can't fetch data and render anymore.

It's just not true.

I think the term SPA is somewhat confusing. Why can't an SPA, or parts of it be rendered on the server as well.

> we used to call them "Single Page Web Applications" because avoiding page refreshes was the point

I wonder if the problem was really that the whole page was reloaded into the browser which caused a big "flash" because all of the page was-re-rendered. The problem maybe was not reloading the page from the server but re-rendering all of it. Whereas if you can load just parts of the page from the server the situation changes. It's ok if it takes some time for parts of the page to change because nothing gets "broken" while they are refreshing. Whereas if you reload the whole page everything is broken until all of it has been updated.

We had this middle ground of returning html fragments and updating subsections of the page. For posting a comment, for example.

There were plenty of sites doing that in the mid 2000s.

The problem was there was no concept of reusable components. IMO htmx is not the headline here but django-components (https://pypi.org/project/django-components/) is. Managing html, css and JS in component-reusable chunks on the server used to be extremely awkward, especially when you begin to need lifecycle events (HTML appeared on the page, lets attach all the necessary event listeners, but only to the right element - even in a list of 5 elements; internal HTML changed, lets see which things need more events etc).

I would try this approach out in a typechecked language, if I'm certain a native mobile app isn't going to be needed.

I think your explanation makes it very clear.

The difficulty with web-development is there are 3 different languages (HTML, CSS, JS) which all need to make some assumptions about what is coded in the other languages. The JavaScript refers to a DOM-element by id, it assumes some CSS which the JS can manipulate in a specific way.

The ideal goal much of the time has been: "Keep content separate from presentation, keep behavior separate from the content etc.". While this has been achieved in a superficial level by keeping CSS in a .css -file, content in a .html-file and behaviors in a .js -file, they are not really independent of each other at all. And how they depend on each other is not declared anywhere.

That means that to understand how a web-page works you must find, open and read 3 files.

Therefore rather than having 3 different types of files a better solution might be to have 3 files all of which contain HTML, CSS, and JS. In other words 3 smaller .htm files, each embedding also the CSS and JS needed.

We have a set up like this at my job. The servers are based in the Pacific Northwest. We have users in Europe and India.

You can guess how awful the user experience is.

Even worse for Chinese users who have to browse many US sites with a VPN (e.g. me)

> you start making the assumption that the client's internet is fast.

The most common trajectory for react and other SPA framework apps is to also make this assumption, waving away the weight of libraries and front-end business logic with talk of how build tools are stripping out unused code so it must be light, while frequently skipping affordances for outright network failure that the browser handles transparently, oh and hey don't forget to load it all up with the analytics calls.

But maybe more crucially: what's the real difference between the overhead of generating / delivering markup vs JSON? They're both essentially data structure -> string serialization processes. JSON is situationally more compact but by a rough factor that places most components on the same order of magnitude.

And rendered markup is tautologically about the data necessary to render. Meanwhile JSON payloads may or may not have been audited for size. Or if they have, frequently by people who can't conceive of any other solution than graphql front-end libraries.

Whether you push html or json or freakin' xml over the wire is a red herring.

Heck, "nativeness" might be a red herring given frequent shortcomings in native apps themselves -- so many of them can't operate offline in spite of the fact that should be their strength because native devs ALSO assume client's internet is fast/on.

It may be common when starting out, but we do have paths to optimize out of it.

We can do code splitting, eager fetching js when page is idle, optimistic rendering when page is taking time etc. Unlike what a lot of people like to believe not every spa runs 20 megs of js on page load.

Also the initial load time being a few seconds and then the app being snappy and interactive is an acceptable compromise for a lot of apps (not everything is an ecommerce site).

When most fragments need to be server rendered it manifests as a general slowness throughout the interaction lifecycle that you can't do much about without adopting different paradigm. The hey-style service-worker based caching hits clear boundaries when the ui is not mostly read only and output of one step very closely depends on the previous interactions.

I joined a place working on larger rails+unpoly+stimulus app which started off as server rendered fragments with some js sprinkled in, but after two years had devolved into a spaghetti where to figure out any bug I'd typically need to hunt down what template was originally rendered, whether or not it was updated via unpoly, whether or not what unpoly swapped in used the same template as the original (often it was not), whether or not some js interacted with it before it was swapped, after it was swapped etc. .... all in all I felt like if you push this to use cases where lot of interactivity is needed on the client, it is better to opt for a framework that provides more structure and encapsulation on the client side.

I am sure good disciplined engineers will be able to build maintainable applications with these combinations, but in my experience incrementally optimizing a messy spa app is generally more straightforward than a server-rendered-client-enhanced mishmash. ymmv.

> Unlike what a lot of people like to believe not every spa runs 20 megs of js on page load

This is not a new take, it's exactly what every die-hard SPA dev says. While 20MB is an exaggeration, the average web page size has ballooned in the past decade from ~500KB in 2010 to around 4MB today. And the vast majority of those pages is just text, there is usually nothing really interactive in them that would require a client-side framework.

Others will say 2MB, 4MB is not that bad, but that just shows how far out of touch with the reality of mobile internet they are. Start measuring the actual download speeds your users are getting and you'll be terribly disappointed even in major urban centers.

I think you're talking past each other: the problem isn't assuming the client's internet is fast, the problem is assuming the client's internet is stable.

If you replace most interactions that could be resolved client-side with a network transaction, you're betting on the client's internet being not just reasonably fast but also very stable. When I'm on the go, my internet is more likely to be fast than stable.

> The problem is assuming the client's internet is stable.

Yep. This is the major drawback of backend-dependent interactions. This is what scares me away from amazing technologies such as ASP.NET Core Blazor Server where I can code my frontend in C# instead of JavaScript.

If only Blazor Wasm wasn't so heavy. 4mb of runtime DLLs is a bit off-putting to any use but intranet LOB applications.

Recent versions trimmed it down to about 1mb.

Your comment dovetails with my primary point: how an app serializes or renders data is entirely trivial compared to planning for network availability issues when it comes to app function and user experience.

GP asks: "is it ever acceptable to round-trip to the server to re-render a component that could have been updated fully-client side?" This is a question that's oriented around what is generated on the server and pushed over the wire rather than the fact that there is a network call at all.

If the network is not stable, a typical 1st-load-heavy SPA-framework will make... a tenuous network call returning JSON with iffy chances of success instead of a tenuous network call returning an HTML fragment with iffy chances of success.

On a transatlantic flight I recently had the displeasure of browsing over a satellite connection. A lot of sites simply never loaded, even though the connection speed was reasonable. The multi-second latency made these sites that loaded tens to hundreds of resources completely unable to render a single character to screen.

It’s almost as if developers are treating latency as having a kind of Moore’s law as with memory or cpu.

> I personally would rather wait longer for the site to load, but have a more responsive site once it did.

If react sites delivered on that promise, that would be compelling. However, while my previous laptop was no slouch, I could very often tell when a site was an SPA just in virtue of how sluggish it ran. Maybe it's possible to build performant websites targeting such slower (but not slow!) machines, but it seemed that sluggish was quite often the norm in practice.

If the internet is slow it will be horrible for the user on first load to download a full blownup JS bundle. It will also not removr the fact that any resource change will require a roundtrip to the backend and back forth

> There was demo that showed it normally takes ~100ms to click a mouse, and if you attach to the on-mouse-down, then by the time the mouse has been released (100ms later), you can have already fetched an updated rendered component from the server.

I think what you're describing is a form of preloading content but it's not limited to React.

For example:

The baseline is: You click a link, a 100ms round trip happens and you show the result when the data arrives.

In htmx, Hotwire or React you could execute the baseline as is and everyone notices the 100ms round trip latency.

In React you could fetch the content on either mouse-down or mouse-over so that by the time the user releases the mouse it insta-loads.

But what's stopping you from implementing the same workflow with htmx or Hotwire? htmx or Hotwire could implement a "prefetch" feature too. In fact htmx already has it with https://htmx.org/extensions/preload/. I haven't used it personally but it describes your scenario. The API looks friendly too, it's one of those things where it feels like zero effort to use it.

Hotwire looks like it's still fleshing out the APIs for that, it has https://turbo.hotwired.dev/handbook/drive#preload-links-into... for pre-loading entire pages. There's also https://turbo.hotwired.dev/reference/frames#eager-loaded-fra... and https://turbo.hotwired.dev/reference/frames#lazy-loaded-fram... which aren't quite the same thing but given there's functionality to load things on specific events it'll probably only be a matter of time before there's something for preloading tiny snippets of content in a general way.

If the click causes a state change, it would be complicated to pre-render (but not apply) it before click.

I actually have a module that I built ti loads pages using such an approach (prefetch). In my take, I refined Pre-fetching to be triggered a few different ways. You can fetch on hover, proximity (ie: pointer is x distance from href), intersection or by programmatic preload (ie: informing the module to load certain pages). Similar to Turbo, every page is fetched over the wire and cached so a request in only ever fire once. It also supports targeted fragment replacements and a whole lot of other bells and whistles. The results are pretty incredible. I use it together with Stimulus and it's been an absolute joy for SaaS running projects.

Sounds really good, do you have that code published somewhere? Any plans to get it merged into the official libs?

I do indeed. The project is called SPX (Single Page XHR) which is a play on the SPA (Single Page Application) naming convention. The latest build is available on the feature branch: https://github.com/panoply/spx/tree/feature - You can also consume it via NPM: pnpm add spx (or whichever package manager you choose) - If you are working with Stimulus, then SPX can be used instead of Turbo and is actually where you'd get the best results, as Stimulus does a wonderful job of controlling DOM state logic whereas SPX does a great job of dealing with navigation.

I developed it to scratch an itch I was having with alternatives (like Turbo) that despite being great are leveraging a class based design pattern (which I don't really like) and others which are similar were either doing too much or too little. Turbo (for example) fell short in the areas pertaining to prefetch capabilities and this is the one thing I really felt needed to be explored. The cool thing with SPX which I was able to achieve was the prefetching aspect and I was surprised no-one had ever really tried it or if they did the architecture around it seemed to be lacking or just conflicting to some degree.

A visitors intent is typically predictable (to an extent) and as such executing fetches over the wire and from here storing the response DOM string in a boring old object with UUID references is rather powerful. SPX does this really efficiently and fragment swaps are a really fast operation. Proximity prefetches are super cool but also equally as powerful are the intersection prefetches that can be used. If you are leveraging hover prefetches you can control the threshold (ie: prefetch triggers only after x time) and in situations where a prefetch is in transit the module is smart enough to reason with the queue and prioritise the most important request, abort any others allowing a visit to proceed un-interruped or blocking.

In addition to prefetching, the module provides various other helpful methods, event listeners and general utilities for interfacing with store. All functionality can be controlled via attribute annotation with extendability for doing things like hydrating a page with newer version that requires server side logic and from here executing targeted replacements of certain nodes that need changing.

Documentation is very much unfinished (I am still working on that aspect) the link in readme will send you to WIP docs but if you feel adventurous, hopefully it will be enough. The project is well typed, rather small (8kb gzip) and it is easy enough to navigate around in terms of exploring the source and how everything works.

Apologise for this novel. I suppose I get a little excited talking about the project.

This looks extremely similar to Unpoly to me.

Never heard of Unpoly, but seems really cool. I will need to have at look at it more closely but from the brief look I'd say SPX is vastly different.

In SPX every single page visit response (the HTML string) is maintained in local state. Revisits to an already visited page will not fire another request, instead the cache copy is used, similar to Turbo but with more fine grained control. In situations where one needs to update, a mild form of hydration can be achieved. So by default, there is only ever a single request made and carried out (typically) by leveraging the pre-fetch capabilities.

If I get some time in the next couple of weeks I'll finish up on the docs and examples. I'm curious to see how it compares to similar projects in the nexus. The hype I've noticed with HTMLX is pretty interesting to me considering the approach has been around for years.

Interestingly enough and AFAIK the founder of github Chris Wanstrath was the first person to introduce the ingenious technique to the web with his project "pjax" - to see the evolution come back around is wild.

>In SPX every single page visit response (the HTML string) is maintained in local state. Revisits to an already visited page will not fire another request,

Unpoly does this.

Would this not be a concern for React (and other SPAs) as well? I'm no UI expert, but from what I've seen of React/Vue UIs in previous companies, you still have to hit the server to get the data, though not the UI components. The difference in size between just the data in, say, JSON, and the entire HTML component would be very minimal considering both would be compressed by the server before sending.

There are frameworks that let you apply changes locally and (optimistically) instantly update the ui and asynchronously update server state. That is a win.

On the other hand, I have seen implementations of spa “pages” that move from a single fetch of html to multiple round trips of dependent API calls, ballooning latency.

I wouldn't assume a fragment is any bigger than the raw data when it's compressed.

  { "things": [
    { "id": 183,
      "name": "The Thing",
      "some date": "2016-01-01",
    },
    { "id": 184,
      "name": "The Other Thing",
      "some date": "2021-04-19",
    },
  ]}

  <tbody>
    <tr><td>183</td><td>The thing</td><td>2016-01-01</td></tr>
    <tr><td>184</td><td>The other thing</td><td>2021-04-19</td></tr>
  </tbody>

They seem extremely similar to me.

The issue with this model is that many state updates are not scoped to a single fragment. When you go to a another page, you’ll likely want to update the amount of results on one or more detached components. That’s way more natural to by getting the length of an array of data structures than on a html fragment.

Possibly, yes, although many SPA sites seem to hit for updates every (visual) page change anyway, to get the latest results. It's rare that a UI will hold all the records to count locally, unless it's a small and slow-changing data set, so it's asking for a count whether or not it's getting it wrapped in HTML or JSON.

> is it ever acceptable to round-trip to the server to re-render a component that could have been updated fully-client side ?

htmx doesn't aim to replace _all_ interactions with a roundtrip; in fact the author is developing hyperscript (https://hyperscript.org/) for all the little things happening purely client side.

But in any case even an SPA does round trips to get data stored on the server. The question becomes: is it better to make a backend spout json and then translate it, or make the backend spout HTML directly usable ?

> Do you really need to be managing state on the client? Sometimes an "app" needs to work offline.

> Why have HTML elements react to changes in data or state, rather than just insert new HTML elements already updated with the new state?

But what's the big difference? Something somewhere must react to change. Either modify the DOM by client-side code, or modify/replace it by loading content-fragments from the server.

I would (perhaps naively) think that doing more on the client is faster than both re-rendering on the server and reloading from the server. Maybe it's just that React is too big and complicated and therefore slow.

I think the point of a SPA is not how to refresh the screen when you have to do the round-trip to the server. The point is that you can do more things without making the round-trip in the first place.

Somewhere along the line the only accepted voice in the industry was everything has to be Javascript. I still have no idea why HTML5 hasn't evolved to include features purposed by HTMX.

> It’s the 5% where htmx is not one of the right choices at all.

I think even 5% is an over-statement. In my Top 100 site visit per month, the only three site that were SPA are Gmail, Feedly and Youtube. And I dont see how any of these three couldn't be done in HTMX. The Web Apps, if we call it that, that actually requires heavy JS usage are Google Work, Sheets, Google Map and Google Earth, and possibly some other productivity tools like Figma.

What security issues does server rendering solve? I resent that every website needs to be an SPA, but from a security perspective I’ve concluded that the clearer line in the sand that SPA application architectures creates is better than the security challenges that can result from server side rendering.

Navigating the risks around the NPM supply chain is another story, but I suspect it will be solved by large / popular frameworks gradually pruning their own dependency trees resulting from downstream pressure in the form of pull requests.

I think anywhere you introduce more complexity, more ways for things to interact, it's inherently less secure without the additional work checking for both the App + the API being secure on their own.

There's no such thing as a secure "app". Only the API needs to be secure. That's more straightforward when your API looks like REST/RPC calls rather than "renders html templates to a string".

> That's more straightforward when your API looks like REST/RPC calls rather than "renders html templates to a string".

How so? You're now dealing with two applications (or two parts of an application) that need to understand and access authentication as defined by "the app"

If the same codebase handles auth across the board it's much simpler and more reliable.

From a security perspective, the client is 100% irrelevant. You might prefer to offer a good UX in the face of authorization failure, but that doesn't affect the security of your app one way or another.

Good APIs look like simple functions; they take certain very structured inputs (path, query params, headers, body) and produce a simple structured output (usually a json blob). They're usually well defined, limited in scope, often idempotent, and easy to write automated tests for.

HTML endpoints are more complex because they generally combine many different functions at once, rely on server side state like sessions, and generate large quantities of unstructured input. They tend to be hard to test exhaustively and it can be hard to reason about all the possible edge cases.

The operative word being good, which most APIs unfortunately aren't. You could make the exact same argument about APIs that you made about HTML endpoints, and vice versa. The problem, imo, is that writing a fronted is a lot harder for many people than writing a backend and they tend to spend more time on the front-end.

Security is hard, especially when most developers are ignorant or negligent about basic best practices. If I had a nickel for every website I've found that only has client-side validation I'd be rich.

> The problem, imo, is that writing a fronted is a lot harder for many people than writing a backend and they tend to spend more time on the front-end.

The question then is whether the API is more part of the frontend or the backend.

If your backends are relatively easy and small, I think you should try to keep your APIs in that space and e.g. return JSON from a simple REST API with endpoint-level security.

On the other hand, if an API threatens to bloat and complicate your backend, use an API framework like Postgraphile or Hasura that gives you the tools to build powerful and secure APIs by writing some simple code or even no code at all.

Maybe it helps if you think of it this way:

An application can be very imperfectly thought of as having two bodies of logic, frontend logic and backend logic. In an SPA, if you secure the backend logic you are safe no matter what mistakes are made in the frontend. When rendering server-side HTML, the frontend logic and backend logic both run in a privileged security context. The attack surface area is larger.

> In an SPA, if you secure the backend logic you are safe no matter what mistakes are made in the frontend.

If. The problem I've observed is that people treat the backend as a dumb pipe for data and focus entirely on the frontend.

> When rendering server-side HTML, the frontend logic and backend logic both run in a privileged security context.

This isn't necessarily a bad thing. Business logic happening in a protected and opaque context means it isn't exposed and easy to reverse engineer or manipulate. An extremely common vulnerability on SPAs is "get a list of all the $STUFF user is allowed to see from endpoint A, then get all the $STUFF from endpoint B and filter out all the results they shouldn't see" because everything is still visible to the client; that exact same (suboptimal) logic is inherently more secure on the server. Another common one being "are we logged in or should we redirect?" Conversely, rendering content on the server makes it a lot easier to prevent certain vulnerabilities like CSRF.

That's not to say that I think SPAs are bad and AJAX is good, I just find the argument that SPAs are more secure if you secure the backend dubious. A SPA with an insecure backend can be just as insecure as a backend rendering HTML because the weak-point is the backend itself.

Edit: You could perhaps argue that SPAs are indirectly better from a security perspectiv because text serialization is safer than binary serialization. Though any serialization is still a potential weakness.

It's more straight forward when you have multiple kinds of frontends (iOS, Android, Web app), but if it's just a Web App it's less complex to just return HTML.

The default today to make an API is because we assume it'll have multiple frontends or because we want to make it easier to change frontends. That does not make it more secure; it's just a trade off we, as an industry, have made to deal with the reality of delivering apps/services to users.

> Only the API needs to be secure.

If users type passwords, sensitive data, anything into the frontend then any javascript, plugins etc pulled in by that page is an attack vector.

Unless you do something extremely silly with the login page, like sending it as a GET parameter, or storing it locally, or not having a CSRF token, or not using HTTPS, I don't see what special measures are required!

You can import malicious client side plugins irrespective of if it’s an SPA or server rendered. I’d much rather a silly plug-in be limited to client side JavaScript (which is sandboxed) over server side logic, which is not.

Sensitive data is not restricted to logins. If you are pulling in third party JS like for analytics, tracking, social, whatever then that is an attack vector. Marketing and business teams aren't responsible for security but they have the muscle to pull in dangerous code to the frontend that can be swapped out. It is naive to think that the API is the only thing to focus on.

The likelihood of a vulnerability in serverside logic is far higher and more impactful than a large marketing player like google analytics stealing PII.

If POST content type is application/json and is enforced, csrf is not possible. You cannot csrf put and delete unless you modify cors policies, all of which are server side vulnerabilities and not related to you using SPA vs server side rendering.

>" think anywhere you introduce more complexity"

When your website is the actual complex application SPA makes very much sense and is actually less complex. And no you do not have to download all of it into a browser. Load parts replacing some inner html with the other and scripts on on need basis. Works like a charm. I am using couple of JS libs but no framework and there is no need to "build".

As for security - JS app talks to my own C++ backend using some JSON based RPC so I just have to validate the API only which is way less work as well.

https://intercoolerjs.org/2016/02/17/api-churn-vs-security.h...

Here's one I've experienced. Suppose you have a table of customers, and you want to show an extra column of data on that page showing total orders, if and only if the viewer of that table has the manager role.

With an SPA, you'll be building an API (perhaps a 'REST' one, or GraphQL) to expose all the data required, such as customer name, email, etc, as well as the extra 'total orders' field iff they have the manager role. Now you need to make sure that either (a) that endpoint properly excludes that 'total orders' field if they lack the permission, or (b) you have a separate endpoint for fetching those kind of stats and lock that behind the role, or (c) (I hope not) you just fetch all orders then count them up! Now, having properly secured your API so that all and only the right users can get that data, you have extra logic in your front end such as 'if has role manager then show this column too'.

With a server side rendered page, you don't have to do the API security bit. You can just fetch all the data you like (often via a single SQL query), and then replicate the same extra logic of 'if has role manager then show this column too'. You've skipped the whole "make sure the API is secure" step.

Now suppose you want to add a dashboard for every admin user, not just managers, showing total orders system wide. Did you include that in your API already? Now you're likely going to need a new endpoint that allows any such user to fetch total system orders, while managers are still the only ones who can fetch per customer order totals. Having found a place to add that to your API, you can render it. With the server side page, there's no extra work to keep this secure. The dashboard is already restricted to the users who can see it, so just add the extra query to fetch total orders and display it.

In short, there's a whole layer that an SPA needs to secure for which there is no analogue with a server side rendered site. In an SPA you secure the API and then have the logic for what to show to whom. For the server side rendered site, you just have the logic for what to show to whom and that gives you the security for free.

As a slight counterpoint to that scenario, the front-end can often just get away with just checking whether the data exists in the response, rather than checking roles. This isn't quite as simple as the SSR alternative, but it at least removes most of the hassle with making sure the permissions match on server and client.

However, this doesn't help much when the restricted data is on a separate endpoint, since the app needs to decide whether to make the request in the first place.

manager role column

Tbh, I’d prefer a runtime which would be itself aware of such metadata, knew the role out of a request/session context and could build a ui table based on all-columns-ever template, from a query automatically built for this specific case, because querying and throwing away totals may be expensive. This manual “do here, do there” is a sign of a poor platform (not that we have a better one) and code-driven rather than data-driven access control in it. Painting walls and installing doors every time you want a meeting should not be a part of a business logic, regardless of which-end and its implications.

Yes. It's a poor design. The UI shouldn't care about permission or visibility rules. Instead It should only take data and render tables based on their data+metadata. All the permission logic should be done in the API level based on the caller ID/context.

Yep, I think there's wisdom in what you say here for good design. My point is (using a very simple example) that there are ways in which server side rendering offers some immediate security benefits that don't automatically come for an API+front end design.

I'm not sure about its performance, as I haven't done a great deal of testing, but another tool to achieve some of what you suggest (assuming I've understood you) is using RLS. E.g., using the obvious query, and relying on RLS rules to return only permitted data. You can similarly send the appropriate role with the query [1].

I also note with interest that Postgres 15 includes some improvements that might make this kind of approach even more viable:

"PostgreSQL 15 lets users create views that query data using the permissions of the caller, not the view creator. This option, called security_invoker, adds an additional layer of protection to ensure that view callers have the correct permissions for working with the underlying data."

[1] https://news.ycombinator.com/item?id=30706295

Yes yes yes. You're not going to get much appreciation of this from newer devs. They've only known one thing. I shudder at all the human-hours spent on duplicative tasks related to the artificial frontend/backend separation.

What do the tests look like for this? How do you check that you're not exposing the sensitive data?

If you have non-html native mobile applications, you’ll need to have that complexity regardless of the techniques used to construct web page.

Yep, that's absolutely right. From my own experience (which is really quite small for that kind of thing), I tend to think that the API you want and would build for a mobile app is not going to be the same as the one you would build for your SPA site. But yes, when you build that API, you'll need that complexity.

I've been doing some hobby experimenting with doing this in a more generic way using Postgres RLS and putting a lot of that permissions checks into the database. That way, if I used PostgREST or my own solution for a mobile app API, the security rules should apply just the same to the API as they do to the website.

Can't the backend decide which fields to send back in a JSON, the same way it would decide which HTML columns it would've rendered?

The front-end can pass a user role with every request and render whatever the backend sends it into a table.

I do case (a) like this with SPA. Call to /orders (or any endpoint) will check roles/permissions and runs the proper query. A normal user will get [{name, email}], but a manager will get [{name, email, num_orders}]. A normal user call will not have the COUNT(*) from orders part anyway in SQL query (which is expensive). Only a manager's call will have that part. Most likely number of managers will be less than users, so the users get faster results. The results are returned to front end and if the {num_orders} column exists, it is rendered. Front end doesnt have to bother with any access control logic.

For the server-side rendered page, what seems to me is you are running same query for normal users and managers, which is fine too, but removing that num_orders column.

Ultimately in both cases, the access control logic happens on the server, and frontend don't have complicated access control logic anyway. My point is, with SPA also we can get the same server-side benefits, atleast in this case. Or am I missing something?

I am in 100% agreement with you: pick the right tool for the job.

My hope is that, with htmx, HTML/hypermedia is that right tool for more jobs.

I’ve been exploring various alternatives and I’m certainly of the same mind as you.

It’s always trade offs and that’s fine.

What I find interesting/ frustrating is every framework or option likes to sell you on some numbers that are very nice but so specific they’re not the big picture. And/or talk about how they are different / better than another framework that I might not even be familiar with.

Technical pages now have their own confusing sort of developer marketing.

I have 2 problems with htmx (IMHO):

1. SoC: the server API needs to return only the data and meta data requested, and it should not be concerned with the display-layer (html), because many different clients i.e. mobile app, browser, Electron etc. might want to consume this API.

2. Logistics & scaling: Imagine a large application with 100s of html/htmx components and views, now you alter your database, you introduce new business rules etc... If you used React or Alpinejs etc. you could just go to the relevant stores or app code and make the change as opposed to sifting and refactoring tons of html.

Personally I'd rather just use Alpinejs from the start, knowing its lightweight, fast and easy to implement, and not end up painting myself into a corner over the application lifecycle.

1. https://htmx.org/essays/locality-of-behaviour/

2. many large applications use htmx (or related approaches like hotwire, unpoly, etc.) and scale fine. hypermedia is better at handling databaase/logic/API changes than fixed-format data APIs because your API is encoded within hypermedia responses: https://htmx.org/essays/hateoas/

LoB yeah, on small scale perhaps, I guarantee you will end up with a cluttered mess on large applications, unless you spend a ton of extra time/work to design for scale, maintenance and dev onboarding.

I do not agree with HATEOAS, so now you have an API which job is to produce html (SoC problem), and what if a Flutter app also needs to consume this API, do you build another HATEOS API just for Flutter?

Every few years its the same, devs adopting and defending the new shiny thing, though I have to admit, I love that this time its a way more simplified, sane alternative.

I have experience with multiple large applications that use htmx. They scale fine. They just aren't what people are used to right now.

Give it time and mull it over. It may grow on you.

I also like htmx and this kind of comparison is fruitless. The executive summary talks about LOC, build time, # of JS dependencies, etc. Nobody started using React because of these things, so it misses the point. It doesn't compare htmx to react on the matters that really matter to people who chose react...

Reply on news.ycombinator.com