Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

m.twitter.com

Post reply on HN
Print view View original

151–160 of 259 posts

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#151

Post by lukevp »

charukiewicz wrote: post #77
lukevp wrote: post #33

Earlier quoted context omitted.

It depends on how much data is centralized. If creating a new email round trips to the server to render in the next email list page, it may feel instant on a fast connection. With a SPA framework, it could add it to the local list of emails and push to the server in the background, so it would transition instantly regardless of connectivity. It would also work offline. If you are doing all business logic on the serve…

> With a SPA framework, it could add it to the local list of emails and push to the server in the background, so it would transition instantly regardless of connectivity. With an SPA, it could be built to do this. But most SPAs aren't developed this way. Take a look at the "RealWorld" example SPA showcase (it's like a TodoMVC for SPAs), which has 43k stars on GitHub: https://github.com/gothinkster/realworld And go ah…

My post was not about what is probable but what is possible. Hey is an app, not a website, that has been built by an entire team of developers over 2+ years, with multiple millions of dollars, not a gatsby app on Netlify made in 30 minutes. They could have made this work fully offline in React in this time, if they wanted to.

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#152

Post by jdauriemma »

drewda wrote: post #137

Ruby on Rails is the stack I've felt most comfortable in for well over a decade and it's always great to see it's continued progress! That said, I do think it's unfortunate that Rails has yet to have a "canonical" and opinionated approach to JSON-based API design, alongside the page rendering. There are multiple JSON/API gems, but they come and go over the years, with inconsistent maintenance and development. So, I w…

I could be mistaken, but I believe more recent versions of Rails have out-of-the-box tools for creating and maintaining JSON APIs. Many of the bootcamp grads I work with seem to have had experience building JSON APIs using a vanilla rails app.

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#153

Post by lukevp »

save_ferris wrote: post #78
lukevp wrote: post #33

Earlier quoted context omitted.

It depends on how much data is centralized. If creating a new email round trips to the server to render in the next email list page, it may feel instant on a fast connection. With a SPA framework, it could add it to the local list of emails and push to the server in the background, so it would transition instantly regardless of connectivity. It would also work offline. If you are doing all business logic on the serve…

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.

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#154

Post by jakelazaroff »

ch4s3 wrote: post #85
piazz wrote: post #65

Noteworthy 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…

> 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.

Discord and Figma are two standout examples.

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#155

Post by oh_sigh »

piazz wrote: post #65

Noteworthy 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…

On signup, it also tries to autofill my credit card number when asking me what my full name is. Maybe it is just a chrome UI issue and it will only give the form my full name and not my CC#, but it is a little bit concerning.

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#156

Post by yesimahuman »

epoch_100 wrote: post #17

What 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…

I agree that react/vue/etc. aren't necessary, however this approach is not diametrically opposed to using a JS framework.

For example, if you use a framework like Stencil or Next.js w/ React, you will be able to pre-render your page into static HTML to serve to clients, but you also get the benefit of having rich JS components and code sharing. And then you avoid a lot of the issues they seem to have around lack of DOM diffing and the like.

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#157

Post by jeffbee »

julianeon wrote: post #144
jeffbee wrote: post #115

Earlier quoted context omitted.

Thanks for the downvotes folks, confirming my experience that this forum is incapable of engaging in a rational discussion of privacy and information security, and its members operate from a nonsense threat model. By far the biggest risk to most people's personal privacy is that someone will access their email. The easiest way to do it is to be on the staff of the email company, or to infiltrate their systems. HEY's…

HEY's security page lists encryption-at-rest. https://hey.com/security/

Interesting because this page specifically disclaims it:

https://hey.com/policies/security/

"Our application databases are generally not encrypted at rest."

Particularly interesting would be a discussion of how they can index content with Elastic while preventing system operators from accessing that index, and with strong auditing of any such access.

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#158

Post by mpartel »

burlesona wrote: post #89
piazz wrote: post #65

Noteworthy 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…

Uh... did we use the same app? I signed up this week and found the whole thing very clean and zippy. Nothing in the animations / interactions felt off to me.

The experience might vary a lot depending on ping times to their servers, if most interactions require a server round-trip (and if they don't have nice animations to hide the lag).

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#159

Post by charukiewicz »

lukevp wrote: post #151
charukiewicz wrote: post #77

Earlier quoted context omitted.

> With a SPA framework, it could add it to the local list of emails and push to the server in the background, so it would transition instantly regardless of connectivity. With an SPA, it could be built to do this. But most SPAs aren't developed this way. Take a look at the "RealWorld" example SPA showcase (it's like a TodoMVC for SPAs), which has 43k stars on GitHub: https://github.com/gothinkster/realworld And go ah…

My post was not about what is probable but what is possible. Hey is an app, not a website, that has been built by an entire team of developers over 2+ years, with multiple millions of dollars, not a gatsby app on Netlify made in 30 minutes. They could have made this work fully offline in React in this time, if they wanted to.

In your post you made it sound like most SPA frameworks will take care of this for you.

> With a SPA framework, it could add it to the local list of emails and push to the server in the background, so it would transition instantly regardless of connectivity. It would also work offline.

None of this happens automatically with SPA frameworks, and it requires a custom implementation of offline functionality in the context of the business domain (what to store, what to send to the server when connection is reestablished, which data to re-synchronize). It's hard to do, which I think is why most SPAs don't do it.

Moreover, it's clear that DHH is not interested in even something like basic PWA support, and will instead spend his time attacking Apple for not approving their app on the app store.

Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search

#160

Post by julianeon »

epoch_100 wrote: post #17

What 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…

Amusingly, the comment right about yours contradicts this: saying HEY does not feel fast, and a tuned React SPA would be faster.

I would say that there's been a pendulum swing back towards no frameworks, no bloat. But the corollary (important to note) is: this assumes competence & knowledge of performance tuning - in React, VUE, or no framework. Significantly, it means you have to a little more than the defaults.

Because if you don't do any performance tuning, it's possible that a tuned React SPA could beat it. It seems possible that a HEY app written by someone who did that with React could be even faster than what we see on HEY right now, in this particular case.

Post reply on HN