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

171–180 of 259 posts

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

#171

Post by Albert_Camus »

akiselev wrote: post #116
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…

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.

I don't think it's holding SPAs to a higher standard. It's holding SPAs to a reasonable expectation for SPAs. An SPA is significantly more complicated on the client side in exchange for some purported benefits, especially to the user (such as only downloading what you need). If everything is discarded on each "page" transition and re-downloaded again upon a return, and has the page-popping-into-place effect, that eliminates one of the foremost benefits of an SPA and diminishes the UX.

I encourage anyone developing an SPA to go talk to actual end users about this. Most will report that they don't like the experience, often citing a variety of issues, but one of the biggest ones is related to the immediate page transitions followed by blank boxes or loading spinners for a perceptible amount of time. You'll hear comments like "it feels too fast" or "it feels like nothing is happening". These are not good things, and developers shouldn't be clutching their React/Angular/Vue/whatever framework just because it's what they know how to develop in, at the cost of producing products that users don't like as much as normal server side rendered applications.

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

#172

Post by rhizome »

latortuga wrote: post #103
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…

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

The Rails version of that is called ActionCable.

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

#173

Post by omnimus »

latortuga wrote: post #103
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…

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

It is probably like LiveView but i think its over http. Like Laravel Livewire https://laravel-livewire.com/ I am not sure websockets and ruby are best of friends.

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

#174

Post by bdcravens »

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.

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.

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

#175

Post by dragonwriter »

throwaway894345 wrote: post #170
gav wrote: post #162

Earlier quoted context omitted.

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…

> Rewrites are typically prohibitively expensive,

Big bang rewrites are (and, moreover, tend to lose correctness from the source), Ship of Theseus ones are not and do not have that tendency. If you can do component-wise replacement, then fast-to-develop and correct but suboptimal performance is a better deal than anything which trades off either of the others for performance.

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

#176

Post by julianeon »

t3rabytes wrote: post #147
julianeon wrote: post #135

Earlier quoted context omitted.

The bigger question, for me, was: Why not use GCP instead of AWS, if you're running Kubernetes, a Google project that GCP is especially friendly towards?

We did! HEY actually started out on GKE.

Interesting! I would've thought Kubernetes on GKE would be the one offering Google's platform totally dominated - even if you have a lot of your other infrastructure on AWS.

I'm just getting started w Kubernetes and had seen some comments that I should be using GKE - so this was counterintuitive to me. I guess that once you get set up and running, AWS's offering is comparably good.

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

#177

Post by jimnotgym »

Am I misreading something, or can you only use a *@hey.com address and not your own domain? So if Hey lock you out you potentially lose access to all of the accounts you set up using that address. PayPal can't send their 1 time code, your bank can't reset your login. Your password manager can't do 2fa. If you own the domain you can switch there dns to someone else and regain your life. If you don't own the domain to your main email you are running a risk I wouldn't run.

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

#178

Post by bdcravens »

jdauriemma wrote: post #152
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.

It has included jbuilder for a long time, which has a DSL for rendering JSON responses.

https://github.com/rails/jbuilder

For a few years now, it has included the ability to focus strictly on APIs, leaving out the pieces you'd need for a full-blown browser-rendered app.

https://guides.rubyonrails.org/api_app.html

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

#179

Post by PaulAnunda »

mkchoi212 wrote: post #74

It uses ElasticSearch? Does this mean that HEY only supports searching when the device is online? I would expect search to work on a mobile app with no internet access when I'm paying $100 for an email service...

Interesting point. I can't remember the last time I had to search while offline. Not to say that it'd never happen, but implementing a decent index on a mobile device doesn't sound trivial.

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

#180

Post by bdcravens »

sitzkrieg wrote: post #166

i have to admit i don't get it. there seems to be zero compelling reason to use hey over; eg, fastmail. fastmail is to this day the fastest website ive ever used

Perhaps their target market are those who have been on Gmail for a long time, which I presume is a substantial number.
Post reply on HN