Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

URL-Driven State in HTMX

lorenstew.art

Post reply on HN
Print view View original

161–170 of 188 posts

Re: URL-Driven State in HTMX

#161

Post by ebiester »

_1tem wrote: post #141
ebiester wrote: post #139

Earlier quoted context omitted.

Yes, a well-engineered SSR webapp could be indistinguishable from an SPA. However, it is much harder to build a well engineered SSR with the tools we have. I haven't seen someone solve errors with form submissions and the back button well at the framework level. Post-Redirect-Get was awful. Trying to solve back buttons and wizards. Trying to solve modals. Is a modal a separate page with the rest in the back? What doe…

> Yes, a well-engineered SSR webapp could be indistinguishable from an SPA. However, it is much harder to build a well engineered SSR with the tools we have. Clearly you've never used Laravel + Livewire. Modals, forms, wizards, sidebars, I have all of that in my app without writing any client-side JavaScript. And it works better than most SPAs. I actually get gushing praise for how "smooth" the app experience is.

My contention is that this may not be the traditional client side app, but you are still placing these on a single page. Just because you are replacing the HTML on the page doesn't mean it is a multi-page app. It's an interesting SPA/MPA hybrid but just because you are not writing javascript doesn't mean that the infrastructure isn't using javascript to handle the plumbing.

So, let's use this as an example. Let's say you bring out a side drawer to edit the details of one row on the table. The side drawer pops up. The user edits details and clicks submit. (To answer this question, the user scrolls to other parts of the table to look at other rows.) There is an error in the user's input based on business logic. The user corrects it, and the row is changed. The side drawer goes away.

How many times is the whole page loaded from scratch? In a traditional SPA, the page is loaded once. With a strict MPA, the page is loaded from scratch four times. With Laravel + Livewire, to my understanding, the page is loaded once and divs are replaced with HTML from the server.

Even if it is not a react app, it is still a collection of single page apps with server side intermediations using html.

Re: URL-Driven State in HTMX

#162

Post by ebiester »

TimTheTinker wrote: post #140
ebiester wrote: post #139

Earlier quoted context omitted.

Yes, a well-engineered SSR webapp could be indistinguishable from an SPA. However, it is much harder to build a well engineered SSR with the tools we have. I haven't seen someone solve errors with form submissions and the back button well at the framework level. Post-Redirect-Get was awful. Trying to solve back buttons and wizards. Trying to solve modals. Is a modal a separate page with the rest in the back? What doe…

> The key insight into the SPA is that you are writing a coherent client experience. This is the best way to put it I've yet seen. HN articles keep saying things like "now that navigation transitions are solved in CSS, there's no use case left for SPAs". Is everyone just writing apps for widespread content consumption or something? > CNN should not be an SPA. Yes, and we need canonical "that should be an SPA"-type ap…

I think the easy answer is "could you see this system being rewritten in QT or Visual Basic 6?"

If this would have been a desktop app in the 90s, it's within this scope.

Re: URL-Driven State in HTMX

#163

Post by geek_at »

johnisgood wrote: post #153
tonyedgecombe wrote: post #151

Earlier quoted context omitted.

Unless they have abandoned backwards compatibility then I don't think that is what I meant.

Major differences that I can think of between the two are (with regarding to warts and ease of use): PHP 8 uses exceptions with a unified Error hierarchy, there are type errors, division by zero, certain parse errors and so on. PHP 8 has strong support for static typing now, thank goodness. PHP 8 introduces union types (int|float|null). PHP 8.1 introduces intersection types (A&B). PHP 8.1 added the "never" return typ…

Wow very in depth comment. Maybe I'll spin up a dev container and play around with php

Re: URL-Driven State in HTMX

#164

Post by colgandev »

HTMX has given me so much joy. I love Django and was there near the beginning. For a while I thought I had to switch to something like FastAPI and Vue etc to make relevant web apps and sites, but with Django recently adding async, Django Ninja, and HTMX, I'd reach for Django now for almost anything besides a few specific use cases.

So many problems I've run into with newer tools feel like they were already solved years ago if you can SSR.

Not that the newer tools don't have their place and they have plenty of good ideas, but it's been fun to see Django stay relevant and for more of the included batteries to be useful again (forms, templates, etc).

Re: URL-Driven State in HTMX

#165

Post by colgandev »

podgorniy wrote: post #66

I think people are now ready for php. I bet it will be reinvented on top of nodejs.

It has been wild to realize I've now seen one full technology cycle of thin client to thick client to thin client again. Maybe PHP this time around will be able to be more robust with the lessons learned.

Re: URL-Driven State in HTMX

#166

Post by asa400 »

jiggawatts wrote: post #110
donatj wrote: post #97

Earlier quoted context omitted.

As a long time PHP developer, it never fails to amuse (amaze?) me the lengths people go to in order to get the things the browser will give you for free.

The most "special" code that I regularly come across is when a developer takes a JPG in blob storage -- already a public HTTPS URL -- then serves that in a "Web API" that converts it to base-64 encoded bytes inside JSON, sends it to client JavaScript, decodes it, and feeds it to an image in code. Invariably, it's done with full buffering of the blob bytes in memory on both server and client, no streaming. Bonus point…

This is truly beautiful. Art, even.

Re: URL-Driven State in HTMX

#167

Post by johnisgood »

geek_at wrote: post #163
johnisgood wrote: post #153

Earlier quoted context omitted.

Major differences that I can think of between the two are (with regarding to warts and ease of use): PHP 8 uses exceptions with a unified Error hierarchy, there are type errors, division by zero, certain parse errors and so on. PHP 8 has strong support for static typing now, thank goodness. PHP 8 introduces union types (int|float|null). PHP 8.1 introduces intersection types (A&B). PHP 8.1 added the "never" return typ…

Wow very in depth comment. Maybe I'll spin up a dev container and play around with php

I missed an important difference (because I did not consider it to be relevant to "warts"[1] and "ease of use"), which is that modern PHP has Just-in-Time (JIT) compilation now, not an interpreted runtime, which offers significant performance improvements!

[1] On second thought, poor performance could be considered a wart.

Re: URL-Driven State in HTMX

#168

Post by TimTheTinker »

naasking wrote: post #143
ebiester wrote: post #139

Earlier quoted context omitted.

Yes, a well-engineered SSR webapp could be indistinguishable from an SPA. However, it is much harder to build a well engineered SSR with the tools we have. I haven't seen someone solve errors with form submissions and the back button well at the framework level. Post-Redirect-Get was awful. Trying to solve back buttons and wizards. Trying to solve modals. Is a modal a separate page with the rest in the back? What doe…

The only real use case for an SPA is something that has to continue to work offline. There are legitimate cases like this, but most apps developed as SPAs aren't it. > No SSR framework figured out how to do this because they thought about pages rather than experiences. Laravel, Blazor and apps designed around HTMX are all like this. "SSR framework" has literally nothing to do with "pages rather than experiences". Pag…

> The only real use case

The original idea behind an SPA was to enable API-only backends (with static file service). I still think that's a very worthy use case.

Why not decouple the backend from the concerns of particular views? It makes for a more complex frontend, but it also allows multiple, highly differentiated frontend apps to be build on top of a single set of backend APIs. Esri's ArcGIS Online powers a lot of specialized frontend-only web apps. I used to be on their Business Analyst team (that's a web app) - and I have to say I really like the pattern of building apps this way.

Re: URL-Driven State in HTMX

#169

Post by NegativeLatency »

ashwinsundar wrote: post #53
NegativeLatency wrote: post #8

Earlier quoted context omitted.

I've seem a largish company everyone here knows of, try this and have it fail, because of various weird client things, and also eventually run out of space in the hash. It's a neat hack but I wouldn't rely on it.

They failed as a company?

Still around doing, eh fine. But they abandoned the url hash params with an id that references params on the backend (a mess!)
Post reply on HN