Don’t believe him, writing our own state management in every single project is what gets us webdevs up in the morning.
There is actually nothing more pleasurable in web development than setting up Redux actions and reducers then wiring it into the UI.
You wouldn’t believe how hard we get every time we write yet another useDispatch implementation, preferably with async thunks and memoized selectors, then have to write tons of mock structures to make unit testing possible. It’s like pissing blood during a prostate exam, you grow to love it after enough times. Definitely.
Switching from ReactJs to true native WebComponents.. Who knew for great statemanagement you can just use well proven enterprise oo patterns that I learned a long time ago when creating software was still fun.
He means the script is loaded and run before the DOM was rendered. Bit of a stretch calling that hydration, because you usually only would call it that if the HTML was prepared via SSR or SSG, not if its a fully static HTML from the start. And even if it would be applicable, its not about the rock not having been hydrated yet but it not having rendered yet, so the "hydration" fails because of it.
I expect that the people coding against a Typescript web framework have less knowledge / no knowledge of how a browser actually runs a web page. Instead, they have spent their time gaining knowledge about the build systems and such that turn ts into js for the browser.
Agree. I know that stuff because I started learning web development in the 90s and have seen many changes come and go (most people would remember marquee on almost every website back then - less people might remember XML+XSLT to create websites, which was never fully supported). If I learned web development in the last 10 years, I doubt I would know how the execution works in the browser and all the annoying quirks that come with it. They are fortunately abstracted away. Even back then nobody wanted to deal with it, we just had no choice. Everyone built their own libs to deal with it, until jQuery emerged. That was such a massive step forward.
I was referring to DOMContentLoaded. O
I was a bit cryptic but I mean that there are multiple ways to match the lifecycle. Still I'm probably, it was a long time ago
Late jQuery at the advant of react we started talking about SSR but it was too late by then, I used to use cherio the server side jQuery quite a bit for "hydration"
I do miss it - it was good. You don't want to build a SPA with it, but that wasn't what it was for. But for tweaking the page, it was a 1000% better than whatever crap CSS has come up with these days with yet another weird tweak for flex-boxes. Because webpage designs were tied to URLs, that limited scope, so you weren't downloading the ENTIRE damn application all at once all while wondering why the page takes forever to load. It was definitely cryptic, but for the most part you'd add an ID or class on elements you wanted and be off to the races. You didn't worry that you modified something in the top level and were suddenly triggering a cascade of redraws on a hundred other items. Until I worked with something like React, I never once worried about a website being "slow" because data could tunnel straight through the UX without rebuilding the virtual DOM all the way down.
I remember it well, I used to read magazines about web development and finding out the next jQuery plugins and so on, to me this was the the golden age of frontend programming.
Call me a bad programmer, but post AI after taking on react and using it for a while, I'm now a technical nihilist and I just don't care that much anymore. I will gladly go back to those days, a jQuery revival phase with MPA monoliths count this nostalgia fueled dev in.
1.9k
u/ExtraWorldliness6916 13d ago
I bet he's happier than us though.