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

121–130 of 164 posts

Re: Your single-page app is now a polyfill

#121

Post by qpiox »

fxtentacle wrote: post #17

I feel like the whole article misses the point. Yes, the rendering delay caused by a non-streaming HTML parser exists, but unless you screw things up elsewhere, that's going to be less than 1ms of delay. Yes, bloated frameworks are annoying, but not due to their computational overhead per se, but because they increase download size and because Javascript is slower then native code in general. I find it very telling t…

Misses the point on so many levels.

Fastest experience will always be without a special framework. Fastest will always be if there is nothing except the content served in a single minimal request/response. So, this means no JS (excepct issuing requests), no browser framework, pure content. Browser sends the simplest request and receives simplest content. User reads it or looks at it. Fast as hell. It can't be faster than that because JPG can not be compressed further, gzipped HTML can not be compressed further. With later HTTP implementations, the connection can already be open and re-used.

To explain this with an analogy. Bloatware comes when you decide that your true content is not enough to be appreciated as is, and needs to be beautified, made interactive, .... Just like make-up. Without make-up you only need to show your face. When you decide to use make-up to cover the true content (your true face), you need huge ammount of overhead - you need to buy the make-up, you need to learn how to apply the make-up, clean the make-up, re-apply the make-up. You need robust make-up. You need waterproof make-up. Then you need special cleaner because water will not be able to clean it. Then you start needing a make-up framework, to help you clean, apply and re-apply the make-up consistently and easily. So reinventing make-up frameworks will do nothing in alleviating overhead. Dropping the framework is the best way to go.

I hope this analogy makes things clear what I meant.

Re: Your single-page app is now a polyfill

#122

Post by mattmanser »

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…

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.

Re: Your single-page app is now a polyfill

#123

Post by rob74 »

nexuist wrote: post #99
rob74 wrote: post #87

Earlier quoted context omitted.

> forego the website entirely and post your information on social media which can then be consumed by optimized native apps ...and force the user to install the "optimized native app" for the social media site du jour ? Or simply let them put up with Facebook's "yes-this-is-a-public-page-but-I'm-still-going-to-ask-you-to-log-in-or-sign-up-just-because-I-can" shenanigans? Great UX, that!

Are we really going to assume that your average user doesn't already have FB installed and already signed in? They have over one billion users, you know. It's not exactly rare to find Facebook on any arbitrary person's device.

Even assuming all of those accounts are still active (and none of them are duplicates), that still leaves around 7 billion people without a Facebook account. Personally, I do have a Facebook account, but I only use it on my private desktop PC, not on my work laptop and also not on my phone.

Re: Your single-page app is now a polyfill

#124

Post by jdbernard »

astura wrote: post #84
imtringued wrote: post #45

Earlier quoted context omitted.

>The main one is that the browser loses its state at each page reload, and that the state on the server, if any, needs to be reconciled every time with that on the browser. Yes, I also noticed this flaw. There is no good way of dealing with this other than saving state into localStorage which is less than ideal.

Traditionally you'd save it in the session on the server

And that really underscores the OP's point. With SPAs your servers no longer need to scale linearly with your user base. You don't have to solve all the myriad problems that come with maintaining state for all users in a centralized location.

Re: Your single-page app is now a polyfill

#125

Post by tpxl »

shusson wrote: post #26

> Why do we build single-page apps?... > We want our web apps to feel “instant”... > Blank screens make for a bad user-experience... In my experience if you really need fast page loads, SPAs are off the table. So the premise of the article makes no sense to me. In fact, what do people on HN think the main reason to choose an SPA is these days?

>In fact, what do people on HN think the main reason to choose an SPA is these days?

The only reason to choose a SPA is when you need an _application_.

A blog has no reason to be a SPA. A news site has no reason to be a SPA. HN has no reason to be a SPA.

An internal support tool has a reason to be a SPA. A messaging app has a reason to be a SPA (slack et. al). A music player has a reason to be a SPA (spotify).

Re: Your single-page app is now a polyfill

#126

Post by nawgz »

recursivedoubts wrote: post #120
nawgz wrote: post #111

Earlier quoted context omitted.

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…

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

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

Re: Your single-page app is now a polyfill

#127

Post by nawgz »

mattmanser wrote: post #122
nawgz wrote: post #111

Earlier quoted context omitted.

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…

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.

Re: Your single-page app is now a polyfill

#128

Post by pier25 »

qu4z-2 wrote: post #115
mdoms wrote: post #88

Earlier quoted context omitted.

I'm in New Zealand. HN page loads are about as instant as you can get on the web. Certainly faster than the vast majority of SPA interactions and their requisite API calls.

I'm seconding this. I'm in New Zealand and Hacker News is easily one of the most responsive sites on the web, in my experience.

How long do you wait for TTFB from HN on average?

Re: Your single-page app is now a polyfill

#129

Post by recursivedoubts »

nawgz wrote: post #126
recursivedoubts wrote: post #120

Earlier quoted context omitted.

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

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

https://htmx.org/attributes/hx-get/

https://htmx.org/attributes/hx-target/

https://htmx.org/attributes/hx-push-url/

Re: Your single-page app is now a polyfill

#130

Post by nexuist »

rob74 wrote: post #123
nexuist wrote: post #99

Earlier quoted context omitted.

Are we really going to assume that your average user doesn't already have FB installed and already signed in? They have over one billion users, you know. It's not exactly rare to find Facebook on any arbitrary person's device.

Even assuming all of those accounts are still active (and none of them are duplicates), that still leaves around 7 billion people without a Facebook account. Personally, I do have a Facebook account, but I only use it on my private desktop PC, not on my work laptop and also not on my phone.

I agree with you, I'm only logged into my work FB account on my personal device, however I'm also a power user (and I'm guessing you are too) so I don't think our experiences can extrapolate out to the population as a whole. Sure 7B people don't have FB, but are you trying to invite 7B people to your event or business? Not really; you're probably trying to target a very specific kind of person, or a group of people you already know. In that case you can just do some surveying / focus group'ing to figure out what people already use and push your content on the platforms that cover the majority of users (which in most cases, I'm guessing, would include FB).
Post reply on HN