Seems to me that the proof is in the pudding wrt their stack, but it's probably not what they wanted to prove. I would take a well tuned React SPA over this any day of the week.
Ran into a host of inconsistencies already, changing between imbox/feed/papertrail on iOS also feels very “unnative” in the sense of not fluid.
The Basecamp folks have always been JavaScript skeptics (my perception at least) so I’m not totally surprised. And while the “magic” may apply to the simplicity of their front end implementation, that’s unfortunately not the same as a magical user experience where in 2020 I do expect a more fluid feel.
It’s quite apparent that often it’s just replacing one HTML block with another without too much thought about transitions.
[1]: https://twitter.com/dhh/status/1275906524569731072?s=20
Ok. Just as long as you don't get stuck in 2010 :-P
Something like a web email-client really lends itself perfectly to a pure client side JavaScript application. Use the browser's cache facilities to cache the client side javascript and save server resources by avoiding server side rendering. You don't care that much about initial load time. Or search engine visibility.
I don't really find that to be the case. All of the actions seem to be done for me in under 400ms which is to say under the Doherty Threshold. That mean's that they are largely imperceptible. Sure it doesn't have fancy animations, but there isn't really any time for them.
Can you cite an example of a popular React SPA that is less "laggy" in your opinion? I'm curious to compare the UX.
But Notion seems to be those extremely extremely rare examples.
Moving around elements doesn't seem like a fair thing to compare to navigating around the app... that's more like looking at how smooth text editing feels in Hey.
This has a lot of advantages, mainly that you don't need to care about state on the client side and you're always synced with the real estate on the backend. It has one major drawback though. If you want to create snappy interfaces, you still have to create some client visual state and modify the visual state before you receive the response from the server. Otherwise it becomes laggy because it's waiting for the response to re-render. If you don't do it this way it's going to feel slow for sure.
But again, the main advantage of this is that there's no complex state logic in the client. The server-rendering is the source of truth for your state.
It's definitely a different mindset because now you have to write JS to create UI states as they are expected to come fro the server (if you're looking for that quick SPA snappiness).
I think it's an interesting approach, but I'm not sure if I like it, though. I have build apps this way and always get the sense that I'm not creating something that feels fast.
So if you have 10 images loaded and one changed, turbolinks it’s only going to swap the one that changed.
Have in mind that we are talking about plain HTML likely gzipped blobs. So although this is not efficient it’s still fast enough for simple app layouts.
Got ya. This is what I'd expect.
Btw, I'm a follower of Basecamp and their designers, and I don't like their visual design choices :p
(And I say that as a big RoR fan!)
_Opening_ app.hey.com is a different story, and is far faster than opening a tab to gmail. I often wait for Gmail while staring at a blank tab as it loads, even one a fast broadband connection. Using Gmail over spotty broadbad, say while traveling, often leads to dropping down into "simple HTML mode".
Hey loads up very, very quickly, which isn't surprising given how small the bundle of html/js/css you are pulling down is.
Nice, this is much closer to LiveView than Stimulus Reflex. Will check it out when I have time.
Slightly off topic:
>Github's ViewComponent is currently the de-facto standard for component/presenter-style libraries for use with Rails and likely will make it into Rails eventually.
I thought DHH rejected the idea?
I can't speak for DHH, and I don't see anywhere that he commented in the PR. My read of the thread is that there are open questions about the best way to structure this abstraction, so the minimal interface to allow for clean community experimentation has been stabilized in the meantime.