JavaScript hydration is a workaround, not a solution

https://thenewstack.io/javascript-hydration-is-a-workaround-not-a-solution/

by fagnerbrack • 4 years ago

172 231 4 years ago

aliqot2• 4 years ago

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 place without all the toolchain and shenanigans. We must return to fundamentals.

guipsp2• 4 years ago

I thoroughly agree, society was much better before computers came along.

xjose97x• 4 years ago

Can't tell if this is is a joke or not lol

mikepurvis• 4 years ago

Whoa whoa whoa, let's not get carried away. The peak of technology obviously occurred in $YEAR_AUTHOR_GRADUATED_UNIVERSITY and it's all been downhill from there.

jozzy-james12• 4 years ago

agreed, wouldn't be able to read this comment

scrollaway4• 4 years ago

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 webapp which still needs to display a hundred images on a page (because reasons), so lazy-loading the images is still important.

I can find you a very well-optimized website that is only a few kilobytes, but still loads slow as shit because their network is bad and I'm on a terrible 3G link. FOUC would still be an issue.

zozbot2343• 4 years ago

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

quest88• 4 years ago

I think the point is people should use the correct tool for the job. Instead, sites that should (or can) be static sites are unnecessarily using some JS framework.

jozzy-james12• 4 years ago

FOUC would still be an issue.

hell, just using webfonts can cause FOUC - no JS needed.

intothemild• 4 years ago

Developers, just coding their websites, not a toolchain in sight.

qsort2• 4 years ago

You're not wrong, the websites I enjoy the most are basically all static.

I think the problem is that the "web fundamentals" aren't that good to begin with. A web application is very often the least bad solution, but you're not going to have "rich" web applications without tons of JS. Show the average user HN and they won't like the interface.

SketchySeaBeast• 4 years ago

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.

tmnvix• 4 years ago

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'.

phailhaus6• 4 years ago

"Am I out of touch? No, it is the children who are wrong."

This is an old, tired take that boils down to "we should be ashamed for wanting nice things." If only everyone would just accept simple websites like HackerNews! This is backwards, it is user-blaming. It turns out that the web is an incredible platform that has revolutionized the world, and thousands of people have worked hard to build tools that make it easier to develop on. "Web fundamentals" can't give you Google Docs.

morelisp2• 4 years ago

Users don't want this shit, startups do.

cxr8• 4 years ago

"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 "fundamentals" are concerned is its de-emphasis on the importance/role of the URL and making every Docs doc a sort of second-class publication that exists in this "other" kind of space—i.e., Google Drive and the Docs editor, which you always get a sense of being "inside", instead of the content just being out there on the Web.)

jokethrowaway2• 4 years ago

You can have simple websites without them being ugly

waboremo• 4 years ago

Do you have any proposed solutions for the problems that exist? Going back to fundamentals doesn't eradicate the problems, it will only recreate them in a slightly altered state.

One of the most commonly proposed solutions is we keep the web to only static content. Well now we've just shifted all the media-heavy interactive content onto a dedicated app instead of the browser, shifting all the same exact problems onto a new platform instead.

joshmanders2• 4 years ago

Well now we've just shifted all the media-heavy interactive content onto a dedicated app instead of the browser

And then they complain because "This could have just been a PWA, why do I have to install an app for every website I use!?"

erokar• 4 years ago

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 less treating their web browser as an OS (or more realistically, not giving the distinction any thought).

Maybe an interesting way forward could be a web model specifically for apps, which of course many would say would be WebAssembly. The HTML/CSS/JS combo has been remarkably successful and resilient though, so I'm not convinced it will be dethroned easily.

hakre2• 4 years ago

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.

sopooneo• 4 years ago

I remember when HTML5 and CSS3 were just in the RFC phase and many web developers thought they would make their jobs simpler. Because the things they were being asked to do, for which they were currently creating tortured workarounds, could be done directly with the new standards.

But of course the job did not become simpler. The fixed value turned out not to be what clients would demand, but the quantity of tortured workarounds devs could be enticed to endure.

hypertele-Xii• 4 years ago

Almost got back into webdev but the technical interview was 100% JavaScript.

mattwad• 4 years ago

I'll be an anecdote: I literally only came back because of CSS3 and jQuery. Managing layout with tables and all hover effects with javascript did not sound like a fun career choice when I first started. And now I've fully embraced flexbox and grid and styled components - I rarely have to think about classes anymore. New tools have been making my job a lot more fun over the years.

swatcoder2• 4 years ago

My boots are pretty dusty too, and a web browser isn’t usually how I usually want to engage with a tool or toy.

But the systems architecture model of infinitely beefy backends with simply-adequate thin clients predates both of us. Browsers, the cloud, and all this obnoxious javascript tooling are the contemporary implementation of that and not without reason. They do it pretty well!

Like with any new tool, people get carried away and start using it for things that really don’t need it. I’m with you that most websites don’t need all this stuff and get caught up in it anyway.

But that’ll burn off, and in the meantime, we’ll end up with a rich, mature thin client system for the solutions that need it and that system will be around for decades. No sharks jumped.

hakre2• 4 years ago

Browsers of today are begging so much for new clothes, they ain't browsers anymore. Gib dem Affen Zucker.

cxr8• 4 years ago

but Javascript jumped the shark at some point

Contemporary frontend, in-browser app development, you mean. JS is a programming language. By conflating a language with a particular culture of software development, you implicitly transfer more power to that culture, the people in it, and their practices, even though your message expresses a clear desire for the opposite.

pier255• 4 years ago

The core issue is that browsers were not made to provide the sophisticated features we require these days. Because of this fundamental problem, you can't build something like Gmail or Spotify without increasing the complexity of development exponentially.

The "SSR + sprinkled JS" paradigm is still totally valid though for many use cases.

wruza2• 4 years ago

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.

maest• 4 years ago

Clicking on the builder.io link redirects me to:

https://uc.appengine.google.com/_ah/conflogin?state=%7E...

which says:

    An application is requesting permission to access your Google Account.
    Please select an account that you would like to use.

EDIT: you can see it if you go to http://builder.io (https works fine)

dmix3• 4 years ago

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 sub-links and stored offline-first like a desktop app, so clicking on anything loads immediately w/o waiting for network requests to finish

- Now with 'resumability' where the server-side framework was built with client hydration in mind and delivers the bare minimum event/DOM data necessary to make the page interactive (instead of just being a glorified HTML cache load before the usual JS activates)

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 and interactivity on the web. Or pure server-side performance but with full JS interactivity.

The next set of frameworks is going to be as big of an evolution the way Angular/Backbone->React/Vue was ~8yrs ago. But it's going to require new backend server frameworks, not just a new client framework. There's probably a big opportunity for the project that can combine this stuff properly.

BeefWellington7• 4 years ago

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 evolution happening here towards desktop-style performance and interactivity on the web. Or pure server-side performance but with full JS interactivity.

For people following JS these are examples of constantly relearning past lessons. I'm not sure how anyone could reliably expect 100+ms round-trip time (on a good connection) to offer the same experience as something local but I think what it actually means is that the people writing JS-based software haven't actually used a native desktop app for years and have done mostly web-based things.

You could be forgiven it since HTML/JS as a user interface design language appears to have taken over completely, to the point where even the most popular code editors are now web browser-based.

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 griping aside, I recognize JS as a language is here to stay and it's important to stay on top of its developments and improvements.

acover• 4 years ago

I find myself hating visual studios lag but okay with visual studio code.

Maybe visual studio isn't getting attention but it's painful to use.

dmix3• 4 years ago

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 comparing the current era of React/electron apps (or even most Next.js apps) of course you're not going to see Desktop-type speeds yet... these new developments are closing the gap but it's only just starting to be adopted.

tln• 4 years ago

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 SimpleNote (which is blazing fast!)

Google Meet loads faster than Zoom

For VS code, it creates a whole new chromium process, but for websites like quicknote.io, do you count the browser base usage and loading time? Or just the incremental time to load up in a new tab?

yamtaddle• 4 years ago

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.

The high power use is what kills me. That and input lag. Fix those and I'd give way fewer shits that an Electron app eats 10x the memory that's remotely justifiable by what it's doing, and more like 20-100x what a well-made desktop program would for the same purpose.

[EDIT] Yeah, I know, high power use and input lag are in part because Webtech disrespects things like system memory, so in practice I'm not going to see one fixed without the other.

woojoo6662• 4 years ago

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

thethirdone2• 4 years ago

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 environment is fine, but deluding yourself into thinking that its great performance is not.

qudat2• 4 years ago

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.

doix• 4 years ago

The things you have listed minimize the impact of network latency, they don't affect the rendering performance which is still a big deal. Apps that need to render large amounts of data still kind of suck, you'll see many apps "virtualize" things. So rather than having 10,000 elements, you have however many fit in your viewport + N and as you scroll they get reused. The tearing hurts my soul.

Compare the scrolling in Excel 97 + Windows NT to Google Sheets/Office 365. It's night and day. The webapps that render everything with WebGL do preform better, but then you have non-native widgets.

I hope this problem gets solved one day.

madeofpalk• 4 years ago

Native OS widgets virtualize large lists as well. Some do it better than others.

lewisl9029• 4 years ago

In my experience, time-slicing and deferring renders for large lists (via APIs like useDeferredValue and/or requestIdleCallback, etc), combined with memoization can be a great alternative to virtualization.

For a lot of use cases where people jump straight to virtualization, it's not actually the number of elements that exist in the DOM at once that's the problem (React and browsers these days can handle a lot more than what's intuitive to most people). The problem is usually the cost of rendering all those elements at once in the initial mount, which often can cause visible frame drops and even noticeable freezes of the page.

Deferred rendering and time slicing can amortize this cost over a longer period of time while providing essentially the same UX (by eagerly rendering the first X # of items in a list), while memoization can keep transitions to new states fast by reusing the same large list of nodes when it hasn't changed. All of these techniques combined is still orders of magnitudes less complexity and requires fewer UX compromises (tearing, loss of browser search, etc) compared to virtualization, which should be reserved only for cases where there is no other workable solution IMO.

cxr8• 4 years ago

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 for even longer; Firefox has been an Electron-style app for 100+% of its lifetime, for example. Talk to any self-styled JS programmer for any length of time, though, and it's like these things don't even exist—like the latter was actually invented by the Electron folks, and the only thing that made JS development viable generally as a serious applications programming language is the trio of NPM+Webpack+React/React-alikes.

It's overall not worth taking their opinions at face value. They tend to be the ones who are "not following JS". They're worshipping some weird toolchain cult and calling it JS. Indeed, judging by the compulsion to try to work around ostensible deficiencies in the language and deal in cargo cult advice (esp. e.g. concerning things like `==`/`===` and `this`, and insisting on NodeJS-isms like its non-standard `requires`) it's evident that they actually hate JS, despite what they're likely to say to the contrary.

notriddle2• 4 years ago

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/wiki/XUL

[2] https://briangrinstead.com/blog/firefox-webcomponents/

silasb• 4 years ago

You did a good job summarizing the frontend framework evolution, but I'm curious where you think the evolution in backend frameworks are going? I was thinking LiveView, but I also think WASM could come into play as well.

lelanthran• 4 years ago

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?

Existenceblinks5• 4 years ago

Ruby, Go, Rust, Python, PHP, Elixir folks rolling eyes. The next web framework will not be limited to only one language and these coupling paradigm.

samwillis• 4 years ago

While I think the "resumability" that Builder have developed for Qwik is very clever, I increasingly prefer the approach taken by HTMX and Alpine.js. Move back from JSON apis and render your html fragments on the server (you need to anyway!). It removes so much duplication of logic, simplifies your tool stack and reduces your risk of vulnerabilities.

I would even be tempted to say, both "Hydration" and "Resumability" are workarounds.

Attaching your event handlers to the DOM via HTML attributes rendered on the server à la HTMX, Alpine.js or god forbid even 'on{event}=""' attributes removes so much of this complexity.

There will however always be places for client side html rendering though, the closer your webpage becomes to being an "App" the more likely you will need to do client side rendering, especially if you want to work offline.

AngeloR• 4 years ago

I haven't dug into Alpine.js, but I've been messing with HTMX on some personal projects for a few months now and am really pleased with it. It's honestly made it a pleasure for me to return to front-end work.

graboid2• 4 years ago

I just had to do a site which involved a fair amount of interactivity. A sidebar with different types of filters, a search bar at the top, and a complex boolean filter builder inside a modal (think like infinitely-nestable AND/OR filters, where each filter involved 5 dropdowns interacting with each other). Then some area to collect the results and do some operations on them. I was feeling brave and decided to skip Vue which we otherwise use for complex UIs and do the whole page with HTMX and nothing else. And it worked.

It took me longer, thats for sure, but also because I had to get a feeling for how to approach many things I would have just routinely plumbed together with Vue. And the feeling at the end was really satisfying, a fast-loading, complex interactive page, powered by ~10kb of Javascript, with all filtering logic, validation etc. completely server-side (we use ASP.net). And I have confidence it will work exactly as it is years from now. With our Javascript tooling, I expect things to break by that time.

That said, I certainly pushed the library in parts, and the vote is still out on how easy it will be to understand the flow of interaction if some time has passed.

yuretz• 4 years ago

Just curious, if it's pure htmx, doesn't this mean that most of UI interactive actions do a roundtrip to the server to update the app state? Or have you used hyperscript for some parts?

the__alchemist• 4 years ago

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-latency low. Modern JS is good enough for this purpose without the webpack/VDOM/bundling/dependencies that have made many websites sluggish.

commandlinefan• 4 years ago

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 actually worked, and somebody else comes along and adds back the things that were already in the original solution on top of the hacks so that it works the way it always worked, but much slower and in a way that will break in surprising ways when you least expect it.

spion2• 4 years ago

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.

pwdisswordfish0• 4 years ago

I thought that was called "progressive enhancement". I like that too

robertoandred• 4 years ago

Their definition is wrong. Hydration takes static HTML and replaces it with client-rendered HTML.

Existenceblinks5• 4 years ago

Yep, some duplicated templates where they need to be is dead simple and cheap. I've been thinking about this for many years and still think that is by far the best.

onion2k2• 4 years ago

...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 bonfire.

Hydration is an example of this. People chased 'first contentful paint' and 'cumulative layout shift' timings because that's what Google told everyone they needed to optimize for. That meant reducing the amount of upfront work done in JS, pushing some barebones HTML and CSS to the client for those sweet, sweet metrics, and then running a massive bundle of deferred JS to make it do anything. Google is pulling that rug with Time to Interactive, First Input Delay and (coming soon) Interaction to Next Paint, so now devs are trying to write the same website but have the server strip out the code they wrote (eg Remix.run).

Everyone wants a fast website. No one wants a heap of fragile complex build tooling. The answer to the first problem is to stop trying to solve the second problem with MORE TECH. Go back to fundamentals. 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.

michaelchisari• 4 years ago

Simplicity is almost always best, but the hardest part is pushing back on management and product that often only care whether feature requests are possible and aren't as concerned with what goes on under the hood.

jeffy90• 4 years ago

Speed and uptime are also features. If customers like speed/uptime (they do) we need to make sure management prioritizes them and understands how certain features will work against speed/uptime.

galaxyLogic• 4 years ago

Cool-looking things appeal to customers, and also to developers.

It's a bit like your car. It takes you from place to place and could drive much faster than speed-limits or traffic-jams allow. But getting from place to place is not all you want. You want to pay extra for the coolest looking fastest wheels you can afford.

When you work with an app or app-development tool that looks cool your self-image improves. You are a cool dude because you work with a cool-looking application. Seriously, it does have an effect on me.

andrewmcwatters2• 4 years ago

If you try and tell inexperienced employees this in an interview for a job when you have well over a decade or more of experience—you’re not getting the job.

I agree with you, but there’s some sort of complexity agreement in corporate environments, because people aren’t willing to accept that you don’t need a large build process, or any at all these days, maybe outside of a build pass for JSX.

azangru• 4 years ago

If you try and tell inexperienced employees this in an interview for a job when you have well over a decade or more of experience—you’re not getting the job.

Good. An interview is as much you assessing your potential employer as your potential employer assessing you.

pupppet• 4 years ago

I've had clients and self-professed SEO gurus carve out useful content in order to chase that 100 pagespeed score. I wish Google would just come out and state how content vs speed is weighted.

user3939382• 4 years ago

diceduckmonk2• 4 years ago

Time to Interactive, First Input Delay and (coming soon) Interaction to Next Paint

Having worked on one of the most bloated SPAs at Google and doing an SRE rotation to optimize exactly these metrics, I couldn’t agree more on the hypothesis that this is where complexity, jank and fragility arises.

This is why our startup set out to build the best-in-class frontend for cloud computing and making a bet on SSR. I’m from a JavaScript background and personally think hate for the language is undue. V8 is also a marvel of engineering. We elected Go for our application language. It’s faster for our purposes but with SSR the domain language isn’t as important. We could use Haskell if it was fit for the problem domain. We empathize with how ideas such as “user-perceived latency” came about but SSR is a much simpler model and our philosophy is that “simpler is faster is faster”.

boredtofears• 4 years ago

What is SSR exactly in the context that you're describing?

I thought if you're using server side rendering you'd be serving HTML directly from your application.

strongpigeon• 4 years ago

Having worked on one of the most bloated SPAs at Google [...]

Let me guess. Google Ads?

tsimionescu5• 4 years ago

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

Karellen3• 4 years ago

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.

likortera2• 4 years ago

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?

lhorie• 4 years ago

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.

dntrkv2• 4 years ago

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.

jollyllama• 4 years ago

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

cultofmetatron• 4 years ago

If the data doesn't change often and there's no further changes on the data after its created, seems perfectly valid. Optimizing queries takes time; in some cases, building new tables for amortizing parts of the computation. And of often you don't know whats worth optimizing till later so its easy to spend a lot of time optimizing the wrong thing.

I mean he basically cached the results for viewing later. As cringy as it seems, it was probably the optimal solution.

personally, I would have probably built out a materialized view and added memcache to generate json to make it easier to refactor additional output formats over time but that's just me. It still wouldn't have loaded as fast as sending a pre-generated html file.

solardev9• 4 years ago

Hey, he basically invented pre-Cloudflare Cloudflare!

(one of their caching solutions -- which works very well, actually -- is to just cache the slow PHP output of many sites and serve the HTML directly)

RickHull• 4 years ago

https://htmx.org/

wruza2• 4 years ago

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.

dmitriid• 4 years ago

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

paulirish• 4 years ago

Speaking as the TL of Lighthouse and PageSpeed, I can comfortably say that adding complexity is antithetical to our goal. Quality UX and a reliably performant web is what we want for all users.

Ideally, folks would use a thinner stack with _less_ JS, as that's rewarded across all the metrics. But in recent years, many teams build a "site" by building a SPA. As they're entrenched in that dubious decision, the only path to making it performant is adding SSR complexity. ¯\_(ツ)_/¯ Perhaps its the apparent conflict between UX and DX that leads to tooling complexity?

And to nitpick: Core Web Vitals debuted with 3 metrics, one of them being FID. The focus on runtime/JS performance has been there from the start. Regardless, I hard agree on your last paragraph.

solardev9• 4 years ago

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?

FalconSensei2• 4 years ago

Perhaps its the apparent conflict between UX and DX that leads to tooling complexity?

+ PMs wanting to run dozens of AB tests at once in every single page

yawaramin• 4 years ago

It's ironic of Google to try to drive web performance when websites are full of Google Analytics scripts. Like the fox guarding the henhouse ;-)

yazaddaruvala• 4 years ago

Perhaps its the apparent conflict between UX and DX that leads to tooling complexity?

In theory improved DX leads to improved UX. In practice, subpar/lazy tooling needs to be worked around to get better DX.

I’ve added a lot of JS weight to migrate legacy apps to React always improving time to interactive and responsive error handling/messaging. Vanilla JS and even Jquery just don’t have the DX that allows them to scale in a corporate context (specifically because of under experienced engineers and poor “due dates”).

IMO it’s a lack of initiative from browser developers to move the web forward faster (obvious given the funding comes roughly exclusively from the developers of iOS and Android). I understand the inertia of legacy browsers, but it should not take decades to eliminate the need for these DX polyfills (eg like Jquery took to become redundant, and how long it’s taking React/Vue/Svelte style components).

solardev9• 4 years ago

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 feel like "don't use tooling/frameworks" is the web dev version of "you don't need Java or .NET or WPF or WinForms, just use assembly and gfx drivers and draw pixels on the screen". HTML and ECMAscript evolve very slowly relative to the needs of software businesses, and it would take 30x (if not 300x) as long to write complex apps in those alone. Having a "build and bundle" step is just the webdev version of compiling developer-friendly code (React and frameworks) into the "lowest common denominator" code of browser-parseable HTML + JS.

It's not about "cleverness", but being able to do your job in a reasonable amount of time and effort, vs going back to a 90s-style internet where every page is basically a dumb terminal and all the actual interactivity has to happen on the backend.

I think is a better option is to know your target audience, their expected device and connection speed (metro desktop? rural mobile?) and not to worry about over-optimization. Nobody cares if your website loads in a second if it's so hard to use that it takes THEM more time to do what they need. Better to take 5 seconds to load, and then be actually usable as an app.

FWIW I don't think web apps are getting slower because developers are getting worse, but because the newer frameworks are enabling new use cases that weren't before possible. Photo editing? You used to have to download and install Photoshop, which can take minutes or days depending on your network and connection. Now you can run Photopea in a browser window in a few seconds and do most of the same things.

As for core web vitals? It's not a bad thing to use a performance arms race to get websites to be faster. It forces frameworks to evolve their delivery, caching, loading, hydration mechanisms. But that doesn't have to mean "give up on frameworks and complex apps". It can also just mean keep up with their latest performance improvements, and/or hope that ECMAscript evolves faster, that things like Web Components or PWAs etc. become more commonplace.

fleddr2• 4 years ago

The examples you give are a 100% fit for the SPA model. Nobody would build Google Docs or a game from server-side HTML.

That's not the discussion. The discussion is everything except that. The typical example being a CRUD app. A bunch of cards, filters on the left, search box on top, logged in user. It usually isn't much more than that. Which means its low state and lowly interactive.

zozbot2343• 4 years ago

Having a "build and bundle" step is just the webdev version of compiling developer-friendly code (React and frameworks) into the "lowest common denominator" code of browser-parseable HTML + JS.

One problem is that for all the building and bundling webdevs do, only a few very recent frameworks (Svelte and SolidJS) can even manage to compile into something that even approximates "plain vanilla", progressively-enhanced JS on the client. And use of these is still the exception rather than the rule.

onion2k2• 4 years ago

And what do you do for more complex, stateful apps?

To quote Albert Einstein, "Make everything as simple as possible, but not simpler."

This applies as much to your JavaScript bundler configuration as it does to the origins of the universe. It's not surprising really, because if I say "an instantaneous explosion that causes the entire universe to be filled with matter" you don't know if I'm talking about the Big Bang or Webpack.

weare138• 4 years ago

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?

ratorx• 4 years ago

Frontend frameworks often have better developer experience. I want to use one because it’s less annoying to do thing like template HTML with editor completions, than using HTML.

Another theoretical advantage is that you can get better colocation of content, style and functionality.

Basic JS is pretty annoying to write. It reminds me of using goto for control flow. It’s a lot cleaner to be able to put functionality alongside the document structure.

Of course, you can use HTML + CSS + JS but you can also use Assembly for all code. But the end solution here is not Frontend frameworks.

I think it’s time browsers give us a better abstraction to HTML + CSS + JS. Webassembly and friends are nice, but I think the 3 fundamentally need to be replaced together in a performant way such that the simple case of no client side code is well optimised. Frontend frameworks are just a symptom of the problem which is that Web devs have to use the only abstraction creation mechanism available to get nicer development properties.

qudat2• 4 years ago

Frontend frameworks often have better developer experience. I want to use one because it’s less annoying to do thing like template HTML with editor completions, than using HTML.

Agreed. As I've been developing a service (https://prose.sh) with no javascript and only go templates, the biggest downside is autocomplete.

bot41• 4 years ago

Just make something that works with with HTML and CSS alone, and enhance it with JS

If you do this and have a sufficiently complex application... you will end up where the modern frameworks are. They exist for a reason.

zemnmez• 4 years ago

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

likortera2• 4 years ago

Meanwhile I'm having a ton of fun (and better metrics) by just rendering html from the server and using Unpoly for interactivity and "old style ajax" dynamic updates. And still building the entire application in JavaScript, end to end.

lucideer• 4 years ago

While the points against hydration are valid, the proposed solution sounds to me like it would have other (opposite) performance problems:

i.e. hydration has an inherent startup overhead, and possibly a continuing memory overhead (though the latter doesn't seem inherent), whereas resumable sounds like it may start fast, run slow (and I can't see where they solve the mentioned memory overhead problem).

I haven't tested this myself so since they have some Qwik demos linked I gave them a try. Anecdotally, startup seems very slow in them. I thought this was meant to be the problem being solved. Maybe the component download is fast but the framework download/parse is the slow part?

Either way, none of the examples are complex or interactive enough to properly test ui latency so I don't know.

jbreckmckye• 4 years ago

No! That's not how it is. The way it is, is

- every app more complex than how I like to do things, is an overengineered mess

- every app less complex than how I like to do things, is an offensive relic from the distant past

RestlessAPI• 4 years ago

Guys, multiple things can be true at the same time.

1. Webapps are largely overloaded and dont need to be as huge/complicated as they are.

2. Webapps are an objective computing miracle that brings full app functionality to tech illiterate people that is platform agnostic, everywhere on the planet, and thus most of their complexity is justified.

3. Performance for performance sake is never a hill to die on as it always leads to increasing complexity.

4. Performance when performance matters, is invaluable, and you should be prepared to make dramatic concessions for it.

5. Chasing metrics where the value is not something you easily understand, is usually never worth it.

6. Chasing metrics whose value is obvious (for example, PageSpeed) is worth it.

When websites should be static, they should be static. When webapps should be webapps, they should be webapps.

Software is a tool. A means to an end. Getting hung up on things like this isnt worth it. Just focus on delivering value to your users, and making it a good experience. Sometimes thats best achieved through a static website, sometimes its through a webapp.

jozzy-james12• 4 years ago

and when websites are kind of apps, but not really so you need the SEO benefits of regular websites yet the interaction of apps....then you get into the fun bits

DrFell• 4 years ago

SSR is a hack, not an architecture.

firasd• 4 years ago

Anyone tried Phoenix Liveview recently? Seems like a solution to opt out of this kind of situation entirely.. I'll be exploring the framework

jozzy-james12• 4 years ago

liveview still uses JS, its just rather out of the way in what it does

edit: livewire in laravel land does a similar approach - tho not as fast currently, leverages alpine.js under the hood

chrismccord• 4 years ago

While we use JS and websockets, even with js disabled or curling the page will send all the HTML. So the initial render is strictly a regular html page with all your expected content.

beebeepka• 4 years ago

I've been trying to stay away from doing public facing web apps for a decade, so, from my point of view, hydration doesn't make any sense.

Authorization is in the browser, meaning I get to serve the login page "real fast".

That said, I get the reasons people do it, but frankly, it doesn't sit well with me. It's guaranteed that the whole process is unreasonably complicated as opposed to serving a few static files that can be cached and everything.

I'm theory, it could benefit people browsing without JS but I am not sure if things work out this way. Do next next require js on the client to display whatever was "rendered" on the ui server?

jessaustin• 4 years ago

Authorization is in the browser...

I'm probably missing some details, but this seems like a Bad Idea.

jozzy-james12• 4 years ago

realistically speaking, if done correctly - SSR would allow the site to work without JS. Now, in practice, that comes down to what is required on the client side for interactivity - which is a case by case basis, and if your site doesn't require JS on the FE at all, why would you use it for the backend

oblak• 4 years ago

Yeah, but at the same time, who the hell would use nuxt/next for the type of site that is perfectly usable without js.

epolanski2• 4 years ago

You can still cache ssr websites and render them only once.

togaen• 4 years ago

Burn it all down. Just stop using JavaScript.

pier255• 4 years ago

Good luck using even a barebones site like HN without JavaScript.

nicklaf• 4 years ago

HN works fine without JS!

That being said, the third-party search service it uses does not.

efields• 4 years ago

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.

bern4444• 4 years ago

Take a look at remix.run. It has most of what you list and the rest can be easily added on.

Existenceblinks5• 4 years ago

Judging from the landing page, it's not any way close to `$(document).ready()` as parent said.

dmjio• 4 years ago

Miso has hydration w/ a global event event handler.

https://haskell-miso.org/

pier255• 4 years ago

Misko is right of course, but it remains to be seen if Qwik will be everything it promises to be.

cutler• 4 years ago

Of all the terms in tech "hydration" makes me cringe the most.

thenoblesquid• 4 years ago

Have you not heard of the new programming language that's gaining traction? Moist

Karellen3• 4 years ago

Any idea what the origin of the term is? And why "progressive hydration" was needed over the pre-existing term "progressive enhancement"? I can't figure out what's different about "progressive hydration" that the old term didn't cover.

rglover2• 4 years ago

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 696ms to a full load.

Here's the SSR I do:

https://github.com/cheatcode/joystick/blob/development/node/...

Here's the mount ("hydration"):

https://github.com/cheatcode/joystick/blob/development/ui/sr...

The only "magic" is that I embed the hydration logic into the built JS for the current page and it fires automatically on load (no need to add manual hydration code).

[1] https://github.com/cheatcode/joystick

jstanley• 4 years ago

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

rglover2• 4 years ago

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.

simonbarker87• 4 years ago

I started in web dev 17 years ago, but didn’t get my first professional dev job until 3 years ago.

I had never had to learn angular, react, separated backend and frontend when writing code for my own stuff and my own company.

I would regularly process as much as I could on the server and ship the HTML and a JSON object to the browser and then just use native JS or more SSR from there.

My sites and apps were complex, just as complex as the stuff we were making in my first two dev jobs but the dev ex was so much nicer.

Shipping a heap of JS to the browser and getting that to do the heavy lifting of making the HTML etc just felt like an anti pattern but I went with it because “that’s the way we do it now”

Seeing Remix, Laravel, RoR still going, Astro etc is starting to convince me that perhaps separated FE and API isn’t the one true way and the old way might have been better.

fwip• 4 years ago

I'm not sure if this is reflective of a normal Qwik project, but in the TODO app, javascript fragments are not even downloaded until the event fires, which adds a very noticeable latency.

e.g: on first click (to check off a TODO item), my browser went and fetched q-6642ef59.js, which has the below contents and in turn caused the fetch of two other javascript fragments, which in turn caused a fetch of two more.

    import{d as o}from"./q-dd8cb722.js";import{t}from"./q-3d9b01e7.js";const s=o((({item:o,todos:s})=>t(s,o)));export{s as Item_onRender_on_click};

Looking at the network tab, this took a full quarter-second to finish fetching on my Macbook on fast office internet. They cite "50 ms to ready for interaction" for this demo app, but it's really 300ms until the the interaction begins.

Perhaps judicious use of preloading javascript and/or CSS animations could hide this from a user, but it seems icky, especially if you're targeting mobile with much higher latencies.

ricardobeat• 4 years ago

This is a very confusing, and then disappointing, article.

It starts by describing what is, essentially, plain javascript or how you'd use jQuery in the old days. Attaching events to the DOM at startup is not hydration.

Then it starts describing what seems to be React's particular flavour of hydration, where it re-renders the entire app before applying its diff/reconciliation algorithm. But in a very roundabout way, it's not clear what they are even talking about. Not every framework works like that. And, it's definitely not the heaviest part, diffing the DOM can be extremely fast. The slowness comes from, erm, everything else and just the sheer amount of code these frameworks run.

By the third section, I had the feeling this would be an advertisement for Qwik, because of the 'closure around app state' concept, and how they appear to believe that lazy loading everything is the best idea since sliced bread. Bingo :)

Existenceblinks5• 4 years ago

A symptom of everything js. The desire to write template once in one language and ignore that role of frontend and backend are different, so are business logic usually. At the end of the day some duplicated codes are simpler and better solution.

JavaScript hydration is a workaround, not a solution

Related Stories