anybody know what they're using for the imap/smtp/pop core?
DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
191–200 of 259 posts
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#192Noteworthy how they tout the success of their "magic" frontend stack made with vanilla JS, lack of a trendy framework, etc. But if you use the app, the UX is fairly laggy, requires frequent refreshes, all the animations and interactions are off - the list goes on and on. It's noticeably subpar (and I like Hey). Seems to me that the proof is in the pudding wrt their stack, but it's probably not what they wanted to pro…
Unfortunately have to agree. I really wanted to love HEY, and while it’s certainly not super laggy or anything, I’m not overwhelmed with the “magic”. 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 “…
From the twitter feed: "React is so 2019. HTML + minimum JS is 2020"
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.
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#193Earlier quoted context omitted.
> the UX is fairly laggy 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.
Sure, a fairly best in class example would probably be Notion. Switch between pages, move some elements around, etc. There's a level of interactivity and responsiveness that I just don't see with Hey.
Which is also running on Rails if I remember correctly.
But Notion seems to be those extremely extremely rare examples.
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#194Earlier quoted context omitted.
I wouldn't read too much into the reception of Hey at this stage. It has only been opened up to people who pre registered, which is to say followers of dhh/Basecamp, who are predisposed to like it.
I'm sure they've allowed in all pre-registrants at this point. I registered sometime in the last week and was allowed in yesterday. I'm pretty sure DHH said the other day they'd open it up to the public this week sometime.
It is open to all now.
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#195Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#196Earlier quoted context omitted.
You’re also still paying a performance penalty for interacting with the virtual DOM in react. It’s not like react is just more complex to develop on, it’s also a noticeably slower experience in some cases (looking at you, Reddit.) I’m also not completely convinced that the one-codebase ethos actually results in that much more efficiency, particularly given that one codebase is JavaScript. I’m sure there is a gain, bu…
Vdom is a common point of premature optimization. React is very fast if you are rerendering components correctly. Turbo links is still having to diff just like react/vdom.
Turbolinks merges the contents of , but replaces the contents of outright. No diffing on the body.
"During rendering, Turbolinks replaces the current element outright and merges the contents of the element. The JavaScript window and document objects, and the HTML element, persist from one rendering to the next."
https://github.com/turbolinks/turbolinks#navigating-with-tur...
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#197Noteworthy how they tout the success of their "magic" frontend stack made with vanilla JS, lack of a trendy framework, etc. But if you use the app, the UX is fairly laggy, requires frequent refreshes, all the animations and interactions are off - the list goes on and on. It's noticeably subpar (and I like Hey). Seems to me that the proof is in the pudding wrt their stack, but it's probably not what they wanted to pro…
Interesting note, on Twitter DHH mentioned that they have some additional "magic" that they're using to do frontend work. It sounds like HTML over websockets, not unlike Phoenix LiveView or (tooting my own horn here) our recently released Motion library ( https://github.com/unabridged/motion ) which both allow you to use the server as your single source of truth while providing reactive UI components on the frontend.…
>Motion library
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?
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#198dang was this flagged for some reason? It seemed to be pushed off the front page really fast.
OP here.
indeed, it was at the top of the front page for having the highest vote. Now it was sent the second page.
Weird, why could this be?
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#199Noteworthy how they tout the success of their "magic" frontend stack made with vanilla JS, lack of a trendy framework, etc. But if you use the app, the UX is fairly laggy, requires frequent refreshes, all the animations and interactions are off - the list goes on and on. It's noticeably subpar (and I like Hey). Seems to me that the proof is in the pudding wrt their stack, but it's probably not what they wanted to pro…
They are using Turbolinks. They generate everything server-side and then Turbolinks calculates the delta between the existing loaded template in the client and the incoming template generated in the server and injects only the changes. 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…
Where is the "existing loaded template" kept server-side, sticky session cache? Seems maybe better for scale to send the whole small html and let client diff-apply.
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#200What I think is even more significant than Hey’s backend stack is its _frontend_ stack. There’s no complex JavaScript framework; it’s all server side rendered HTML with a few touches of lightweight JS (mostly Turbolinks and StimulusJS, afaik) on the client to add basic interactivity. And it feels just as fast—if not faster—than any other modern, well-built web app. It goes to show that libraries like React and Vue ar…
Turbolinks is a full front-end framework. It just makes you manage the DOM diffing yourself by annotating nodes with various data attributes so that they are replaced, persisted and cached properly as navigation occurs. It might be smaller or faster than other frameworks, but it definitely has much of the complexity and pitfalls of its brethren.
Hrmmm... we have very different experiences with Turbolinks. Maybe older versions were more like that, but v5 is definitely not. Turbolinks doesn't look at the page at a node level, it replaces the tag outright for each visit. You may want to turn Turbolinks off for a specific link, or make a DOM element that holds some sort of JS-driven state permanent across page loads, but there's really not much you _can_ do on a node level and the times you do use those things are certainly the exception, not the rule.