News for hackers. Stuff that matters.
Re:JavaScript hydration is a workaround, not a solution by solardev on Thursday September 01, 2022 @05:10PM (#32683249)
The whole idea of a "site" full of "pages" doesn't really suit a lot of modern use cases. What do you do when your "app" isn't really a "site" to begin with? Like most of the apps in Google Workspace, or Maps, Earth, etc. It's not their URL structure that gives them value, but the buttload of realtime clientside interactivity enabled by JS.

How are you supposed to "less JS" your way out of that?

Re:JavaScript hydration is a workaround, not a solution by OJFord on Thursday September 01, 2022 @05:18PM (#32683351)
The vast majority of SPAs are not 'Maps, Earth, etc.'.

I thought the 'if the level of interactivity basically amounts to a form' of top-level comment sums it up nicely. Many are SPAs for the sake of it, similarly to packaging a website as an 'app' but not doing anything native, offline, or that really warrants it being its own app at all other than getting homescreen space on iOS.

(Totally off-topic: I can't believe Apple still doesn't let you organise that however you want. It's sort of a small thing, but also so in your face, by far the most immediate turn-off to me of iOS.)

Re:JavaScript hydration is a workaround, not a solution by solardev on Thursday September 01, 2022 @05:27PM (#32683493)
Yeah, you're totally right in that complex web "apps" are different to a simple informational page. But do the metrics take that into account? It's just a raw performance score, no, not performance-per-complexity or performance-per-feature etc.?

How do you compare "fast" between "my journal entry today" and "Photoshop on the web" using one set of metrics...?

Re:JavaScript hydration is a workaround, not a solution by sarchertech on Thursday September 01, 2022 @10:27PM (#32685900)
You probably don’t care about the SEO ranking of the app just the landing/marketing pages.
Re:JavaScript hydration is a workaround, not a solution by wpietri on Thursday September 01, 2022 @05:16PM (#32683310)
If something isn't expressible as a site full of pages, why are you worrying about Google's metrics for sites and pages?
Re:JavaScript hydration is a workaround, not a solution by sroussey on Thursday September 01, 2022 @07:32PM (#32684751)
Agreed. If you must login, for example, then that part of the site is not indexed, so googles metrics are not relevant.

Indeed, I’ve seen higher NPS scores when it’s slower… the user feels like they are paying for more.

Re:JavaScript hydration is a workaround, not a solution by mch82 on Friday September 02, 2022 @12:21AM (#32686550)
Applications like you’re describing should consider less DOM and more Canvas API. The apps aren’t documents. They’re more like video games. DOM manipulation and rendering usually degrades performance more than the JavaScript.

One essay on this topic… https://medium.com/young-coder/the-future-web-will-canvas-re...

Re:JavaScript hydration is a workaround, not a solution by solardev on Friday September 02, 2022 @12:49AM (#32686713)
They can and should work side by side, along with SVG, WebGL, maybe WASM and workers and such. They are all web technologies. But Javascript is still the thing that controls all of them, their state, URL routing, interaction events, etc.

I spent much of the last few years working on such hybrid apps (DOM mixed with graphics techs, with clientside UI and state combined with server-side with and persistence, etc.).

The DOM has never meaningfully slowed down for me, even with CPU throttling or testing on old laptops. Canvas has, especially in some builds of Firefox. Certainly for rendering graphics canvas or WebGL are better choices, but it's not a performance magic bullet for all apps.

More often than not, the performance bottlenecks are just some bug of ours (a poorly implemented search algorithm) or an unoptimized query somewhere.

No modern web app needs to be just one thing or another. Even if you're operating almost entirely in canvas (like a map) there's still a ton of Javascript (open layers, leaflet, mapbox-gl-js, etc.) that you need, along with being able to use the DOM where it makes sense (reusing buttons, alerts, etc.)

Canvas is also really hard to make responsive. CSS evolved alongside the devices and has first class units for all that. Canvas doesn't have those easy abstractions and having to virtualize your UI without CSS-like helpers (much less things like flexbox or Bootstrap) makes it hard to make standard UIs too. HTML still has its uses for now, though arguably React and other abstractions make it much less important.

Re:JavaScript hydration is a workaround, not a solution by solardev on Friday September 02, 2022 @01:03AM (#32686793)
And sorry, one more thought: Canvas work can itself be abstracted with frameworks like OpenLayers or PixiJs or Unity. It's a testament to how powerful browsers have become that you can run full MMORPGs or other games in the browser. But that all depends on being able to download a huge Javascript bundle at load time, but then the rest of the experience is usually pretty smooth.

Games and maps are just an extreme version of that, but other examples where clientside DOM apps with heavy JS can still be faster (compared to old school server-side HTML) and easier to work with (compared to canvas) are email, e-commerce, ebooks, dashboards, chat, forums, video tubes, search and filtering, galleries, documentation, project management, etc.

Re:JavaScript hydration is a workaround, not a solution by remexre on Friday September 02, 2022 @06:59PM (#32696685)
I can see email and chat, sure, but ebooks, forums, video tubes, and documentation? All four of those seem like they shouldn't require much JS, and I would be unsurprised to find good examples of each that work even with JavaScript disabled.
Re:JavaScript hydration is a workaround, not a solution by solardev on Saturday September 03, 2022 @10:46AM (#32702339)
Sorry, the threads got a little confusing here. I think this particular one was discussing those examples in the context of using Canvas vs HTML, with or without Javascript.