Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript hydration is a workaround, not a solution

thenewstack.io

Post reply on HN
Print view View original

231–239 of 239 posts

Re: JavaScript hydration is a workaround, not a solution

#231

Post by FalconSensei »

c0nfused wrote: post #99
scrollaway wrote: post #91

Earlier quoted context omitted.

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

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

Hopefully, in someone else's timeline. But the user/customer is complaining to you, not to Google

Re: JavaScript hydration is a workaround, not a solution

#233

Post by Existenceblinks »

dmitriid wrote: post #141
wruza wrote: post #138

Earlier quoted context omitted.

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

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

People forget that a form submit is a function call with parameters. The bone of programming; calling functions. Also something something state transfer.

Re: JavaScript hydration is a workaround, not a solution

#234

Post by Existenceblinks »

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…

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.

Re: JavaScript hydration is a workaround, not a solution

#235

Post by Existenceblinks »

bern4444 wrote: post #106
efields wrote: post #96

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

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

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

Re: JavaScript hydration is a workaround, not a solution

#236

Post by Existenceblinks »

the__alchemist wrote: post #34

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

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.

Re: JavaScript hydration is a workaround, not a solution

#237

Post by cxr »

notriddle wrote: post #94
cxr wrote: post #85

Earlier quoted context omitted.

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.

"The point"?

So, again, my comments were not misleading. And these remarks don't provide any information that contradicts the claims I made. (You are, though, calling attention to what is actually misleading here—and tacitly supporting what was my argument all along, without seeming to realize it.)

Re: JavaScript hydration is a workaround, not a solution

#238

Post by cxr »

gitgud wrote: post #207
cxr wrote: post #88

Earlier quoted context omitted.

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…

> 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). So your users will need a specific browser to use your Web app? This goes against a primary advantage of Web apps... They work on many different browsers/devices*

> So your users will need a specific browser to use your Web app?

No. For the use case mentioned (editing and sharing docs in Google Docs), no one would be using a Web app, because there isn't one anymore. With the browser itself able to do directly what Google Docs is being used for, there's nothing left.

Re: JavaScript hydration is a workaround, not a solution

#239

Post by aboodman »

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

Earlier quoted context omitted.

> Seriously though, go load up any natively compiled app on your OS of choice and compare the speed of it doing any given task to what you get out of web-based versions, electron versions, etc. There isn't a comparison. I highly recommend trying out Linear.app, it's as fast as any desktop app I use. Replicache made a clone demo https://repliear.herokuapp.com/ the production linear app is even faster But if you're com…

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

It seems like you’re missing the point of the demo. It is purposely not trying to hide the initial load. There’s more (a lot more) to application performance than page load speed. This obsession with page load speed is weird. How many times a day do you open Excel? How many time a day do you click on things in it?
Post reply on HN