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

111–120 of 164 posts

Re: Your single-page app is now a polyfill

#111

Post by nawgz »

recursivedoubts wrote: post #49
jiofih wrote: post #13

You know what also uses the streaming parser? Standard server-rendered pages. The idea that SPAs are faster because “they just download the content” is rarely true, HTML compresses well and the content will take the same space in either. The real bottlenecks are in re-executing huge amounts of JS per page (don’t have huge amounts of JS?) and page transitions (being worked on).

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

Re: Your single-page app is now a polyfill

#112

Post by nawgz »

dougmany wrote: post #104
Justsignedup wrote: post #55

My reasons for SPAs has always been complex behaviors on the app and state persistence is a PITA if you don't end up with a nice MVVC on the front-end. Not saying not possible to make complex pages without SPAs, but there are some things that are harder, and some that are easier. Personally I love writing SPAs, I find that I end up making less complex code which ends up being easier to maintain. Not counting by the n…

I am curious what tools you are using. I am trying to upgrade Angular 1.4 to 1.7 and it is a nightmare. Has your method had any sort of time test for upgradability?

Angular 1 is ancient and terrible.

I've been developing React for the last 5 years, times change and "best practices" change with them, but my 3 year old model / graph editor seamlessly upgrades across React versions, even if my eyes don't love the code like they once might've.

Re: Your single-page app is now a polyfill

#113

Post by lhorie »

nawgz wrote: post #110
lhorie wrote: post #106

Earlier quoted context omitted.

> that's going to be less than 1ms of delay That doesn't jive with my experience. If you are using something like React to do client-only rendering, you're gonna be waiting a lot for blocking critical path JS to run, as well as the actual paint time (which alone can easily be in the hundreds of milliseconds). > Ship your users an app including a copy of the data ahead of time That's not really feasible though, is it?…

>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 repaints, depending on how your data trickles in). In the wild, this pattern gets particularly egregious when people decide that it's ok to have loading icons and widgets pushing each other down as data comes in.

If you mean to compare to client-side rendering without SSR, then you're still looking at the cost of at least two repaints (the initial TTFP repaint, plus any repaints from data fetching after that).

Re: Your single-page app is now a polyfill

#114

Post by pier25 »

orthecreedence wrote: post #109
pier25 wrote: post #64

Earlier quoted context omitted.

I agree. I wrote an SPA with Mithril a couple of months ago and the entire app fit in 38kB gzip. For me the biggest drawback of an SPA is that it's a lot more work.

I've found SPAs to be less work. Instead of having two templating systems (server-side and client-side) there's just one on the client side. Now I don't have to share code between client and server, but more than that, the two are logically separated. The client can just be a client, rather than a strange half-extension, half-app of the server. Secondly, if you also want to expose an API, do you put it in the server…

I agree having two templating systems is a problem (more on this later) but by going SPA your front end now becomes massively more complex than sprinkling some JS here and there. For example you now need to manage application state which is not a trivial problem on large projects. You also need to replicate native browser UX if you're serious about making a good SPA (eg: your forms are filled when going back, the content and scroll position are preserved when going back, etc).

As for the duplicate template problem, this is easily solved by doing SSR + hydration. I concede this is generally complex to set up (unless using something like Next.js) but it's worth it IMO. It's really the best of both worlds (MPA vs SPA). You are still creating components and having a sophisticated interactive UI just like in the SPA world, but front end development is greatly simplified since you're only dealing with one page at a time. Also, in many cases, you might not even need an API. How many times have you create an API only to feed your SPA? It's a lot of overhead.

Also these days I don't think the decoupling argument is so strong unless you're working on a complex project with multiple teams.

Re: Your single-page app is now a polyfill

#115

Post by qu4z-2 »

mdoms wrote: post #88
pier25 wrote: post #58

Earlier quoted context omitted.

Also probably because you're close to the server. I doubt someone in say New Zealand would have instant page loads on HN. The solution of course is having distributed data and logic which is becoming much easier and cheaper these days.

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.

Re: Your single-page app is now a polyfill

#117

Post by [deleted] »

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…

[deleted]

Re: Your single-page app is now a polyfill

#118

Post by [deleted] »

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…

[deleted]

Re: Your single-page app is now a polyfill

#119

Post by asddubs »

nexuist wrote: post #82
victor106 wrote: post #77

Earlier quoted context omitted.

This is cool. What techniques did you use to include a copy of the data?

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

Re: Your single-page app is now a polyfill

#120

Post by recursivedoubts »

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…

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

Post reply on HN