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

251–259 of 259 posts

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

#251

Post by throwaway894345 »

mercer wrote: post #245
throwaway894345 wrote: post #189

Earlier quoted context omitted.

It's feasible, but it's still very costly. And again, there's no reason to pick a language that is going to force you to do a rewrite (incremental or not) when there are languages that offer good performance and good iteration velocity.

In practice 'good iteration velocity' is often dependent on using a language/stack that you and/or your team is comfortable with and proficient in. When one can choose between multiple equally-mastered stacks, then choosing the most appropriate/performant one is perhaps a good choice. But even then there are other things to consider. For example, I worked for a startup where my ideal choice would've been a performant…

> In practice 'good iteration velocity' is often dependent on using a language/stack that you and/or your team is comfortable with and proficient in.

This is true, but some stacks impose such a high cost that the costs exceed gains from familiarity. Basically you need to evaluate the savings of switching to a better stack and how long it's going to take before that savings equals the cost of switching to the new, less-familiar stack. For greenfield projects, the cost of switching is just the opportunity cost of slower initial development velocity while the team learns the new stack; for existing projects, there may also be the cost of rewriting in the new stack, which quickly becomes prohibitive.

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

#252

Post by ksec »

Sammi wrote: post #246
ksec wrote: post #204

Earlier quoted context omitted.

Is there a Vitess for Postgres?

Isn't Citus sort of the same? https://www.citusdata.com/

Yes but I feel Vitess is much more widely used than Citus. MySQL community, last time I check has formed a more mature ecosystem and conscious on HA and Clustering.

Postgres still feels more like throwing you a bunch of options and you are on your own.

It is not that a solution being more widely used means it is good, you are just less likely running into edge cases with no help at all.

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

#253

Post by karmakaze »

whoisjuan wrote: post #210
karmakaze wrote: post #199

Earlier quoted context omitted.

Where is the "existing loaded template" kept server-side, sticky session cache? Seems maybe better for scale to send the whole small html and let client diff-apply.

In theory the server doesn’t care about this because the idea is that you’re requesting something that is generating a complete new template. What turbolinks does is looking at the difference between whatever you have loaded in the browser and whatever was sent by the server. So if you have 10 images loaded and one changed, turbolinks it’s only going to swap the one that changed. Have in mind that we are talking abou…

> plain HTML likely gzipped blobs

Got ya. This is what I'd expect.

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

#254

Post by neilsense »

strzibny wrote: post #239
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.

And yet it actually works right? In many parts of the world I was not able to load GMail, because the first load is just too much. I take Hey approach any day as a user.

Yep, and those parts of the world will happily pay $99/yr for email.

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

#255

Post by AlexMuir »

paxys wrote: post #138
parhamn wrote: post #55

It’s rare for tech to be a determinant to a products success, which is why I’m confused at all the extrapolations here. What’s working for Hey is years of brand development and marketing that allowed them to do such a hyped launch. It could’ve been written in php with jquery and it wouldn’t have made much a difference.

Plus it's way too early to even call it a success.

We’re talking about the tech stack here. It’s already a success because there’s a working product. No-one is arguing that the use of this stack guarantees business longevity.

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

#256

Post by frandroid »

p_l wrote: post #247
frandroid wrote: post #206

Earlier quoted context omitted.

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…

A lot of Google stuff, to this day, uses GWT apparently

Internal tools are always what takes the longest to get the greenlight to rewrite... Don't take shortcuts you don't want to live with forever :)

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

#258

Post by welearnednothng »

tomlagier wrote: post #230
welearnednothng wrote: post #196

Earlier quoted context omitted.

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

Hey! I just saw this and thought I'd follow up for posterity's sake in case anyone else came across this.

This gets into how we want to define "diffing", but I would say no, no there's not any diffing on the body, manual or otherwise. Per the linked section:

"Before each render, Turbolinks matches all permanent elements by id and transfers them from the original page to the new page, preserving their data and event listeners."

So, at no point is it attempting to determine a difference between two pages. Instead, it simply queries for appropriately tagged elements (from the source code, 'this.bodyElement.querySelectorAll("[id][data-turbolinks-permanent]') and copies those over to the next page.

Thus, it's declarative rather than algorithmic and not what I would consider "diffing" at all. In this context, the parent to my comment stated it's "still having to diff just like react/vdom", which certainly isn't the case.

Cheers!

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

#259

Post by thirdsun »

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.

While I haven't used Hey yet, I find Notion on iOS to feel very sluggish and out of place compared to native apps. That's not a benchmark at all in my opinion.
Post reply on HN