5 ms·

> Unless you are running some really complicated globally distributed backend your roundtrip will always be higher than 80ms for all users outside your immediat

by imiric 1y ago

> Unless you are running some really complicated globally distributed backend your roundtrip will always be higher than 80ms for all users outside your immediate geographical area. The bottleneck is not the roundtrip time. It is the bloated and inefficient frontend frameworks, and the insane architectures built around them. Here's the creator of Datastar demonstrating a WebGL app being updated at 144FPS from the server: https://www.youtube.com/watch?v=0K71AyAF6E4&t=848 https://www.youtube.com/watch?v=0K71AyAF6E4&t=848 This is not magic. It's using standard web technologies (SSE), and a fast and efficient event processing system (NATS), all in a fraction of the size and complexity of modern web frameworks and stacks. Sure, we can say that this is an ideal scenario, that the server is geographically close and that we can't escape the rules of physics, but there's a world of difference between a web UI updating at even 200ms, and the abysmal state of most modern web apps. The UX can be vastly improved by addressing the source of the bottleneck, starting by rethinking how web apps are built and deployed from first principles, which is what Datastar does.

mike_hearn 1y ago
To see this first hand try this website if you're in Europe (maybe it's also fast in the US, not sure): https://www.jpro.one/ https://www.jpro.one/? The entire thing is a JavaFX app (i.e. desktop app), streaming DOM diffs to the browser to render its UI. Every click is processed server side (scrolling is client side). Yet it's actually one of the faster websites out there, at least for me. It looks and feels like a really fast and modern website, and the only time you know it's not the same thing is if you go offline or have bad connectivity. If you have enough knowledge to efficiently use your database, like by using pipelining and stored procedures with DB enforced security, you can even let users run the whole GUI locally if they want to, and just have it do the underlying queries over the internet. So you get the best of both worlds. There was a discussion yesterday on HN about the DOM and how it'd be possible to do better, but the blog post didn't propose anything concrete beyond simplifying and splitting layout out from styling in CSS. The nice thing about JavaFX is it's basically that post-DOM vision. You get a "DOM" of scene graph nodes that correspond to real UI elements you care about instead of a pile of divs, it's reactive in the Vue sense (you can bind any attribute to a lazily computed reactive expression or collection), it has CSS but a simplified version that fixes a lot of the problems with web CSS and so on and so forth.
- dminik 1y ago
  I'm not impressed. On mobile, the docs are completely broken and unreadable. Visiting a different docs subpage breaks the back button. Firefox mobile seems to think the entire page is a link. This means I can't highlight text for instance. Clicking on things feels sluggish. The responses are fast, but still perceptible. Do we really need a delay for opening a hamburger menu?
- recursion 1y ago
  At least for me this site is completely broken on mobile. I'm not saying it's not possible to write sites for mobile using this tech... But it's not a great advert at all.
  - monooso 1y ago
    Hardly a surprise, given that: > The entire thing is a JavaFX app (i.e. desktop app) Besides, this discussion is not about whether or not a site is mobile-friendly.
  - mike_hearn 1y ago
    I haven't tried it on mobile. That could be, but my point was limited to latency and programming model. You can use JavaFX to make mobile apps. So it's likely just that the authors haven't bothered to do a mobile friendly version.
- integralid 1y ago
  >the only time you know it's not the same thing is if you go offline or have bad connectivity. So, like most of the non-first world? Hell, I'm in a smaller town/village next to my capital city for a month and internet connection is unreliable. Having said that, the website was usable for me - I wouldn't say it's noticeably fast, but it was not show either.
  - smj-edison 1y ago
    I feel like it depends a lot on what kind of website you're using. Note taking app? Definitely should work offline. CRUD interface? You already need to be constantly online, since every operation needs to talk to the server.

by imiric 1y ago

mike_hearn 1y ago

To see this first hand try this website if you're in Europe (maybe it's also fast in the US, not sure): https://www.jpro.one/ https://www.jpro.one/? The entire thing is a JavaFX app (i.e. desktop app), streaming DOM diffs to the browser to render its UI. Every click is processed server side (scrolling is client side). Yet it's actually one of the faster websites out there, at least for me. It looks and feels like a really fast and modern website, and the only time you know it's not the same thing is if you go offline or have bad connectivity. If you have enough knowledge to efficiently use your database, like by using pipelining and stored procedures with DB enforced security, you can even let users run the whole GUI locally if they want to, and just have it do the underlying queries over the internet. So you get the best of both worlds. There was a discussion yesterday on HN about the DOM and how it'd be possible to do better, but the blog post didn't propose anything concrete beyond simplifying and splitting layout out from styling in CSS. The nice thing about JavaFX is it's basically that post-DOM vision. You get a "DOM" of scene graph nodes that correspond to real UI elements you care about instead of a pile of divs, it's reactive in the Vue sense (you can bind any attribute to a lazily computed reactive expression or collection), it has CSS but a simplified version that fixes a lot of the problems with web CSS and so on and so forth.

dminik 1y ago
I'm not impressed. On mobile, the docs are completely broken and unreadable. Visiting a different docs subpage breaks the back button. Firefox mobile seems to think the entire page is a link. This means I can't highlight text for instance. Clicking on things feels sluggish. The responses are fast, but still perceptible. Do we really need a delay for opening a hamburger menu?
recursion 1y ago
At least for me this site is completely broken on mobile. I'm not saying it's not possible to write sites for mobile using this tech... But it's not a great advert at all.
- monooso 1y ago
  Hardly a surprise, given that: > The entire thing is a JavaFX app (i.e. desktop app) Besides, this discussion is not about whether or not a site is mobile-friendly.
- mike_hearn 1y ago
  I haven't tried it on mobile. That could be, but my point was limited to latency and programming model. You can use JavaFX to make mobile apps. So it's likely just that the authors haven't bothered to do a mobile friendly version.
integralid 1y ago
>the only time you know it's not the same thing is if you go offline or have bad connectivity. So, like most of the non-first world? Hell, I'm in a smaller town/village next to my capital city for a month and internet connection is unreliable. Having said that, the website was usable for me - I wouldn't say it's noticeably fast, but it was not show either.
- smj-edison 1y ago
  I feel like it depends a lot on what kind of website you're using. Note taking app? Definitely should work offline. CRUD interface? You already need to be constantly online, since every operation needs to talk to the server.