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

JavaScript hydration is a workaround, not a solution

thenewstack.io

Post reply on HN
Print view View original

201–210 of 239 posts

Re: JavaScript hydration is a workaround, not a solution

#201

Post by yawaramin »

paulirish wrote: post #151
onion2k wrote: post #37

...get a PageSpeed score of 100/100 I'm slowly coming around to the idea that PageSpeed (or Lighthouse, or Core Web Vitals, or whatever Google has invented this week) is what drives a lot of the complexity in web app dev. People refuse to throw out what they've learned, so every time there's a new metric to chase in case you lose SERPS ranking for being slow! devs heap another layer of complexity on to the Webpack bo…

Speaking as the TL of Lighthouse and PageSpeed, I can comfortably say that adding complexity is antithetical to our goal. Quality UX and a reliably performant web is what we want for all users. Ideally, folks would use a thinner stack with _less_ JS, as that's rewarded across all the metrics. But in recent years, many teams build a "site" by building a SPA. As they're entrenched in that dubious decision, the only pat…

It's ironic of Google to try to drive web performance when websites are full of Google Analytics scripts. Like the fox guarding the henhouse ;-)

Re: JavaScript hydration is a workaround, not a solution

#202

Post by woojoo666 »

BeefWellington wrote: post #198
woojoo666 wrote: post #182

Earlier quoted context omitted.

The web apps that take 100+ms round trip are ones that have to download the entire page. Downloading a new desktop app takes even longer. If you use a local-first webapp that is cached on your desktop, that's a fairer comparison

This makes no sense. Downloading a web browser takes even longer. It's an insane comparison to draw in the context of the experience of actually using an application. Nobody cares about startup time when it's a task you do once a day compared to using the application which might be constant throughout the day. How often are people booting up their IDEs?

It's equally unfair to compare the round-trip load of an application that people expect to download on-demand, versus an application that is already installed on the client

Re: JavaScript hydration is a workaround, not a solution

#203

Post by sarchertech »

solardev wrote: post #160
OJFord wrote: post #156

Earlier quoted context omitted.

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…

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

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

#204

Post by ricardobeat »

This is a very confusing, and then disappointing, article.

It starts by describing what is, essentially, plain javascript or how you'd use jQuery in the old days. Attaching events to the DOM at startup is not hydration.

Then it starts describing what seems to be React's particular flavour of hydration, where it re-renders the entire app before applying its diff/reconciliation algorithm. But in a very roundabout way, it's not clear what they are even talking about. Not every framework works like that. And, it's definitely not the heaviest part, diffing the DOM can be extremely fast. The slowness comes from, erm, everything else and just the sheer amount of code these frameworks run.

By the third section, I had the feeling this would be an advertisement for Qwik, because of the 'closure around app state' concept, and how they appear to believe that lazy loading everything is the best idea since sliced bread. Bingo :)

Re: JavaScript hydration is a workaround, not a solution

#205

Post by silasb »

dmix wrote: post #7

The recent evolution of JS frameworks has been really nice. Performance is basically getting identical to desktop. The three recent developments I've noticed: - "Islands" in Deno https://fresh.deno.dev/ and https://remix.run/ where only small isolated parts get hydrated, instead of the whole page - Using http://linear.app style data-flows ala Replicache ( https://replicache.dev/ ) where JSON data is preloaded for all…

You did a good job summarizing the frontend framework evolution, but I'm curious where you think the evolution in backend frameworks are going? I was thinking LiveView, but I also think WASM could come into play as well.

Re: JavaScript hydration is a workaround, not a solution

#206

Post by MatthiasPortzel »

fleddr wrote: post #172
solardev wrote: post #152

Earlier quoted context omitted.

And what do you do for more complex, stateful apps? I don't think it's fair to dismiss this problem as "just use HTML and CSS and a sprinkling of vanilla JS". What happens when you need to build anything more complex than a basic form? A dashboard, or web map, or Figma, or Slack, or Gmail, or Gsheets... everything from state to AJAX (and other async) to persistence to URL routing, etc. becomes insanely complex. I fee…

The examples you give are a 100% fit for the SPA model. Nobody would build Google Docs or a game from server-side HTML. That's not the discussion. The discussion is everything except that. The typical example being a CRUD app. A bunch of cards, filters on the left, search box on top, logged in user. It usually isn't much more than that. Which means its low state and lowly interactive.

The problem is that there are a few cases in every CRUD app where it is undeniable that the best user experience would come from client-side rendering. Stuff like password criteria validation, filtering or sorting a column on a table, upvoting or downvoting a post, and other application specific behaviors shouldn’t require a page reload.

What we tried in the jQuery-era was augmenting mostly-server-side apps with components that handled these behaviors. But it wasn’t a good dev experience and it wasn’t a good user experience.

So a lot of teams choose to build entirely in JS nowadays since it leads to a simpler experience to have everything in a React SPA than some things in and some things in jQuery.

I’m not saying this is perfect, I think we still have a long ways to go. But I’m optimistic about the current wave of JS tools (Hotwire, Astro, Fresh), and I think “just go back to server side frameworks” isn’t solving any problems.

Re: JavaScript hydration is a workaround, not a solution

#207

Post by gitgud »

cxr wrote: post #88
phailhaus wrote: post #62

Earlier quoted context omitted.

People want to be able to author and share docs, directly in the browser and share with no effort. You cannot do this without JS, and the level of complexity is sufficient that you need robust tooling in order to manage it.

You can do this directly in the browser* without JS—in exactly the way shown by the example I just gave: by using a browser that is capable of editing and sharing docs (directly). * If someone really wanted to be a stickler, they could point out that that you've set up Google Docs to fail your own rubric, since it involves indirect editing. The browser itself has no direct role in the editing process. It only manages…

> You can do this directly in the browser without JS—in exactly the way shown by the example I just gave: by using a browser that is capable of editing and sharing docs (directly).

So your users will need a specific browser to use your Web app?

This goes against a primary advantage of Web apps... They work on many different browsers/devices*

Re: JavaScript hydration is a workaround, not a solution

#208

Post by [deleted] »

onion2k wrote: post #37

...get a PageSpeed score of 100/100 I'm slowly coming around to the idea that PageSpeed (or Lighthouse, or Core Web Vitals, or whatever Google has invented this week) is what drives a lot of the complexity in web app dev. People refuse to throw out what they've learned, so every time there's a new metric to chase in case you lose SERPS ranking for being slow! devs heap another layer of complexity on to the Webpack bo…

[deleted]

Re: JavaScript hydration is a workaround, not a solution

#209

Post by mch82 »

solardev wrote: post #153
paulirish wrote: post #151

Earlier quoted context omitted.

Speaking as the TL of Lighthouse and PageSpeed, I can comfortably say that adding complexity is antithetical to our goal. Quality UX and a reliably performant web is what we want for all users. Ideally, folks would use a thinner stack with _less_ JS, as that's rewarded across all the metrics. But in recent years, many teams build a "site" by building a SPA. As they're entrenched in that dubious decision, the only pat…

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?

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

#210

Post by solardev »

mch82 wrote: post #209
solardev wrote: post #153

Earlier quoted context omitted.

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?

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

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.

Post reply on HN