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

211–220 of 239 posts

Re: JavaScript hydration is a workaround, not a solution

#211

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

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

#212

Post by nyanpasu64 »

tln wrote: post #73
BeefWellington wrote: post #22

Earlier quoted context omitted.

> The recent evolution of JS frameworks has been really nice. Performance is basically getting identical to desktop. It's getting much much better but performance is only "identical to desktop" if you ignore anything about its resource usage or speed increases in processors over the past decades. > For people not following JS these might all seem like constantly reinventing past lessons, but there is a logical evolut…

> Seriously though, go load up any natively compiled app on your OS of choice and compare the speed of it doing any given task to what you get out of web-based versions, electron versions, etc. There isn't a comparison. My experience is a bit different... Google Docs loads faster than Numbers Figma loads faster than Illustrator VS code loads faster than Xcode (not a fair comparison) Quicknote.io loads faster than Sim…

VS Code loads slower than Sublime or Kate (though they're a bit lighter on features than Code, not sure it's slower than Qt Creator). And Google Docs takes many seconds (worse on older hardware) to load 100-150 page documents (4 seconds for warm load on Firefox on a top-of-the-line (for single-threaded) Ryzen 5600X) than LibreOffice Writer (just over 1 second on warm startup, 0.6 seconds if Writer is already running).

Re: JavaScript hydration is a workaround, not a solution

#213

Post by onion2k »

solardev wrote: post #152
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…

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…

And what do you do for more complex, stateful apps?

To quote Albert Einstein, "Make everything as simple as possible, but not simpler."

This applies as much to your JavaScript bundler configuration as it does to the origins of the universe. It's not surprising really, because if I say "an instantaneous explosion that causes the entire universe to be filled with matter" you don't know if I'm talking about the Big Bang or Webpack.

Re: JavaScript hydration is a workaround, not a solution

#214

Post by mburee »

tsimionescu wrote: post #134
AnIdiotOnTheNet wrote: post #131

Earlier quoted context omitted.

> The idea that all apps should use some kind of system style that dictates shape for every single control is... Odd. I don't know of any system that operates like this We came damn close to every OS operating like this in the late 90s. Sadly the future arrived.

I don't think that is actually a good thing. I much rather have people less tied to one particular ecosystem, and preventing barriers to moving from one OS to another.

By moving from one OS to the other you really mean Windows/OSX/Linux, right? Because thanks to modern web(browsers) you can almost but forget using another one, regardless of someones checkbox design.

Re: JavaScript hydration is a workaround, not a solution

#215

Post by grey-area »

ItsTooMuch wrote: post #109
grey-area wrote: post #100

Earlier quoted context omitted.

<contenteditable

Sure. And now you need thousands of lines of JS to make it cooperative in real time.

That's not a requirement for most people, versions and locking is fine.

There are certainly refinements that can be added with JS, but JS is not a requirement, and certainly is not for rendering an editable page.

Re: JavaScript hydration is a workaround, not a solution

#216

Post by yazaddaruvala »

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…

> Perhaps its the apparent conflict between UX and DX that leads to tooling complexity?

In theory improved DX leads to improved UX. In practice, subpar/lazy tooling needs to be worked around to get better DX.

I’ve added a lot of JS weight to migrate legacy apps to React always improving time to interactive and responsive error handling/messaging. Vanilla JS and even Jquery just don’t have the DX that allows them to scale in a corporate context (specifically because of under experienced engineers and poor “due dates”).

IMO it’s a lack of initiative from browser developers to move the web forward faster (obvious given the funding comes roughly exclusively from the developers of iOS and Android). I understand the inertia of legacy browsers, but it should not take decades to eliminate the need for these DX polyfills (eg like Jquery took to become redundant, and how long it’s taking React/Vue/Svelte style components).

Re: JavaScript hydration is a workaround, not a solution

#217

Post by pdimitar »

aliqot wrote: post #29
xjose97x wrote: post #8

Earlier quoted context omitted.

Can't tell if this is is a joke or not lol

There is some bias in this comment, perhaps Ordnung is what compels it, but simpler was better, and though collectively we were less informed, we were also less burdened. There is value in a plain lifestyle and community. We've lost a sense of community because of this pervasive false-familiarity that the internet and phones have created. You no longer need to see your relatives and community members because you can…

This sort of generalization really doesn't help any discourse.

While it's indeed easy to lose the things you mentioned we're still not forced to do so. Many are already stepping back and reconsidering their choices, and rediscovering various real-life elements. I'm seeing it around me.

And this:

> We've lost a sense of community

...is extremely one-sided. I started my life in a small town where if a bunch of prejudiced people didn't like you then God help you because they could even make sure grocery stores will not be selling you food. I wish you luck even existing on a basic level there.

For people who don't have the approval of their small communities, internet (or physically moving) has been a blessing.

So while your point is valid, you went way too far without regard for nuance. The fact that a lot of people waste their precious time on bullshit on the net does not in any shape or form mean internet hasn't been extremely helpful and enabling for many people.

Re: JavaScript hydration is a workaround, not a solution

#218

Post by tsimionescu »

fleddr wrote: post #173
naet wrote: post #129

Earlier quoted context omitted.

"Just compromise your design", surprisingly, isn't a one size fits all solution. Especially when you can implement things yourself. Yes, it's harder than you think, but sometimes it needs to be done.

No, your designer sucks. Don't reinvent well known controls. Stop doing it. You can give it a border color and an accent color (check out the new accent-color CSS property) and for the rest you leave it alone.

This is completely silly, and no one does this. If I'm going for a square design, I'll want my checkboxes to be square, not rounded squares like Firefox offers for example.

Try to extend this idea to a game menu and see how much sense it really makes to you: would anyone really want default browser checkboxes in an otherwise medieval styled game UI, for example?

Also, if you truly believe that all checkboxes in all apps should look exactly the same (per browser/OS, and except for color), then why not extend this to other aspects of design? Why even allow different sites to use different fonts? That is much harder to adjust to than a different roundness on checkbox corners.

Re: JavaScript hydration is a workaround, not a solution

#219

Post by qu4z-2 »

8note wrote: post #158
AnIdiotOnTheNet wrote: post #135

Earlier quoted context omitted.

Instead they get to learn new ways of doing things with every single application they use regardless of platform and still have to deal with platform issues. Yay for progress?

However, they also benefit from innovation in how those widgets work, rather than being locked to historic buttons because the committee can agree on on pixel change a year

Innovation like not having a tabstop.

Re: JavaScript hydration is a workaround, not a solution

#220

Post by likortera »

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…

Meanwhile I'm having a ton of fun (and better metrics) by just rendering html from the server and using Unpoly for interactivity and "old style ajax" dynamic updates. And still building the entire application in JavaScript, end to end.
Post reply on HN