3 ms·

Recently I've been playing around with Dear ImGui and it's so fast that now all other pieces of software feel sluggish in comparison. It starts up near instantl

Recently I've been playing around with Dear ImGui and it's so fast that now all other pieces of software feel sluggish in comparison. It starts up near instantly and it's incredibly snappy. Even using Python bindings is still incredibly fast. Meanwhile I find it very challenging to build performant web apps without digging myself into a framework-shaped hole, even when the app shouldn't be doing anything particularly complicated. Maybe part of it is a skill issue on my end, but it really feels like a team of smart engineers could help bridge the performance gap between native and web. Or maybe create an island that sits in the middle.

freeone3000 2y ago
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.
resonious 2y ago
> Meanwhile I find it very challenging to build performant web apps without digging myself into a framework-shaped hole, even when the app shouldn't be doing anything particularly complicated. This so much. I semi-recently made an Android app with Flutter and a custom storage solution of just simple mmap calls. It cold starts instantly, even after a long time of not being opened. I then made a web thing, PWA style offline-first. It has a noticeable loading phase when you start it up, even though the entire thing is just static files on disk. Looking at the performance tab in chrome dev tools makes me want to cry. Things take way too long. And don't get me started on Indexeddb. (I realize that profiling incurs overhead, but it's still embarrassing. Indexeddb isn't even instrumented and it takes 20+ms to fetch one record out of an index) SQLite on frontend was trending for awhile recently. I tried using that to get around terrible Indexeddb, but the startup time was so bad. Several seconds just to initialize the library and read the database file. It's pretty quick to query once running, but a non-starter if you want to show users their data quickly upon starting the app. It seems that even just chugging the wasm takes a significant amount of time...

freeone3000 2y ago

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.

resonious 2y ago

> Meanwhile I find it very challenging to build performant web apps without digging myself into a framework-shaped hole, even when the app shouldn't be doing anything particularly complicated. This so much. I semi-recently made an Android app with Flutter and a custom storage solution of just simple mmap calls. It cold starts instantly, even after a long time of not being opened. I then made a web thing, PWA style offline-first. It has a noticeable loading phase when you start it up, even though the entire thing is just static files on disk. Looking at the performance tab in chrome dev tools makes me want to cry. Things take way too long. And don't get me started on Indexeddb. (I realize that profiling incurs overhead, but it's still embarrassing. Indexeddb isn't even instrumented and it takes 20+ms to fetch one record out of an index) SQLite on frontend was trending for awhile recently. I tried using that to get around terrible Indexeddb, but the startup time was so bad. Several seconds just to initialize the library and read the database file. It's pretty quick to query once running, but a non-starter if you want to show users their data quickly upon starting the app. It seems that even just chugging the wasm takes a significant amount of time...