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

111–120 of 239 posts

Re: JavaScript hydration is a workaround, not a solution

#111

Post by trs8080 »

cxr wrote: post #88
phailhaus wrote: post #62

Earlier quoted context omitted.

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…

So your solution is to write a browser so you don't have to write JS?

Supposing I just want to create an internal tool that allows me to collaborate in realtime with my colleagues on a document (multiple cursors, everyone editing at once) and I have to do it in an existing browser because I don't write C++ and only have a few weeks to deliver - how would I do this without JS? Also, it needs to work on Android, iOS, Windows, and macOS in FF, Chrome, and Safari.

Re: JavaScript hydration is a workaround, not a solution

#112

Post by psygn89 »

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.

I agree, I know eventually the datalist won't lag on scroll with even just 100 items in their datalist control, and that they'll name their dropdown picker to something other than "-webkit-calendar-picker-indicator" since it's misleading https://jsfiddle.net/klesun/mfgteptf/ If I sound passive it's because I assumed a native control/component would be performant and switched out a lot of controls for it only to have to revert back to a custom solution. But ultimately they will be fixed and it'll happen to us transparently which is nice.

Re: JavaScript hydration is a workaround, not a solution

#113

Post by pier25 »

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…

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.

Re: JavaScript hydration is a workaround, not a solution

#115

Post by jozzy-james »

RestlessAPI wrote: post #49

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

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

Re: JavaScript hydration is a workaround, not a solution

#117

Post by pier25 »

strongpigeon wrote: post #79
diceduckmonk wrote: post #70

Earlier quoted context omitted.

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

> Having worked on one of the most bloated SPAs at Google [...] Let me guess. Google Ads?

I'd say probably the Google Cloud Console.

Re: JavaScript hydration is a workaround, not a solution

#118

Post by RickHull »

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…

https://htmx.org/

Re: JavaScript hydration is a workaround, not a solution

#120

Post by galaxyLogic »

michaelchisari wrote: post #41
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…

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.

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.

Post reply on HN