JavaScript hydration is a workaround, not a solution • Hacker News Board

Re: JavaScript hydration is a workaround, not a solution

#221

Post by likortera » Fri, Sep 02, 2022, 12:32 PM UTC

tsimionescu wrote: post #82

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…

> Just make something that works with with HTML and CSS alone, and enhance it with JS. You don't need to be clever about it, especially if the level of interactivity on your website amounts to basically a form. A big problem with this is that html is extraordinarily limited as a widget framework. You only have a handful of widgets available, and many of them offer very little (if any) customizability from CSS. For ex…

> So, if you're doing all of this effort anyway, why go through the effort of using the HTML input checkbox at all?

Because HTML is the only way to do a checkbox?... Even if you use JavaScript, at the end of the day you'll have to generate HTML for it to render... so then why go through the effort of using JavaScript for a checkbox at all?

Re: JavaScript hydration is a workaround, not a solution

#222

Post by lelanthran » Fri, Sep 02, 2022, 1:24 PM UTC

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.

They're not even within orders of magnitude. What makes you say that the performance is nearly identical?

Re: JavaScript hydration is a workaround, not a solution

#223

Post by ItsTooMuch » Fri, Sep 02, 2022, 1:29 PM UTC

grey-area wrote: post #215

ItsTooMuch wrote: post #109

Earlier quoted context omitted.

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.

We're talking about programming apps such as Google docs. It is a hard requirement. Your reply is completely useless from technical perspective. Sorry-not-sorry to be so blunt but I have no sympathy for "yeah you can do it without any JS if you remove all features". Let's just go a little further and throw away our computers - we can send carrier pigeons to each other, right? And what's this paper stuff? Useless! Stone tablets 4ever!

And as a user, it is a hard requirement for me too. I never want to go back to locking and versions, that's absolutely terrible and completely kills the workflow I have with my colleagues. Collaborative docs editing is single most awesome development of the modern web and users are choosing the otherwise not-so-good Google Docs solely based on this feature. Perhaps not every user needs it - but there are countless users that do. If I wanted to edit without collaboration I'd use Word - much better UX and document editing capabilities... Sadly no truly working collaboration - it's too much like locking/versions, so it's not an option. I'd rather use collaborative raw text editor than the best of the best locking/versioned WYSIWYGs.

Re: JavaScript hydration is a workaround, not a solution

#224

Post by buzzwordninja » Fri, Sep 02, 2022, 5:08 PM UTC

teaearlgraycold wrote: post #199

jollyllama wrote: post #107

Earlier quoted context omitted.

COO invents caching. Relatively harmless in the grand scheme of things.

Rewritten as a horror story: > COO invents cache invalidation

CIO - Cache Invalidation Officer

Re: JavaScript hydration is a workaround, not a solution

#225

Post by saurik » Fri, Sep 02, 2022, 10:47 PM UTC

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.

I mean, if it really took you a few hours, maybe you actually could throw it away and start again later? Meanwhile, if you have to keep rewriting your setup anyway to account for the new shiny toy everyone insists you use every year, have you really made something that requires less effort to maintain?

Re: JavaScript hydration is a workaround, not a solution

#226

Post by remexre » Fri, Sep 02, 2022, 10:59 PM UTC

solardev wrote: post #211

mch82 wrote: post #209

Earlier quoted context omitted.

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

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

#227

Post by tsimionescu » Sat, Sep 03, 2022, 6:37 AM UTC

likortera wrote: post #221

tsimionescu wrote: post #82

Earlier quoted context omitted.

> Just make something that works with with HTML and CSS alone, and enhance it with JS. You don't need to be clever about it, especially if the level of interactivity on your website amounts to basically a form. A big problem with this is that html is extraordinarily limited as a widget framework. You only have a handful of widgets available, and many of them offer very little (if any) customizability from CSS. For ex…

> So, if you're doing all of this effort anyway, why go through the effort of using the HTML input checkbox at all? Because HTML is the only way to do a checkbox?... Even if you use JavaScript, at the end of the day you'll have to generate HTML for it to render... so then why go through the effort of using JavaScript for a checkbox at all?

I meant, why use , not why use any HTML tag at all. Of course you need some kind of div or span to style.

Re: JavaScript hydration is a workaround, not a solution

#228

Post by solardev » Sat, Sep 03, 2022, 2:46 PM UTC

remexre wrote: post #226

solardev wrote: post #211

Earlier quoted context omitted.

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

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.

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.

Re: JavaScript hydration is a workaround, not a solution

#229

Post by weare138 » Sun, Sep 04, 2022, 2:22 AM UTC

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…

Maybe it's because I'm from GenX and from that era but I still don't get why JS frameworks jump through all these hoops just to avoid server-side programming. Why do all these round trip stuff when you could just render it server-side to begin with?

Re: JavaScript hydration is a workaround, not a solution

#230

Post by solardev » Sun, Sep 04, 2022, 4:00 PM UTC

weare138 wrote: post #229

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…

Maybe it's because I'm from GenX and from that era but I still don't get why JS frameworks jump through all these hoops just to avoid server-side programming. Why do all these round trip stuff when you could just render it server-side to begin with?

In large part because HTML was not designed as a "streamable" format. The main benefit of AJAX is that it lets you send information back and forth without needing a whole page refresh.

You don't have to load anything to send a request to the server. But when the server sends a response back, HTML by itself can't do anything with it. Interaction isn't really a part of the language. So Javascript needs to act as the client, and take the information to apply some sort of DOM transformation to the HTML so that the user can actually see the response and further interact with it.

Javascript is what allows HTML to be interactive in real time at the component level. There's a lot more of that these days than in the past.

The frameworks still do the same thing, at a higher level of abstraction and with better debugging and less verbosity and manual labor. They make it much quicker to create and maintain complex compositions of stateful components... if that is meaningless, your page probably doesn't need a framework, but a lot of complex sites today are exactly that (compositions of stateful components)

It's possible that may change in the future, like with the Web Components spec. But for now, once Flash was deprecated, JS is the only tool really available to web devs for this sort of usage. It's not that it's the best choice for an interactive web, it's just what history left us with... flawed, slow, clunky, but popular enough as to be worth the costs.