71–80 of 239 posts
Earlier quoted context omitted.
I thoroughly agree, society was much better before computers came along.
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.
We want to live in golden age
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…
> 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 evolut…
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?
...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…
> 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…
I thought if you're using server side rendering you'd be serving HTML directly from your application.
...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.
> 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…
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…
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.
Render the entire page in one go, rather than have the server render small chunks at a time and have the client patch the DOM. I.e. not having to think about below the fold, adding event handlers to pre-empt and preload. In practice, you’ll need to sprinkle in JavaScript interactivity, but the point is keep this to a bare minimum. See Craigslist or HackerNews.
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…
> 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 evolut…
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.
...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…
> 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…
Let me guess. Google Ads?
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…
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…