3 ms·

The performance hole is the javascript. Drop back to rendered HTML and some simple CSS rules for display, avoiding redraws and never having a single reflow, use

The performance hole is the javascript. Drop back to rendered HTML and some simple CSS rules for display, avoiding redraws and never having a single reflow, use system fonts, and host resources on the same domain as your HTML. You will be amazed at the speed!

whstl 2y ago
But pure Javascript in itself is rarely the problem, there’s plenty of CPU-demanding websites that are responsive and performant. IMO the problem is what JS enables: making lots of very slow Ajax calls for every small interaction. Which works great in development machines but sucks when a real network is involved. But your point stands, dropping to server-rendered HTML makes it fast again.
- ileonichwiesz 2y ago
  [flagged]
oDot 2y ago
It's not only the language itself, but also the way it lends itself to the developer. I've been using Gleam in Vue[0] for my task app Netful[1] and it surprisingly reduced a lot of the jank, because... it's sync. Awaits are used very often for things that shouldn't be used for and have compounding overhead. [0] https://github.com/vleam/vleam https://github.com/vleam/vleam [1] https://nestful.app/ https://nestful.app/
EasyMark 2y ago
I’ve only done htmx and html + jQuery (&JS) interfaces for web but both were very reactive and hard to tell from native. What gets you is data fetches over networks. Can seem native when local and glacial over a slow network connection. I don’t think it’s necessarily the react/htmx/ etc frameworks, it’s the architecture usually. Javascript + DOM can be really fast, at least on modern hardware.
kaba0 2y ago
Pure react will be plenty fast. Really, try it. It’s when websites add 6 tracking libs, use some less than adequate developer that writes questionable code, and loads 3 ads per user interaction when it slows down, the same way whatever immediate UI would, were it written in hand-optimized assembly even.

whstl 2y ago

But pure Javascript in itself is rarely the problem, there’s plenty of CPU-demanding websites that are responsive and performant. IMO the problem is what JS enables: making lots of very slow Ajax calls for every small interaction. Which works great in development machines but sucks when a real network is involved. But your point stands, dropping to server-rendered HTML makes it fast again.

ileonichwiesz 2y ago
[flagged]

oDot 2y ago

It's not only the language itself, but also the way it lends itself to the developer. I've been using Gleam in Vue[0] for my task app Netful[1] and it surprisingly reduced a lot of the jank, because... it's sync. Awaits are used very often for things that shouldn't be used for and have compounding overhead. [0] https://github.com/vleam/vleam https://github.com/vleam/vleam [1] https://nestful.app/ https://nestful.app/

EasyMark 2y ago

I’ve only done htmx and html + jQuery (&JS) interfaces for web but both were very reactive and hard to tell from native. What gets you is data fetches over networks. Can seem native when local and glacial over a slow network connection. I don’t think it’s necessarily the react/htmx/ etc frameworks, it’s the architecture usually. Javascript + DOM can be really fast, at least on modern hardware.

kaba0 2y ago

Pure react will be plenty fast. Really, try it. It’s when websites add 6 tracking libs, use some less than adequate developer that writes questionable code, and loads 3 ads per user interaction when it slows down, the same way whatever immediate UI would, were it written in hand-optimized assembly even.