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

Re: JavaScript hydration is a workaround, not a solution

#81

Post by ClumsyPilot » Thu, Sep 01, 2022, 5:11 PM UTC

phailhaus wrote: post #69

ClumsyPilot wrote: post #35

Earlier quoted context omitted.

You don't think that it's weird that most of the largest, most successfull companies have mountains of office politics? Clearly this means that office politics is good for your company Largest economies in Europe have the oldest and most drafty, poorly insulated housing stock. Therefore shitty housing stock must be good for the economy. Largest economies in the world have the most pollution. Therefore pollution must…

You're arguing that correlation does not imply causation. Fair. So tell me: how would you manage to build a website like Facebook without robust JS tooling? The answer tends to be "wellll I hate most of these features anyways, let's get rid of them and then it can be as simple as HackerNews!" But obviously, millions of people use those features every day and like them. The tooling solves a real problem.

There are industries that use real robust tooling to run banks, build databases, control surgical robots. They don't choose Javascript, it has all the robustness of a wet noodle.

Desktop and Mobile application are reasonably robust, have very complex software and could do everything Facebook does trivially. All this 'robust tooling' has evolved because we are trying to shove an application into a browser, and despite decades of effort. it still kinda sucks.

If Apple, Microsoft and various distributions of Linux pulled the finger out of their collective asses and agreed on a half-decent, cross-platform GUI software package in 2005, none of this JS madness would exist.

Re: JavaScript hydration is a workaround, not a solution

#82

Post by tsimionescu » Thu, Sep 01, 2022, 5:13 PM UTC

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 example, say you wanted a checkbox, but you wanted to use a custom shape (Edit: shape - color is more easily controlled today) instead of the browser default. Well, tough luck. From HTML you'll have to put the checkbox inside a label, add an empty span next to it, and from CSS make the checkbox invisible and then get creative with drawing some boxes that look like a checkbox [0] (or, more realistically, load some custom graphics). So, if you're doing all of this effort anyway, why go through the effort of using the HTML input checkbox at all?

I always find it fascinating just how barebones and bad HTML+CSS is as a GUI framework. I really don't understand why people insist it's in any way superior to using a JS toolkit for anything requiring more than the simplest interaction (say, more than a newspaper article).

[0] https://www.w3schools.com/howto/howto_css_custom_checkbox.as...

Re: JavaScript hydration is a workaround, not a solution

#83

Post by pwinnski » Thu, Sep 01, 2022, 5:17 PM UTC

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…

The initial claim wasn't about load-time, it was about "doing any given task," and I frequently encounter delays when actually using Google Doc, delays I never experience with compiled text editors or spreadsheets.

All that and TextEdit still starts up much more quickly than Google Docs for me.

Your mileage may vary, of course.

Re: JavaScript hydration is a workaround, not a solution

#84

Post by hakre » Thu, Sep 01, 2022, 5:19 PM UTC

erokar wrote: post #15

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…

I agree with you from a technical standpoint — something created for displaying and navigating between documents is being misused for distributing apps. At the same time though none other model affords the same distribution, write once run everywhere. No other distribution platform can compete. And users have become accustomed to the web being apps as well as documents. In fact, many have become accustomed to more or…

It existed in the platform. But Mozilla has lost the first _and_ the second Browser War and has been sentenced to shepherd some "web developer" Wiki and tell everyone how fun that all is.

Yes it can make your day sad, but I'm sure, out there is a crowd that is just amazed by all of it. And its told that the payment was not that bad as well, so we truly only have winners.

Re: JavaScript hydration is a workaround, not a solution

#85

Post by cxr » Thu, Sep 01, 2022, 5:19 PM UTC

notriddle wrote: post #59

cxr wrote: post #47

Earlier quoted context omitted.

> For people not following JS these might all seem like constantly reinventing past lessons, but there is a logical evolution happening here towards desktop-style performance Funny, my desktop itself is already written in JS, and supports/integrates with apps written that way, too, (and also that aren't), and that's been the case for a while now. And the same has been true of apps from the Mozilla platform lineage fo…

> Firefox has been an Electron-style app for 100+% of its lifetime That's technically correct, which is the best kind of correct, but horribly misleading. Firefox has always been mostly written in JavaScript, but not HTML [1]. A bunch of features that are being standardized now, like Web Components [2], are pretty similar to stuff that Firefox has used in non-standard form for decades. [1]: https://en.wikipedia.org/w…

1. Mozilla deprecated XUL a long time ago; it's been a long time since began the transition to favoring HTML over XUL within Firefox.

2. Even if Firefox were still 100% XUL today, it wouldn't matter. The context here is the use of JS as a general applications programming language and a signpost addressing the uninitiated who haven't been "following JS". Whether it's touching DOM nodes that are in the XUL namespace or the (X)HTML one (or whether it involves DOM nodes at all) is orthogonal. Bringing this up is the kind of change of subject that constitutes misdirection.

3. I don't know what you think the role of Web Components being like XBL plays in this conversation, but it strengthens the underlying point; it doesn't weaken it...

Overall, this is a very odd response, to be generous. More accurately, it's horribly misleading to label my comment "technically correct[...] but horribly misleading".

Re: JavaScript hydration is a workaround, not a solution

#86

Post by lhorie » Thu, Sep 01, 2022, 5:27 PM UTC

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 to put together a web UI for displaying a number of reports from some computationally intensive data warehouse query crunching. We're talking visualization of tables and tables full of data. Conventional wisdom would dictate that implementing this the traditional way would involve query optimizations, various layers of caching, separation of concerns, a framework to manage all the complexity, etc, etc, etc. His approach? Just do the naive queries (slow as they were), print directly to HTML old school PHP style, then save the HTML file to disk.

He was a bubbly happy type of guy and you could see the child-like joy on his face when he showed me how lightning fast the thing would load from navigating from one page to another because it was effectively looking at a static website once the pages had been generated once. I distinctly recall feeling a mix of confused feelings at seeing the guy break every rule in the "programming best practices" book and the undeniably good performance results from the sheer dumb simplicity of the solution.

Re: JavaScript hydration is a workaround, not a solution

#87

Post by scrollaway » Thu, Sep 01, 2022, 5:31 PM UTC

zozbot234 wrote: post #17

scrollaway wrote: post #5

Earlier quoted context omitted.

> 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. What's your point here, exactly? That if random wordpress blogs and recipe websites were less wasteful, the problems these solutions are addressing would not exist? I can make you an extremely non-wasteful weba…

HTML has native support for lazy-loading images these days. No need for added JS.

You can lazy-load a lot more than images. In my example, yes I wouldn't use js for it, but it's irrelevant to the point I was making. My read of GGP is that "lazy loading is useless because you shouldn't have so much content that it's needed, ever", which is a bad take.

Re: JavaScript hydration is a workaround, not a solution

#88

Post by cxr » Thu, Sep 01, 2022, 5:31 PM UTC

phailhaus wrote: post #62

cxr wrote: post #36

Earlier quoted context omitted.

> "Web fundamentals" can't give you Google Docs. There's real irony in this statement, since you can't get much more fundamental than that. WorldWideWeb.app (Nexus) was created as a read-write client for both navigating and authoring content. Not only are modern Web apps not a necessary precondition for that, but neither JS nor any form of mobile code are necessary, either. (The thing that Docs does wrong where "fund…

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 to do so by fetching and executing the minified bundle on the Docs site.

Re: JavaScript hydration is a workaround, not a solution

#89

Post by Karellen » Thu, Sep 01, 2022, 5: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…

> For example, say you wanted a checkbox, but you wanted to use a custom color instead of the browser default. Well, tough luck. From HTML you'll have to put the checkbox inside a label, add an empty span next to it, and from CSS make the checkbox invisible and then get creative with drawing some boxes that look like a checkbox [0] (or, more realistically, load some custom graphics). So, if you're doing all of this effort anyway, why go through the effort of using the HTML input checkbox at all?

What the fuck? Just use the actual goddamn checkbox. You can set colors with CSS, but also, it will work in exactly the same way as all the other checkboxes on the user's system. It will respond to keyboard and other input shortcuts the same way as all the other checkboxes they use. It will work with any accessibility devices the user has in the same way as all the other checkboxes they use.

Don't reinvent standard controls just because they're not "customizable" enough. Function is more important than form, and the standard control has a lot more function than you're probably aware of. Also, the user already knows how the one on their system works, because they've already used one hundreds of times.

And the same goes even more so for controls which are more complex than the checkbox. Which is, uh... checks notes... all of them.

Just stop.

Re: JavaScript hydration is a workaround, not a solution

#90

Post by HeyImAlex » Thu, Sep 01, 2022, 5:34 PM UTC

ClumsyPilot wrote: post #81

phailhaus wrote: post #69

Earlier quoted context omitted.

You're arguing that correlation does not imply causation. Fair. So tell me: how would you manage to build a website like Facebook without robust JS tooling? The answer tends to be "wellll I hate most of these features anyways, let's get rid of them and then it can be as simple as HackerNews!" But obviously, millions of people use those features every day and like them. The tooling solves a real problem.

There are industries that use real robust tooling to run banks, build databases, control surgical robots. They don't choose Javascript, it has all the robustness of a wet noodle. Desktop and Mobile application are reasonably robust, have very complex software and could do everything Facebook does trivially. All this 'robust tooling' has evolved because we are trying to shove an application into a browser, and despite…

Ah can’t wait to finally build a cross platform app without complex JS tooling once I take my time machine back to 2005 and change the course of cross platform GUI development forever.