Sure, but what's your use case? Strict data table where everything is a string or number? Great. Full fledged application where your table rows are actually selectable items that modify app state and cause rerenders elsewhere? Surely a slight performance hit in the table is worth the smoothness of an application.
For example, I have a workflow execution tool. You have a Table serving as a left column, and when you select a workflow (by clicking its table row), it populates the right column with the graph of that workflow.
I often feel as if arguments against SPA are constructed against the worst examples of the thing, when the UIs it enables are smooth, performant, and best-of-all not requiring user installs.
You don't have to use a SPA to achieve that. With a couple of lines of JavaScript, you can insert snippets of html into a webpage that were rendered on the server. And remove them with one line.
Your entire use case is achievable with server-side partial rendering and a few lines of native js.
So your proposition is that instead of downloading a client bundle that knows all of these actions, my server:
* renders a Table for me
* my thin client injects that into the page
* my onClick handlers for the Table are going to do what? Make an API call to the server so it can render the focused Graph section of the page now? Or is it supposed to hook gracefully into some client state that is a part of the aforementioned thin client?
Either way it sounds like instead of having one async stage at application load (which can be optimized with multiple techniques), you are proposing that each user action has to wait for a server to receive the request, render HTML, return it to the client, and either refresh the page or inject the server-rendered HTML.
I fail to see why this is better than an SPA. Especially given that there's context menus and workflow actions everywhere.
Anything that actually changes the data requires a server roundtrip. The point is that it's faster and simpler to just have the server render the entire HTML and replace that rather than making an API call with client-side JS rendering.
>Anything that actually changes the data requires a server roundtrip
I mean, of course, but clearly I've outlined a situation where you can easily prefetch some objects to have an instant user experience. These are plentiful.
Additionally, you enable responsiveness in other ways server rendering can't accomplish with an SPA. You can display loading status of async resources, you can optimistically display changes so the user can begin editing another piece of data without waiting for latency-bound UI, etc..
Finally, "simpler" is a hard sell. Simpler for who? Someone who is writing a simple HTML data table page? Yes. For someone who is building a collaborative graph editor? Give me a break.
This is my point this whole comment thread - the anti-SPA crowd here sometimes hates JS and browsers so much they are willing to completely sacrifice user performance inside application use-cases because they find the idea of an SPA unappealing. It's pretty absurd, facile really, to claim "it's faster AND simpler".
Where's the prefetching? The table loads with the page. Loading it after with JS will only go slower.
> "server rendering can't accomplish with an SPA"
Again, you don't need a SPA to have some interactive DOM manipulation. Nobody is saying everything requires fresh HTML from the server, but something like jQuery Datatables will give you 99.99% of instant client features while working with server-rendered tables. htmx.js is another great library that solves most use-cases.
> "For someone who is building a collaborative graph editor?"
Obviously not, because that's one of the few times where a SPA is needed.
> "the anti-SPA crowd here sometimes hates JS and browsers so much"
What's with the extremes? Nobody is against SPAs or JS or browsers. In fact we want browsers to be used for what they do best, which is rendering URLs into pages very quickly. SPAs make a tradeoff in trying to emulate most of the browser performance and reliability in return for complex interactivity. The issue is that most sites don't need that interactivity, and what little they do need can easily be done with much less.
Yes, I said that in the context of this thread, specifically the GP post that said:
> "a large html table rendered on the server into the DOM directly was orders of magnitude faster "
Ignoring all context and calling this a "childish analysis" does nothing to further your arguments, and is yet another example of your comments going to the extremes.
You show a dogmatic support of SPAs without any consideration for the repeated statements that they are overused and not fit for the majority of the interactivity that people use them for. If you refuse to accept this than there's nothing more to discuss.
I don't know what I'm talking about, yet I build slick UIs for a living. Ok.
You are advocating for every action to take a server round trip to render, a client UI that consists of some hobbled-together mess of client JS, endpoint-rendered HTML, and worst-of-all extra server infra in order to facilitate it, when your client presents you with a perfect execution environment for a single application to transform data into semantic UIs.
I doubly enjoy that you didn't answer my earlier interpretation of your proposal, nor name any specifics of how you work, instead opting to swing back by once other people had sufficiently derailed the conversation.
> For example, I have a workflow execution tool. You have a Table serving as a left column, and when you select a workflow (by clicking its table row), it populates the right column with the graph of that workflow.
That is trivially implementable in pure HTML interactions.
If you were making a 3D game or something, sure... but that's just normal web navigation.
Basically, you are proposing what? That I have a server that renders this table, pre-populated with onClick handlers that magically know what function to call to tell my browser state that it should focus a specific workflow?
Or are you suggesting that I reload the entire application to use "pure HTML interactions"?
I really want to understand - how are you making this construct both not fragile to iterate on AND not require a page reload or server round-trip after the user clicks on a Table row.
You would have rows in one table, those rows would be annotated with two annotations:
hx-get="/workflow/<workflow id>"
where <workflow id> is the ID for the given workflow. This would issue a GET request to, er, get the details for the given row, in partial html format.
And also
hx-target="#other-table"
This would tell htmx to take the received content and put that into the other table on the screen, by id. Since this target is the same for all rows in the table, it could be moved to a parent element, where it would be inherited from.
Finally, you could also use
hx-push-url="true"
If you wanted to push the URL into the navigation bar, creating a history element for the navigation, and which would allow users to copy a URL to a particular spot in the two-level navigation, and enable back button support.
Thank you for the tutorial. It is quite a nice library, to be sure, and the freedom to work outside of the JS ecosystem, instead writing your servers however you please, seems ncie. However, I feel you are talking right past me to show me your library & dislike of JS. From my last message:
> how are you making this [...] not require a page reload or server round-trip after the user clicks on a Table row
The whole appeal of SPAs is they take perhaps 2s longer to start up than your normal webpage, and then you get lots of instant interactions. The example above is one of them. Your model requires server round-trips for every interaction.
I get it - you don't like JavaScript. I find your model quite nice and graceful for non-application purposes. It's certainly a brilliant way to render some types of data.
But for fully interactive applications where your user would want to have context menus showing applicable actions; good feedback on app / loading state; and avoid server latency on any type of event; I feel like SPAs are far superior.
I also feel like you have removed yourself from writing JS flavored HTML, but the solution of server-siding it introduces two problems. One is that you still need to hydrate and format that HTML somehow; I again think you can go a long way with templates, but if you're just using React on the back-end it seems ridiculous. Second, you have to take on all the rendering load instead of just passing thru some JSON-formatted DB results, which puts your server infra under far more pressure at less load to my eyes.
Final gripe: that interaction is not "pure HTML", you are using a JS library...
The primary advantage of SPAs is the increased interactivity of the UI. Instant navigation is nice, but that's an implementation detail: an SPA could just as easily lazily load that data, and must chew up memory on the client and then deal with synchronization complexity with the back end if it doesn't.
It's a trade off, of course. SPAs are a reversion to the classic client-server setup, and there are advantages and disadvantages to both that and the newer web model.
One is that you still need to hydrate and format that HTML somehow
htmx expects HTML back from the server, there isn't any hydration or client side templating (unless you want that)
Second, you have to take on all the rendering load instead of just passing thru some JSON-formatted DB results,
Formatting database data into a JSON string is not significantly less CPU intensive than formatting it into an HTML string, and both are a round-off error when compared with the expense of connecting to the data store.
Final gripe...
Yes, an irony of my life is that I had to learn a lot of javascript in order to avoid writing much javascript.
I think my biggest complaint about what you've written here is that you just shunt these "complexities" you wield against SPA to the back-end and then gloss over them.
I strongly disagree that "formatting database data into a JSON string is not significantly less CPU intensive than formatting it into an HTML string" - business logic is always the most expensive code to inject. This means you're either, again, not really making full-blown applications, or they're exceedingly simple. Postgres can craft nice JSON output straight from the horse's mouth. Can't say the same for HTML.
> Yes, an irony of my life is
The code looks great. Congrats on finding a development path that suits your tastes.
Nothing stops you from loading all of those graphs in the initial HTML payload if you want to, and then displaying them without a round trip to the server. These things are not exclusive, you don’t need to go all-in with a client-side framework to achieve basic interactivity (like tabs).
This is such a silly thought. I have to have a server which has to be capable of transforming data to valid HTML snippets which are aware of the context they'll be put into, a client which is capable of listening to clicks and then putting some data or snippets in some context it has to be aware of, and I have round-trips for everything even though I have a stateful client, and it's best if that stateful client is an orchestrator for remote systems which can somehow inject interactivity into my stateful client.
It's spaghetti architecture and I don't see what the gain is. Why do my servers need to know how to describe my layout!?
You are not listening. You don’t need round trips. The same way your SPA receives its initial data from the server, you can send it as HTML (hidden) and just use JS to switch between the views. And there is nothing special about “understanding layout” on the server, you can run the exact same rendering code in the server with node. I’m not going to bother mentioning streaming html / progressive rendering, SEO, caching, semantic content or accessibility since you obviously won’t care much for that.
We’ve been doing this on the web for over two decades now. Tell me about spaghetti architecture once you work on a real world project using React.
>You are not listening. You don't need round trips.
Ok, so you've already proposed to me that my server not only needs to know how to load all the data, it also has to have an HTML renderer baked in, AND in your haste to say my SPA doesn't have any advantages, you've already forced your server to execute a layout algorithm on N graphs of unknown complexity, on your own machine & dime instead of your client's, just in order to accomplish what my SPA got for free: instantly rendering the next content when the user clicked.
The fact that you can come up with a list of things orthogonally related to serving web content that aren't solved any more gracefully with server-side rendering than an SPA - SEO, semantic content, accessibility - it's just silly. Same with this idea that you're going to pre-render the HTML into an ingenious layout where the user makes a series of actions that uncover nested HTML and don't require round-trips. It's as if you're ignoring that a primary benefit of SPAs is you can hide data loading really easily with prefetching JSON blobs and writing JS to navigate the tree. It's literally the language for the task.
It's exactly why I've not been shy to say this: anti-JS anti-SPA users get so bent out of shape that SPAs build nice UIs that they throw the baby out with the bathwater.
For example, I have a workflow execution tool. You have a Table serving as a left column, and when you select a workflow (by clicking its table row), it populates the right column with the graph of that workflow.
I often feel as if arguments against SPA are constructed against the worst examples of the thing, when the UIs it enables are smooth, performant, and best-of-all not requiring user installs.