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

Re: JavaScript hydration is a workaround, not a solution

#91

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

Karellen wrote: post #89

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…

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

> And the same goes even more so for controls which are more complex than the checkbox.

HTML has a lot of virtually useless controls due to their limited styling. And yeah, sometimes you want custom-looking checkboxes, because you just fucking do and design matters. Also, on some browsers, checkboxes don't even have the lauded accessibility you're thinking about -- I recall a time where zooming in in Chrome wouldn't change the size of checkboxes!

Those aren't even the most egregious examples, to be honest.

Re: JavaScript hydration is a workaround, not a solution

#92

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

> cross-platform GUI software package

And cross-platform APIs, cross-platform libc, cross-platform networking... and then the same shuffle on mobile, making sure everything is compatible? Supporting x86 and ARM?

The web does suck, there's no getting around that. HTML and the DOM are garbage even at their original purpose, let alone at writing applications, and everything on top of that is a kludge on a kludge on a kludge.

But let's not pretend dealing with OS APIs from the 90s is much better. We've been trying to get away from that as early as we could with e.g. Java.

Re: JavaScript hydration is a workaround, not a solution

#93

Post by dntrkv » Thu, Sep 01, 2022, 5:40 PM UTC

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…

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.

Re: JavaScript hydration is a workaround, not a solution

#94

Post by notriddle » Thu, Sep 01, 2022, 5:42 PM UTC

cxr wrote: post #85

notriddle wrote: post #59

Earlier quoted context omitted.

> 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 point is that "JavaScript Applications" aren't just written with JavaScript, and so-called "JS frameworks" really aren't doing much with JavaScript (except, I suppose, JSX).

Mostly, they're DOM enhancers, and Firefox has always been coded against its own internally-maintained, enhanced version of the DOM.

Re: JavaScript hydration is a workaround, not a solution

#95

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

Lots of "robust" industries choose the JS ecosystem.

I work in Fintech. There's a lot of tooling to make JS-as-a-language more robust, including TypeScript and some of the best linters, debuggers and introspective libraries available in the entire tech industry.

The only reason JS isn't used more than it is, is because its robustness is young, not non-existent.

Re: JavaScript hydration is a workaround, not a solution

#96

Post by efields » Thu, Sep 01, 2022, 5:49 PM UTC

Incoming rant: I’ve had to do more hands-on hydration work as I explore static site generators and I’m just deeply unhappy with the state of front end tooling. I now have a taste for

* directory based routing and opinionated defaults that give you the basics to string together html pages with reusable partials and be production ready in minutes (think rails)

* postcss (css tooling)

* reusable and compostable components

* hmr-style dx

* serverside generated pages, as inlined as possible — fastest experience for end user, avoids js if not needed

* not having to think how and where css or images get compiled

Vitejs looked headed that way but recenty dove into it and… it ain’t it yet. Getting something to render on a server then “turn on” with react in the browser is not straightforward.

Remember how much sense $(document).ready() made? Hydration should be that easy and it is not.

Re: JavaScript hydration is a workaround, not a solution

#97

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

Karellen wrote: post #89

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…

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

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 - certainly not Firefox on the Android phone I'm typing this from, nor the Windows box IT wants me to use for work, nor the Linux VM running inside that.

Especially for web apps, writing them so that they look good on every browser with default styling for every element is... Difficult.

Not to mention, users often use the same app from different browsers (laptop, phone, tablet), and are much more easily confused by the different styles of each device and browser than if the app itself is consistent, but different from other apps.

Edit to add: I'm very curious if you can find some major sites that do actually use the default checkbox controls - Google doesn't, YouTube doesn't, Apple doesn't, Wikipedia doesn't, Mozilla doesn't (though I did find a default radio button on their donate page), Microsoft doesn't. Even HN uses plenty of default controls, but still you'll see some custom controls, such as the upvote/downvote buttons.

Re: JavaScript hydration is a workaround, not a solution

#98

Post by Karellen » Thu, Sep 01, 2022, 5:53 PM UTC

scrollaway wrote: post #91

Karellen wrote: post #89

Earlier quoted context omitted.

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

> And the same goes even more so for controls which are more complex than the checkbox. HTML has a lot of virtually useless controls due to their limited styling. And yeah, sometimes you want custom-looking checkboxes, because you just fucking do and design matters . Also, on some browsers, checkboxes don't even have the lauded accessibility you're thinking about -- I recall a time where zooming in in Chrome wouldn't…

> Also, on some browsers, checkboxes don't even have the lauded accessibility you're thinking about

In which case, people with accessibility needs won't be using that browser. And that's the whole point. The user can pick whichever browser works best for them, and implements the standard controls in the way they want. (Or, in the way that sucks the least, out of the browsers available to them.) And if they decide to get a better browser (different engine, or even just a major upgrade to the current one) suddenly all their websites work better. More importantly, they all work better in exactly the same way, so they only have to get used to any differences once, rather than for each and every website.

If you go and write your own version of a standard control which implements it that way you want, you take that away from the user.

HTML allows you to specify the semantics of the controls you want, and have the user-agent bother with the details about how it works. That's going to be more lightweight, more performant, and more user-friendly for more people than any alternative you bodge together yourself.

Re: JavaScript hydration is a workaround, not a solution

#99

Post by c0nfused » Thu, Sep 01, 2022, 5:54 PM UTC

scrollaway wrote: post #91

Karellen wrote: post #89

Earlier quoted context omitted.

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

> And the same goes even more so for controls which are more complex than the checkbox. HTML has a lot of virtually useless controls due to their limited styling. And yeah, sometimes you want custom-looking checkboxes, because you just fucking do and design matters . Also, on some browsers, checkboxes don't even have the lauded accessibility you're thinking about -- I recall a time where zooming in in Chrome wouldn't…

The best thing about using standard controls for things in that as things get better. You get it for free. The zoom bug gets fixed.

I have a bunch of legacy custom controls I deal with regularly because things like color pickers were not cool enough in 2009. The down side is that in 2022 they regularly break and require dev time to fix so some report that gets run once a year works correctly.

Re: JavaScript hydration is a workaround, not a solution

#100

Post by grey-area » Thu, Sep 01, 2022, 6:10 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.

<contenteditable