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

111–120 of 259 posts

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

#111

Post by whoisjuan »

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…

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

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

#112

Post by mdoms »

deltron3030 wrote: post #102
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…

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.

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

#113

Post by wefarrell »

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…

> It goes to show that libraries like React, Vue, and Angular are _not_ necessary to build smooth, modern, and fully-featured web interfaces.

The main selling point of these libraries is the clear separation of concerns - frontend code is clearly isolated from the backend code. Previously it was common for backends to return dynamically generated javascript and to use the DOM as a frontend data storage layer. These weren't pitfalls if you had a solid foundation but if you were inexperienced these conventions gave you a lot of rope to hang yourself with.

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

#114

Post by mr_ndrsn »

jeffbee wrote: post #62

Doesn't sound very sophisticated from a privacy standpoint. How does this kind of vanilla tech stack protect my private emails from access by rogue insiders?

I’m sure there will be some blog posts soon. The encryption stuff is really neat.

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

#115

Post by jeffbee »

jeffbee wrote: post #62

Doesn't sound very sophisticated from a privacy standpoint. How does this kind of vanilla tech stack protect my private emails from access by rogue insiders?

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 own marketing materials state that they do not encrypt their data at rest, so I want to know what protects my data from the guy who is the HEY database administrator, or the low-paid datacenter tech who swaps out the broken disks.

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

#116

Post by akiselev »

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…

I think that's holding SPAs to a higher standard than server side rendering. To compare apples to apples, you'd have to compare to the real world SSR app - think the average corporate intranet django monolith. Sure it's easier on client side network and CPU resources but the same engineers that create SPA monstrosities are the ones that create SSR monstrosities.

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

#117

Post by chapati2301 »

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…

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

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

#118

Post by parthdesai »

mpweiher wrote: post #60
cwhiz wrote: post #42

Earlier quoted context omitted.

I would call the Hey UI and UX straight out of 2007. Opening an email requires a page reload.

Why is either of these a bad thing?

because it's not react/vue /s

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

#120

Post by brobinson »

meritt wrote: post #51
diminish wrote: post #6

> - MySQL for DB (Vitess for sharding) Curious why not postgres?

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...
Post reply on HN