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

161–170 of 259 posts

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

#161

Post by JamesSwift »

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.

Ive never heard of the Doherty Threshold, but looking it up, it seems that its actually saying > 400 ms "is painful", not that its "imperceptible". And that aligns with previous rules of thumb I've used for mobile UX -- you generally want things to be < 100ms, and ideally < 50ms. If something results from user interaction the bar is much closer to the 50ms side of the range.

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

#162

Post by gav »

throwaway894345 wrote: post #99
gav wrote: post #58

Earlier quoted context omitted.

> tech stacks are important I'd argue that tech stacks are unimportant 99% of the time. It really doesn't matter if you use Java or PHP or Python or Node. Failures that I have seen due to the choice of tech stack include: - Technologies that your team doesn't know well - Technologies where hiring is difficult (I've seen attempts to turn C# devs into F# devs and Java devs into Clojure devs and productivity suffered) -…

> I'd argue that tech stacks are unimportant 99% of the time. I think this is true if your product is so wildly profitable that differences in tech stack are relatively unimportant--use whatever lets you move the fastest and just solve performance problems by scaling vertically or horizontally. If your business is cost-sensitive and your cloud-bill is a significant portion of your expense, then tech stack starts to m…

If your app involves a lot of data crunching and that crunching is the bottleneck, then it makes sense to optimize that part.

It's better to have something slow and correct to optimize, so writing it first time round in a slower language isn't a bad thing.

Secondly, shunting work out of your app is easier now than it's ever been. Enqueue and process in a serverless way. Then you can write whatever code that makes most sense for that problem.

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

#163

Post by deltron3030 »

mdoms wrote: post #112
deltron3030 wrote: post #102

Earlier quoted context omitted.

But the reception of Hey also proofs that most people don't care about flawless animations and visual design with webapps. I don't like their visual brand either, but I still might get the app when I have to deal with more email stuff.

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.

There are tech sites and productivity channels who got their hands on it, so far I didn't notice any complaints about Heys UI. I think the bar is quite low because many other apps people use perform much worse.

Btw, I'm a follower of Basecamp and their designers, and I don't like their visual design choices :p

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

#164

Post by sitzkrieg »

jakelazaroff wrote: post #154
ch4s3 wrote: post #85

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

Discord and Figma are two standout examples.

if i maximize discord on a 4k display its unusable, but i guess i should blame something in electron for that

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

#165

Post by yagodragon »

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…

If they spent all this time and energy into building a high performant and minimal react/vue app instead of using their over-engineered in-house front end frameworks the result would be even better. Maybe they should just embrace Vue.js which, like rails, is also an indie open source project ,not backed by big co. Vue 3.0, while still in beta, brings lots of improvements on the table and the new custom renderer api would make it easier for their team to also target native mobile apps.

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

#167

Post by Kiro »

brobinson wrote: post #120
meritt wrote: post #51

Earlier quoted context omitted.

MySQL 8 is very solid and has resolved the vast majority of the gripes of the past. Postgres is, as always, amazing software, but MySQL is no longer the choice to be shunned.

I don't know if I could go back to not having transactional DDL, partial and function-defined indexes, non-blocking ("concurrent") indexing, and so on...

What do you build that requires those things?

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

#168

Post by juandazapata »

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.

Off-line support is trivial. https://twitter.com/javan/status/1274168003773566977

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

#170

Post by throwaway894345 »

gav wrote: post #162
throwaway894345 wrote: post #99

Earlier quoted context omitted.

> I'd argue that tech stacks are unimportant 99% of the time. I think this is true if your product is so wildly profitable that differences in tech stack are relatively unimportant--use whatever lets you move the fastest and just solve performance problems by scaling vertically or horizontally. If your business is cost-sensitive and your cloud-bill is a significant portion of your expense, then tech stack starts to m…

If your app involves a lot of data crunching and that crunching is the bottleneck, then it makes sense to optimize that part. It's better to have something slow and correct to optimize, so writing it first time round in a slower language isn't a bad thing. Secondly, shunting work out of your app is easier now than it's ever been. Enqueue and process in a serverless way. Then you can write whatever code that makes mos…

> It's better to have something slow and correct to optimize, so writing it first time round in a slower language isn't a bad thing.

It's better to have something that's fast and correct the first time. Rewrites are typically prohibitively expensive, and we're not getting anything from using a slow language (negligible productivity gains vs Go, for example). Moreover, there isn't much room to optimize with Python for many applications--you can't always subprocess or rewrite in C because the de/serialization costs will eat any savings from parallelism or C. Not to mention increased complexity.

Post reply on HN