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

221–230 of 259 posts

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

#221

Post by eitland »

throwaway894345 wrote: post #129
eitland wrote: post #94

Earlier quoted context omitted.

> like Java, C#, or Go (although the first two might involve some tradeoff on developer productivity When I first learned Java I though like this. I liked Python, Perl and even PHP. Then after reluctantly joining a Java team I learned to like it. Next I realized how much I actually missed from Java every time I went back to work on a hobby project. Having a Still for a couple of years other languages still seemed to…

I'm sure a proficient Java dev can be very productive, but it would take quite a lot longer to turn a Python dev into a productive Java dev than into a productive Go dev. I don't think this is controversial, but it's not really relevant to my point either way.

> but it would take quite a lot longer to turn a Python dev into a productive Java dev than into a productive Go dev.

I'm really not sure about that. That said it seems you don't really want to discuss this further which is totally OK with me :-)

For others who wonder, my points are only that:

- I was a person who was strongly opinionated against Java and for Python and basically everything else (at that point I had been programming on and off for 10 years)

- Actually becoming productive with Java took a week and the big thing was culture.

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

#222

Post by elsurudo »

frandroid wrote: post #206
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…

What I find amusing is that all of today's SPA frameworks/views are kind of descended from Angular, which Google built internally after learning the lessons of how to build such a thing while putting the Gmail front-end together. We 15 years of SPA usage in email applications demonstrating their superiority. We have things like Facebook, the one true SPA which rules them all. And yet. Turbolinks. (And I say that as a…

Facebook has a terrible and slow UI, so IMO not the best counterexample.

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

#223

Post by eitland »

charukiewicz wrote: post #159
lukevp wrote: post #151

Earlier quoted context omitted.

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

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

Let me paint a somewhat less strawman-y picture of DHH for the benefit of those who doesn't know him:

- He is the guy who built Rails and inspired a huge number of other frameworks from Symfony and Laravel to parts of modern JavaEE.

- "His" apps (obviously built together with others) were early examples of actually working Ajax.

- He has been preaching against the hunt for unicorns for a decade or so I think, talking about sanity and sustainability.

- I think the thing about PWA is less that he isn't interested in it and more that he wants things to just work across all browsers.

- The thing about Apple is less about attacking Apple and more about defending himself - and in the process a number of smaller devs - against abuse from Apple.

I have a lot of nice things to say about Apple, but for cases like this where you wonder if it was Apple or Oracle who called you to extort money then Apple deserves all the criticism rhey get (and then some more if you ask me). Just because one is mostly nice doesn't make it OK to run an extortion racket on the side.

(Apples platform, Apples riles one might say but as far as I have seen so far they didn't break any of the rules, so even by that rule Apple is in the wrong here until they change their rules to add something tvat allows them to do this.)

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

#224

Post by alecbenzer »

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.

Yeah, maybe it's different the further you are from the US or something, but from my use of hey, I have no idea what these people are talking about. It feels about as snappy as most other apps I use. If anything it feels snappier than my average app (though I think that has more to do with backend/network than the UI).

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

#225

Post by alecbenzer »

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.

Not measuring but just going off of my memory, hey feels subtly but distinctly snappier than discord.

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

#226

Post by alecbenzer »

piazz wrote: post #130
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.

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.

Switching between pages is pretty hit or miss for me in Notion. If it's a page I've been to recently it's very fast, but it's noticeably slow on some page loads. hey seems consistently pretty-fast.

Moving around elements doesn't seem like a fair thing to compare to navigating around the app... that's more like looking at how smooth text editing feels in Hey.

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

#227

Post by sougou »

dmlittle wrote: post #220
ksec wrote: post #204

Earlier quoted context omitted.

Is there a Vitess for Postgres?

Looking at Vitess' roadmap[1] it's in their medium term roadmap but I'm not aware of any other project that currently support Postgres. [1] https://vitess.io/docs/resources/roadmap/

This is still in our plans. We're likely to launch by end of year.

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

#228

Post by rhizome »

latortuga wrote: post #181
rhizome wrote: post #172

Earlier quoted context omitted.

The Rails version of that is called ActionCable.

Kind of, yeah. ActionCable is just the plumbing though. The functionality of Motion, this forthcoming magic, LiveView, etc is all a step higher up. Motion uses ActionCable as the implementation mechanism, the "pipe" that data transfers over. But ActionCable itself is basically just "you can use websockets with Rails!" and not much else.

Well sure, and inevitably there are going to be gem(s) or framework additions that make it easier to send HTML down the pipe, which is how I read your comment. We don't disagree!

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

#229

Post by WJW »

criddell wrote: post #36
unixhero wrote: post #12

Why is it called Hey stack? Why does the "Hey stack" persist to the obsolete Mysql dB engine and not PostgreSQL (opinionated dovnvote fodder, I know, but hey; bring it on! They are valid questions).

Maybe because MySQL is good enough for what they need.

In addition, calling it "obsolete" compared to postgres implies postgres is better in all ways, which is simply not the case. There are entirely valid reasons to choose MySQL for new apps.

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

#230

Post by tomlagier »

welearnednothng wrote: post #196
lukevp wrote: post #153

Earlier quoted context omitted.

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

Not to be pedantic, but there is manual "diffing":

https://github.com/turbolinks/turbolinks#persisting-elements...

Post reply on HN