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

Your single-page app is now a polyfill

itnext.io

Post reply on HN
Print view View original

131–140 of 164 posts

Re: Your single-page app is now a polyfill

#131

Post by nexuist »

asddubs wrote: post #119
nexuist wrote: post #82

Earlier quoted context omitted.

I believe this entire technique is known as SSR - Server-Side Rendering. It's built in to Vue and React and you can find examples on their respective sites.

that's confusing, I've only ever heard SSR/server side rendering to mean actually rendering html and serving that, as opposed to SPAs

Well, the idea is that you render the first pass of the SPA and serve that HTML to the client. Rather than just injecting the data into the SPA source code, you inject the data and render the page, and then serve that page. Then whatever changes the user makes to the page after that initial load gets handled by the SPA. This way the user avoids having to wait for the SPA and all its dependencies to load before the page can even appear, and the developer doesn't have to differentiate between what happens on the client side and server side (remember using PHP to inject variables into JS source code?) because they can just bake it into their SPA.

Re: Your single-page app is now a polyfill

#132

Post by maxthegeek1 »

pier25 wrote: post #60
sambeau wrote: post #9

This is impressive and would work really well in a lot of sites, especially ones with static content. However it misses two important reasons to use a single-page app: 1. SPAs allow for highly interactive interfaces with custom components, drag & drop, audio etc. 2. SPAs can cache UI state in the client. The alternative is to store it in a server side session specific to each client. This is possible, of course, but…

> SPAs allow for highly interactive interfaces with custom components, drag & drop, audio etc. None of the features you listed require an SPA. Other than page transitions you can have any UI sophistication on an MPA. > This is possible, of course, but it will either be lost every time the server is restarted, or it will need to stored in the database. Which is why there are caching databases like Redis to solve this.

Serverside caching with e.g. doesn't help with network latency.

Re: Your single-page app is now a polyfill

#133

Post by nawgz »

recursivedoubts wrote: post #129
nawgz wrote: post #126

Earlier quoted context omitted.

>trivially implementable Care to do it here for me then? 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 mak…

You would have rows in one table, those rows would be annotated with two annotations: hx-get="/workflow/ " where 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 a…

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...

Re: Your single-page app is now a polyfill

#134

Post by recursivedoubts »

nawgz wrote: post #133
recursivedoubts wrote: post #129

Earlier quoted context omitted.

You would have rows in one table, those rows would be annotated with two annotations: hx-get="/workflow/ " where 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 a…

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 app…

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.

Re: Your single-page app is now a polyfill

#136

Post by nawgz »

recursivedoubts wrote: post #134
nawgz wrote: post #133

Earlier quoted context omitted.

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 app…

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…

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.

Re: Your single-page app is now a polyfill

#137

Post by nawgz »

lhorie wrote: post #113
nawgz wrote: post #110

Earlier quoted context omitted.

>which alone can easily be in the hundreds of milliseconds This actual paint time is surely not any different than if you rendered the exact same application from pre-hydrated HTML though. Plus, if your application is so complex that paints are on the order of magnitude of network latency, it's probably very important to have a framework to handle interactivity, else everything will end up as some kind of a mess if y…

> This actual paint time is surely not any different than if you rendered the exact same application from pre-hydrated HTML though. Well, it's different in different ways, depending on which goalpost you're standing on. If by that you mean do SSR, then run React on top, then you've just incurred the same TTFP as plain HTML, plus the cost of React hydration, plus potentially a second repaint (or even third and fourth…

>Well, it's different in different ways

You misunderstand - I mean that literally. Arriving to the same initial application state from any means, surely the HTML painter isn't going to be slower or faster. Other parts of the stack will of course be, but I really didn't understand how the painter would induce latency.

I personally see extremely limited value in SSR, I prefer to let the client machine deal with assembling related data objects into a nice UI, so you won't catch me out here arguing for it. I load an HTML page that displays an animated spinner inside #root, and then once my bundle loads it lays the application out.

Re: Your single-page app is now a polyfill

#138

Post by asddubs »

nexuist wrote: post #131
asddubs wrote: post #119

Earlier quoted context omitted.

that's confusing, I've only ever heard SSR/server side rendering to mean actually rendering html and serving that, as opposed to SPAs

Well, the idea is that you render the first pass of the SPA and serve that HTML to the client. Rather than just injecting the data into the SPA source code, you inject the data and render the page, and then serve that page. Then whatever changes the user makes to the page after that initial load gets handled by the SPA. This way the user avoids having to wait for the SPA and all its dependencies to load before the pa…

that's pretty neat, I didn't know that react could do that. Shame no one ever seems to make use of it

Re: Your single-page app is now a polyfill

#139

Post by manigandham »

nawgz wrote: post #127
mattmanser wrote: post #122

Earlier quoted context omitted.

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 aforement…

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.

Re: Your single-page app is now a polyfill

#140

Post by manigandham »

nawgz wrote: post #111
recursivedoubts wrote: post #49

Earlier quoted context omitted.

Absolutely. The initial motivation for building intercooler.js (and then htmx) was because I found that slamming a large html table rendered on the server into the DOM directly was orders of magnitude faster than running the JSON equivalent through a local template engine.

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 se…

I don't see why having an interactive table requires a SPA. No need to throw away everything for a single component on a page.
Post reply on HN