Tips for Building SSR/HDA Applications(htmx.org)
htmx.org
Tips for Building SSR/HDA Applications
https://htmx.org/essays/10-tips-for-ssr-hda-apps/
15 comments
>But the vast majority of SPAs are an order of magnitude more efficient to work on than the old paradigm of PHP/JSP/ASP/Whatever server pages
This is kind of a head scratcher. SPAs may be easier to work on than how things were done 20 years. But they're definitely not easier to work on than SSR in a modern stack.
This is kind of a head scratcher. SPAs may be easier to work on than how things were done 20 years. But they're definitely not easier to work on than SSR in a modern stack.
>But they're definitely not easier to work on than SSR in a modern stack.
It's about division of labor, and having clear interfaces between teams. If you are a one-person project, then by all means go that route. But in a team with specialized talent in backend and frontend development, both are much more efficient when that separation exists. Expecting frontend devs to write efficient SQL queries is about as insane as expecting a backend dev to know how to make complex CSS animations.
It's about division of labor, and having clear interfaces between teams. If you are a one-person project, then by all means go that route. But in a team with specialized talent in backend and frontend development, both are much more efficient when that separation exists. Expecting frontend devs to write efficient SQL queries is about as insane as expecting a backend dev to know how to make complex CSS animations.
Huh? Nothing about using SSR means designers have to write SQL. I think you have some inaccurate assumptions about what SSR has to look like, or how it can be layered. MVC was a thing for a long time, and still is in various forms.
>Huh? Nothing about using SSR means designers have to write SQL.
I said front end devs, not designers. And that is literally called out as a specific proposed benefit in the article.
I said front end devs, not designers. And that is literally called out as a specific proposed benefit in the article.
The article calls out access to features of SQL data stores — not writing SQL itself. In practice, that means developers need to learn how to use an ORM; most common operations are pretty well abstracted.
Sorry, but I'd rather do front end dev on static HTML and CSS any day than deal with the self-abuse treadmill of frontend JS.
And I don't know what to tell you, absolutely no one is advocating for JSP style SQL-inlined-in-HTML or something.
And I don't know what to tell you, absolutely no one is advocating for JSP style SQL-inlined-in-HTML or something.
>Expecting frontend devs to write efficient SQL queries
This just isn't a problem for most modern stacks. You're using an ORM and not writing SQL which isn't any harder than GraphQL or Rest endpoints.
And, for better or worse, there's not that much need to write efficient SQL because servers are so fast these days. The target you need to hit is something like "one of my filter conditions has an index" and things will usually be fine.
This just isn't a problem for most modern stacks. You're using an ORM and not writing SQL which isn't any harder than GraphQL or Rest endpoints.
And, for better or worse, there's not that much need to write efficient SQL because servers are so fast these days. The target you need to hit is something like "one of my filter conditions has an index" and things will usually be fine.
Why in the world would I want to split a team in two highly coupled halves that can't deliver any value by themselves? Division of labor? Seriously? Are we back to the 18th century?
> 2003 called and it wants its network architecture back
yep:
https://htmx.org/essays/hateoas/
https://htmx.org/essays/a-real-world-react-to-htmx-port/
yep:
https://htmx.org/essays/hateoas/
https://htmx.org/essays/a-real-world-react-to-htmx-port/
htmx is so wonderful. We have had amazing success utilizing it and returning to a hypermedia approach to web dev. The essays go into detail of why this is.
[deleted]
The pendulum swings back and forth until it settles on an equilibrium.
No doubt, some SPAs went way too far onto the client side. But some of this advice really feels like the pendulum swinging too far back to the server side.
But I suppose that articles that suggest striving for balance and provide a clear and actionable set of guidelines to achieve that balance aren't quite as easy to write.
No doubt, some SPAs went way too far onto the client side. But some of this advice really feels like the pendulum swinging too far back to the server side.
But I suppose that articles that suggest striving for balance and provide a clear and actionable set of guidelines to achieve that balance aren't quite as easy to write.
I really recommend reading the essays on https://htmx.org/essays/
They are well-written, opinionated, but not dogmatic.
And the book on https://hypermedia.systems/ is a true gem.
This article is surreal. It feels like I just woke up in the year 2003. Why are we actively promoting old architectures that were abandoned for very good reasons?
If your use case requires SSR for some reason, then sure. But the vast majority of SPAs are an order of magnitude more efficient to work on than the old paradigm of PHP/JSP/ASP/Whatever server pages (i.e. what things like htmx are reinventing, but this time in JavaScript!).