The creators of Ruby on Rails use Ruby on Rails, why is this new?
DHHs whole career is based on it, why should he use something different?
DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
71–80 of 259 posts
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#72What 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…
Are the apps then just web view with a wrapper? Or its using react-native for apps?
Sounds like it for the view side, maybe they are doing a local proxy with some offline caching with native libs, does the app work offline?
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#73And would be exorbitantly expensive for 99% of companies because of the stack chosen
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#74It 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...
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#75Earlier quoted context omitted.
Well, he lashes out against FAANG quite often.
Elsewhere in the thread it says they have a goal to be free from "Big Tech" within 5 years, but that there are no reliable non-Big-Tech cloud platforms at the moment. Apparently "cloud" was a mandatory part of the platform. ️
My guess was Azure, because of the Github link to Ruby. But it's possible that AWS has some email functionality they need.
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#76I tried hey and was put off by its bulbous, fisher-price UI. Signing up and having to press "next" after every single bit of information they collected should have been my first clue at the brain-dead thinking that went into this product.
About the UI -- Why is there a trend in designers to add padding to an interface as a disguise for limited features? It's like, does a button really need to to take up half the screen? Oh yeah, that's right, it does if you only have a single feature.
Even the name is annoying. Hey is what you say to get someone's attention in dating app.
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#77What 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 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 ahead and click on the demo site: https://demo.realworld.io/
In virtually every implementation, every time you change pages, the app re-downloads everything it needs for that route. Click on an article and then go back to the feed? Every time you will see a blank feed for about 500ms and only then do the articles stream in.
You can say "well it doesn't have to be this way" or "this is just an example". But the reality is that it usually is this way. This real world example is a good representation of how most SPAs are built, and they lack the type of functionality you're describing. They instead end up creating an experience that poorly emulates server side rendering, since now many page changes end up with a blank page or a loading indicator before the data arrives in a subsequent request.
I don't know about you, but I'd rather wait 250ms once and then have the page arrive fully rendered over a transition that takes 2ms and then 200-400ms of multiple requests finishing and the page popping into place. The latter is really annoying, yet it's the experience most SPAs give you.
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#78What 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 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…
You’re also still paying a performance penalty for interacting with the virtual DOM in react. It’s not like react is just more complex to develop on, it’s also a noticeably slower experience in some cases (looking at you, Reddit.)
I’m also not completely convinced that the one-codebase ethos actually results in that much more efficiency, particularly given that one codebase is JavaScript. I’m sure there is a gain, but I don’t know that it completely offsets the costs of being so tightly bound to the JS community, but that could just be my experience
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#79Earlier quoted context omitted.
DHH (somewhat surprisingly) said he really has no preference between MySQL and Postgres: https://twitter.com/dhh/status/1275909837793062912
What does that answer of his even mean? That he prefers mysql ?
Now that I've thought about it more, it makes more sense. When used properly, Rails handles a bunch of the stuff that would make Postgres a better choice (like data validation, constraints, etc.)
Re: DHH: The HEY stack Vanilla Ruby on Rails, MySQL, redis, stimulus, elastic search
#80What 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…
Turbolinks is a full front-end framework. It just makes you manage the DOM diffing yourself by annotating nodes with various data attributes so that they are replaced, persisted and cached properly as navigation occurs.
It might be smaller or faster than other frameworks, but it definitely has much of the complexity and pitfalls of its brethren.