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

141–150 of 239 posts

Re: JavaScript hydration is a workaround, not a solution

#141

Post by dmitriid »

wruza wrote: post #138
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…

Go back to fundamentals … if the level of interactivity on your website amounts to basically a form What if it doesn’t? I mean by requirements from various departments/analysts and user’s common sense.

In 99% of cases your website will still be basically a form.

Re: JavaScript hydration is a workaround, not a solution

#142

Post by wruza »

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…

We must return to fundamentals.

These are not fundamentals. Overtone window has shifted out of its initial position completely, but browsers ignored it for two decades and offloaded that to webapp developers. Web 2.0 is not a browser, it is what became possible with everything people have built outside of it, on top of “take it or leave it” attitude. Web 1 is an archaic network of winword-level documents that is a huge step backwards in ui, ux, common sense.

We must not return to anything, browsers must get their ass up and running towards what other people achieved through hard work despite all the obstacles.

Re: JavaScript hydration is a workaround, not a solution

#143

Post by joshmanders »

BeefWellington wrote: post #33
dmix wrote: post #30

Earlier quoted context omitted.

> 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. I highly recommend trying out Linear.app, it's as fast as any desktop app I use. Replicache made a clone demo https://repliear.herokuapp.com/ the production linear app is even faster But if you're com…

That demo literally shows a brief "Loading..." screen for the first open issue, which was pretty much my point. I'm not sure what other desktop apps you use but for something as simple as viewing a single database record I've not seen loading screens since about 2000 on any native apps.

> I've not seen loading screens since about 2000 on any native apps.

Have you used any real apps, because Macromedia Dreamweaver/Adobe Photoshop/etc had literal minute long splash loading screens where they zoomed text on a small snippet telling you what it was doing since at LEAST 2000....

Re: JavaScript hydration is a workaround, not a solution

#144

Post by personalidea »

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…

> We will never again have another private thought, another uninterrupted conversation, eye contact, feeling someones hands as you tell them how much their being means to you.

I disagree. It is just that these now need a conscious decision from us. My thoughts are still private until I choose to publish them. My conversations are only interrupted if I allow them to be. We make eye contact when we decide to. The intimate moments with my partner are there when we create them.

True, it’s easy to loose that and growing up today, you need someone to show you that it can be done. Which is why I agree that we stand to loose that, but we are not there yet.

Re: JavaScript hydration is a workaround, not a solution

#145

Post by Dylan16807 »

dntrkv wrote: post #93
lhorie wrote: post #86

Earlier quoted context omitted.

One story that comes to mind was when I was still relatively early in my career and the COO of the company came to me asking for some help getting some jquery ui tab widget thingie to work. And as if the words "COO" and "jquery ui" in the same sentence weren't enough to raise eyebrows, what came next was probably one of the most mind bending software engineering episodes I'd ever witness. It turned out he was trying…

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.

It shouldn't be hard to make a static site generator for a small pile of queries that's very easy to maintain.

You can only anticipate so much up front. You're always going to have to rewrite things after enough growth, so make it easy to add complexity later.

Re: JavaScript hydration is a workaround, not a solution

#146

Post by spion »

commandlinefan wrote: post #56
the__alchemist wrote: post #34

> In web development, Hydration is a technique to add interactivity to server-rendered HTML. It’s a technique in which client-side JavaScript converts a static HTML web page into a dynamic web page by attaching event handlers to the HTML elements. This is how I use JS. I may be misunderstanding something, but this is a nice way to use JS to add targeted interactivity to a page while keeping load times and interaction…

That's how everybody used Javascript when it first came out, coming up on 30 years ago. This is how it was designed to be used in the first place. This seems to happen with everything - somebody solves a problem, somebody else gains a very partial understanding of the solution, adds unnecessary hacks on top of the solution that they thought they needed because the didn't spend any time understanding how the solution…

There is also the situation where someone gets a really partial understanding of a certain solution and as a result wonders why the author didn't implement a simpler solution.

Re: JavaScript hydration is a workaround, not a solution

#147

Post by [deleted] »

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…

[deleted]

Re: JavaScript hydration is a workaround, not a solution

#148

Post by [deleted] »

lhorie wrote: post #86
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…

One story that comes to mind was when I was still relatively early in my career and the COO of the company came to me asking for some help getting some jquery ui tab widget thingie to work. And as if the words "COO" and "jquery ui" in the same sentence weren't enough to raise eyebrows, what came next was probably one of the most mind bending software engineering episodes I'd ever witness. It turned out he was trying…

[deleted]

Re: JavaScript hydration is a workaround, not a solution

#149

Post by jstanley »

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.

Re: JavaScript hydration is a workaround, not a solution

#150

Post by danielvaughn »

dntrkv wrote: post #93
lhorie wrote: post #86

Earlier quoted context omitted.

One story that comes to mind was when I was still relatively early in my career and the COO of the company came to me asking for some help getting some jquery ui tab widget thingie to work. And as if the words "COO" and "jquery ui" in the same sentence weren't enough to raise eyebrows, what came next was probably one of the most mind bending software engineering episodes I'd ever witness. It turned out he was trying…

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.

Yep, my personal webpage probably has like a 10/10 score on any performance tracking thing you could find. Because I literally just wrote some html and css, and dropped it into github pages.
Post reply on HN