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

181–190 of 239 posts

Re: JavaScript hydration is a workaround, not a solution

#181

Post by thethirdone »

qudat wrote: post #170
thethirdone wrote: post #26

Earlier quoted context omitted.

> The recent evolution of JS frameworks has been really nice. Performance is basically getting identical to desktop. Web browsers in general are not able to match applications on the desktop. Additionally, typical JS frameworks come with at least a 2x performance penalty compared to hand-optimized vanilla JS (Not a commonly done thing). Being excited about getting reasonable performance with a great development envir…

> but deluding yourself into thinking that its great performance is not. What's the actual issue though? Sure on HN we care a lot about performance. But outside these walls performance has to be really bad for someone to actively avoid it. Even then, if the product has a stronghold on its userbase, you have to really degrade performance for engagement to falter.

The problem is not that a particular library, framework, or app is slow. The problem is the mindset "This is the best performance possible". Having that mindset makes you accept extremely poor performance even when it is not economically advantageous to stop optimizing.

Even though I am personally frustrated at how willing users are to accept slow software; I do recognize that the velocity and comfort of development outweighs the performance considerations in many cases. However, a mindset that makes you never check to see if the performance considerations are worth it to the users WILL make you make the wrong decisions.

Re: JavaScript hydration is a workaround, not a solution

#182

Post by woojoo666 »

BeefWellington wrote: post #22
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…

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

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

Re: JavaScript hydration is a workaround, not a solution

#183

Post by tmnvix »

SketchySeaBeast wrote: post #11
aliqot wrote: post #2

Maybe I'm just getting old, but Javascript jumped the shark at some point. Hydration, lazy loading, managing flashes of unstyled content, a lot of this is built to address things that wouldn't be problems if we treated the browser as the dojo that it is and not be so dang wasteful. im sure someone with shinier boots than mine will pop in and tell me how im wrong, and perhaps youre right, but the web was a much better…

> if we treated the browser as the dojo that it is I have no idea what this means. Isn't a dojo a place for learning or meditation? I don't understand how that fits the browser, the internet, or web development.

My take was something along the lines of 'the browser is a place to strive for simplicity and mastery' instead of 'move fast and break things'.

Re: JavaScript hydration is a workaround, not a solution

#184

Post by sroussey »

wpietri wrote: post #155
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?

If something isn't expressible as a site full of pages, why are you worrying about Google's metrics for sites and pages?

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

#185

Post by irrational »

anotheracctfo wrote: post #101
dntrkv wrote: post #93

Earlier quoted context omitted.

The purpose of the more complicated solutions is to build something that will be maintained for a long time where complexity will grow, and usually, require multiple contributors. I can bang out a basic landing page site in a few hours that will be extremely performant while pulling in zero libraries. But I would never want to maintain that over any extended period of time or added complexity.

The purpose of more complicated solutions is to prevent devs from becoming bored and leaving. In my experience, KISS results in the easiest solution to maintain. Then I get a litany of complaints from devs that "this isn't programming" or "this is a dead end to my career" and then they leave. Which paradoxically makes it more difficult to maintain, as I have no maintainers lol.

You just need to hire older people. I’ve been doing web development for nearly 25 years. I’m at the point where I would love to just babysit some sites while spending more time on my hobbies and more time with my family.

Re: JavaScript hydration is a workaround, not a solution

#186

Post by rglover »

jstanley wrote: post #149
rglover wrote: post #121

The overhead is arbitrary if done properly. I did this in Joystick [1] and was shocked at how overcomplicated folks make it. You're literally just saying "render to static HTML on the server, and on the client, have a way to render a root component to screen and attach event handlers." Without any serious thoughts about optimization (practically none yet), a no-cache refresh/mount takes 227ms to DOMContentLoaded and…

Are you saying it takes 469ms to attach event handlers? That's well over a billion clock cycles. That doesn't sound efficient.

No. A quick rough profile: https://imgur.com/a/hVLD5Db

Event handlers are attached by queueing them up as I render the component tree and then after the tree is mounted to the DOM, I just run the queue to attach the listeners.

Re: JavaScript hydration is a workaround, not a solution

#188

Post by zemnmez »

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…

> Make something that works with with HTML and CSS alone, and enhance it with JS.

Hydration is... an automated system to do this? Am I missing something

Re: JavaScript hydration is a workaround, not a solution

#189

Post by pdimitar »

anotheracctfo wrote: post #101
dntrkv wrote: post #93

Earlier quoted context omitted.

The purpose of the more complicated solutions is to build something that will be maintained for a long time where complexity will grow, and usually, require multiple contributors. I can bang out a basic landing page site in a few hours that will be extremely performant while pulling in zero libraries. But I would never want to maintain that over any extended period of time or added complexity.

The purpose of more complicated solutions is to prevent devs from becoming bored and leaving. In my experience, KISS results in the easiest solution to maintain. Then I get a litany of complaints from devs that "this isn't programming" or "this is a dead end to my career" and then they leave. Which paradoxically makes it more difficult to maintain, as I have no maintainers lol.

Another poster beat me to it: hire older devs! I'm 42 and my ideal work is maintaining several systems that move rather slowly. It's chill, still responsible, and allows for creativity and inventive solutions when the need calls for it.

Not going to bash younger devs in general but the fact is that getting the job done without thinking of their future career... is usually not high in their list of priorities.

Re: JavaScript hydration is a workaround, not a solution

#190

Post by marssaxman »

tshaddox wrote: post #180
blep_ wrote: post #140

Earlier quoted context omitted.

It is for things like checkboxes. If your design requires checkboxes to be special and different from everyone else's checkboxes, your design is wrong .

Everyone else’s checkboxes aren’t all the same though.

They used to be, and it was better that way.
Post reply on HN