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 are _not_ necessary to build smooth, modern, and fully-featured web interfaces.
Edit: removed mention of Angular because, yes, it’s a framework, not a view library.
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 server side anyway, then yeah SPAs vs a server is not much different. But there is a whole class of problem that the server rendering cannot solve. Most email clients work offline and have an outbox. With a SPA you could have the web and mobile apps have the same exact code and support offline. With their setup, you have to build a native (or at least separate) app from the web app. This decision matters a lot when you’re making an app that should work everywhere, online and offline, with the exact same code.
> 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.
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.
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.
Ummm, anyone claiming offline support is trivial has clearly never written offline support. I'll give you a clue: cache invalidation (and data reconciliation) is hard.
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 context of the business domain (what to store, what to send to the server when connection is reestablished, which data to re-synchronize). It's hard to do, which I think is why most SPAs don't do it.
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.
> 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.)
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.
I think SPAs provide great benefits, but most users only visit a single page. So I would add that SPAs also tend to download more than you need (in JS) if it's something like a blog
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
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 <head>, but replaces the contents of <body> outright. No diffing on the body.
"During rendering, Turbolinks replaces the current <body> element outright and merges the contents of the <head> element. The JavaScript window and document objects, and the HTML <html> element, persist from one rendering to the next."
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.
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.
Hrmmm... we have very different experiences with Turbolinks. Maybe older versions were more like that, but v5 is definitely not. Turbolinks doesn't look at the page at a node level, it replaces the <body> tag outright for each visit. You may want to turn Turbolinks off for a specific link, or make a DOM element that holds some sort of JS-driven state permanent across page loads, but there's really not much you _can_ do on a node level and the times you do use those things are certainly the exception, not the rule.
It seems to work quite well for me, so from my perspective, it's fine.Opening an email and fully loading that whole page takes less than 400ms for me, with he first meaningful pain around 200ms.Even on slow 3g throttling its faster than loading gmail.
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.
I’m not complaining about it. I paid the $99. I’m pushing back that it’s a modern UI and modern UX. It works, but from my perspective it’s pretty ugly and dated.
It’s opinionated nitpicking, not scientific analysis.
Totally this. Maybe a great email client doesn't need to be a SPA. I love a lot of the decisions HEY made, and think the onboarding was lovely. But I think people are over hyping the core UI/UX. Is it fast? Yes. But what data are they really loading? It is also clunky and has obvious design decisions that seem made to get around needing to use more JavaScript.
I will be very interested to see it after a year of polish however.
Amusingly, the comment right about yours contradicts this: saying HEY does not feel fast, and a tuned React SPA would be faster.
I would say that there's been a pendulum swing back towards no frameworks, no bloat. But the corollary (important to note) is: this assumes competence & knowledge of performance tuning - in React, VUE, or no framework. Significantly, it means you have to a little more than the defaults.
Because if you don't do any performance tuning, it's possible that a tuned React SPA could beat it. It seems possible that a HEY app written by someone who did that with React could be even faster than what we see on HEY right now, in this particular case.
> 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.
> The main selling point of these libraries is the clear separation of concerns.
I've rarely heard this as a selling point, and it doesn't seem like a very good one to me.
Even when frontend code is clearly isolated from the backend code, it's quite easy to create a mess of it all.
Except now you're also dealing with 1) multiple separate tech stacks, 2) synchronizing state in at least two places, 3) duplication of code (validation being a common one), 4) payload size and possibly lazy-loading the front-end of your codebase, 5) and so on.
There might be /something/ to this selling point in a sufficiently large project or one where multiple client apps interact with a single backend, of course, but in and of itself I don't see the benefit of such 'forced' separation of concerns.
I agree that react/vue/etc. aren't necessary, however this approach is not diametrically opposed to using a JS framework.
For example, if you use a framework like Stencil or Next.js w/ React, you will be able to pre-render your page into static HTML to serve to clients, but you also get the benefit of having rich JS components and code sharing. And then you avoid a lot of the issues they seem to have around lack of DOM diffing and the like.
> It goes to show that libraries like React, Vue, and Angular are _not_ necessary to build smooth, modern, and fully-featured web interfaces.
I understand what you're saying but want to clarify: Angular is a full blown opinionated framework.
And from my experience in the enterprise which library or framework to use are decided by how productive the dev team can be. Not sure newbs would hit the ground running with the HEY stack.
> It goes to show that libraries like React and Vue are _not_ necessary to build smooth, modern, and fully-featured web interfaces.
Ugh, I hate this trend of hating on the front end frameworks “trend”.
You can build some things without a framework (some things you simply cannot). Sure, a basic email client can be done without much JS. I’m not convinced it’s better for having gone that route.
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 prove. I would take a well tuned React SPA over this any day of the week.
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.
From the twitter feed: "React is so 2019. HTML + minimum JS is 2020"
Ok. Just as long as you don't get stuck in 2010 :-P
Something like a web email-client really lends itself perfectly to a pure client side JavaScript application. Use the browser's cache facilities to cache the client side javascript and save server resources by avoiding server side rendering. You don't care that much about initial load time. Or search engine visibility.
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.
Ive never heard of the Doherty Threshold, but looking it up, it seems that its actually saying > 400 ms "is painful", not that its "imperceptible". And that aligns with previous rules of thumb I've used for mobile UX -- you generally want things to be < 100ms, and ideally < 50ms. If something results from user interaction the bar is much closer to the 50ms side of the range.
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.
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.
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).
More server side rendering means that a lot of the experience depends on the internet connection. Even minor lag or jitter can drastically affect responsiveness.
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.
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 about plain HTML likely gzipped blobs. So although this is not efficient it’s still fast enough for simple app layouts.
Uh... did we use the same app? I signed up this week and found the whole thing very clean and zippy. Nothing in the animations / interactions felt off to me.
The experience might vary a lot depending on ping times to their servers, if most interactions require a server round-trip (and if they don't have nice animations to hide the lag).
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.
There are tech sites and productivity channels who got their hands on it, so far I didn't notice any complaints about Heys UI. I think the bar is quite low because many other apps people use perform much worse.
Btw, I'm a follower of Basecamp and their designers, and I don't like their visual design choices :p
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.
Even though allowed in all pre-registrants, I suspect that people who registering email service that costs $90/m(even trial exists) are tend to DHH follower or similar people.
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.
The UI performance feels snappy to me, and opening up threads or going to commonly used pages feels about as fast as Gmail. From watching the performance w/ network tab open things happen in around 300 - 500 ms, which is inline w/ Gmail as well.
_Opening_ app.hey.com is a different story, and is far faster than opening a tab to gmail. I often wait for Gmail while staring at a blank tab as it loads, even one a fast broadband connection. Using Gmail over spotty broadbad, say while traveling, often leads to dropping down into "simple HTML mode".
Hey loads up very, very quickly, which isn't surprising given how small the bundle of html/js/css you are pulling down is.
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. He indicated they'll be releasing more later this year.
Nice, this is much closer to LiveView than Stimulus Reflex. Will check it out when I have time.
Slightly off topic:
>Github's ViewComponent is currently the de-facto standard for component/presenter-style libraries for use with Rails and likely will make it into Rails eventually.
I can't speak for DHH, and I don't see anywhere that he commented in the PR. My read of the thread is that there are open questions about the best way to structure this abstraction, so the minimal interface to allow for clean community experimentation has been stabilized in the meantime.
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.
ActionCable doesn't really scale that well, but can work for small loads. In addition, there's AnyCable to bring high scalability using the ActionCable protocol for easy Rails interop. With Motion, we are planning support for AnyCable.
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!
I believe they don't have much of a frontend stack at all, it's just a little bit of JavaScript, so I don't understand how the UX would be laggy if it doesn't actually do much.
Because its hard to have seamless / performant UX when requests necessarily dont share DOM state. You run into the same issues on native mobile applications.
I've been using it for the last few days and I don't have this experience. It's better than Outlook (web or desktop), hotmail, yahoo, gmail and other email services I have tried.
On signup, it also tries to autofill my credit card number when asking me what my full name is. Maybe it is just a chrome UI issue and it will only give the form my full name and not my CC#, but it is a little bit concerning.
If they spent all this time and energy into building a high performant and minimal react/vue app instead of using their over-engineered in-house front end frameworks the result would be even better. Maybe they should just embrace Vue.js which, like rails, is also an indie open source project ,not backed by big co. Vue 3.0, while still in beta, brings lots of improvements on the table and the new custom renderer api would make it easier for their team to also target native mobile apps.
Idk,I actually don't understand the obsession of many with Tech Stack or predicting the doom of a language. Because Facebook uses PHP for their service, Would you still use PHP? A lot of people despise PHP. But there's PH maker Mubs, most of his indie products LAMP stack. The main lesson I get from any of these is that pick the one that you're comfortable with and deliver the project than looking for what's the best tool in 2020
> I actually don't understand the obsession of many with Tech Stack or predicting the doom of a language
Really? You don't understand why people have strong opinions about the tools they use for work every single day?
Most programmers don't get to choose the stack they work on. Even if they do, you're going to run into pain points and wonder, "Did I pick the right thing? Would I be equally frustrated if we had gone a different direction? What would be the most enjoyable stack to choose next time?"
People do (and should) care a lot about their tools. Facebook cares so much that they invented an entirely new programming language called Hack to replace PHP, and they also invented Flow and Reason as JavaScript alternatives.
Even for small companies, tools matter. If you spend all your time rebuilding libraries, debugging at runtime, or waiting for devs to learn your stack, you're losing money.
Yeah, tech stacks are important, but which one is right is so dependent on the specifics of a given project, which is what most of these tech-stack-hype conversations ignore. My small company pays out the ears in so many different ways to run our Python service, but we picked it because certain big companies can use Python at much larger scale than ours. Of course, those companies are mostly just doing CRUD operations to a database and often errors don't matter nearly as much because it's social media or whatever, and also they aren't as cost-sensitive as our business. Instead, we're fighting tooth and nail to keep our requests below a 60s HTTP timeout threshold when they could probably be on the order of a few seconds without optimization if we used a more performant application language like Java, C#, or Go (although the first two might involve some tradeoff on developer productivity; Go would probably improve developer productivity and it would certainly be a significant improvement to the tooling/deployment/etc story).
I'd argue that tech stacks are unimportant 99% of the time. It really doesn't matter if you use Java or PHP or Python or Node.
Failures that I have seen due to the choice of tech stack include:
- Technologies that your team doesn't know well
- Technologies where hiring is difficult (I've seen attempts to turn C# devs into F# devs and Java devs into Clojure devs and productivity suffered)
- Choosing the flavor of the week, whether that's the hottest Javascript framework or newest NoSQL database
- Over-architecting thinking you were Google-scale with the added complexity hurting velocity (it doesn't matter if you can scale to millions of users if you can't get there)
Generally boring tech stacks work. By the time your Ruby/MySQL monolith has performance issues, hopefully you're successful enough that you can scale out the worst performing parts in some other language/datastore combination. You'll be in a better position to fix performance problems are when you have them rather then when you are trying to predict them up front.
> I'd argue that tech stacks are unimportant 99% of the time.
I think this is true if your product is so wildly profitable that differences in tech stack are relatively unimportant--use whatever lets you move the fastest and just solve performance problems by scaling vertically or horizontally. If your business is cost-sensitive and your cloud-bill is a significant portion of your expense, then tech stack starts to matter a lot. Further, your tech stack doesn't matter very much when you're just writing a CRUD webapp--you can use whichever stack and you won't run into issues unless you're massively successful; however, if your app involves a lot of data crunching per request, the stack and architecture matter a lot more (you might have to do more than naive vertical scaling to meet performance requirements). Note that I'm a big proponent of "boring", but "boring stacks work" is orthogonal to "tech stacks don't matter [much]".
Maybe these cases are really only 1% of cases, I'm not sure--there are a lot of CRUD webapps out there, so maybe this is true. But it's not much of a consolation when your use case is one of those 1%.
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 most sense for that problem.
> 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 many applications--you can't always subprocess or rewrite in C because the de/serialization costs will eat any savings from parallelism or C. Not to mention increased complexity.
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.
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 stack that I'm pretty good with (Elixir/Phoenix), but we ended up going for Python/Django because the founders felt that 1) it would be easier to find more programmers locally, and 2) apparently some investors do care about this. Both seemed like valid reasons to me.
> 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.
Every maintained project is a continuous Ship of Theseus rewrite, but yes, if there's a language your team is more productive at writing correct code in and that provides better performance, there's an easy choice to make. That's very often not the case, though, and as well as team it's often project scale dependent, and projects often start at a scale where the calculus is very different from where it might be years down the road.
Startups are most likely to fail for either never existing or crashing after take off. Founders mistake the first for an engineering problem and the second for a culture problem. Engineers are smart, if they can write a server in Python they can write a server in Go. Don't waste millions on maintaining an awkward stack for anything but first principles engineering decisions.
> 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 have an advantage when it came to bootstrapping something, but today? With Quarkus reloads are as fast as in PHP. Things just work and are maintained by grown-ups. If you cannot pair program, the compiler will still have your back.
I'd recommend everyone to look outside the box once in a while: if you use Java, try Rails. If you use Python, try Asp.Net or Java (Quarkus or JavaEE or something). Etc.
At least I feel I have learned a lot from being forced through this process.
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.
If you’re interested in talking through this and are considering C#, you’re welcome to email me and bounce around some ideas. I have a lot of experience in both Python and C# and may be able to help!
Yeah, selecting a stack IMO has more to do with scoping your goals.
For example, if you are an indie dev who will be developing a project solo, pick whatever you're best at, because all that matters is the product.
If you're an open source project, that's a different story. If you're looking to hire engineers, also a different game. And if you're the creator of Ruby on Rails and have created a giant personal brand around being contrarian and ignoring the new-hotness in web dev, then your choice is made for you.
I'd also say that a lot of people expecting to eventually hire on developers don't have to pick the tech stack that will scale to a 30 developer team. I've known a lot of very successful companies where the core tech was rebuilt/replaced as the team demands grow. And a lot of them probably wouldn't have gotten there that quickly if they make decisions around a 30 person team when they were 2 people.
Not only is it mature, but it's his framework. Sure he's not the only maintainer but he's the original author. It makes sense to use your own tools; specially if they're successful.
I agree with you, for >95% of projects most of the tools available to you have reasonable upside and downside. If you were equally skilled in all options, it more or less doesn't matter what you pick. There are definitely problems, and entire fields (like hardware) where you don't have much of a choice due to the performance demands. But if you're building a small company or website, for the most part the dogmatism around the tools you use are nonsense, and just get in the way of getting stuff done.
Selecting a tech stack is 75% about your developers skillsets and 25% about how easy it is to hire for that skillset, IMO. Anything else is just hype.
HEY picked their stack because their founder is literally the creator of Rails, so obviously they're going to use Rails and its related tie-ins (MySQL, Redis). This isn't really interesting as DHH has been a proponent of "Rails good everything else bad" for quite some time, and will probably only continue to double down on that stance.
I am a huge fan of server side rendering with progressively enhancing Javascript. It simply feels right to me:
* Search engine indexing works as expected.
* Informational web pages don't need a lot of interactivity anyway.
* You don't need crazy amount of build tools.
* You don't need extra browser extensions just to debug the JS.
* If for some reason there's one JS error, most of the pages are still functional.
* I am unconvinced that SPA is faster than server side rendering.
* Separation of concern is natural, business logic is handled by BFF, UI interaction is handled by JS.
* If you super love Javascript, you can write the BFF in Node.js.
I am glad that Hey is another high profile app exemplifying this.
Are you building an app? if so build an app. All UI is static hosted on CDN with content based urls that can be cached forever and all dynamic data coming in purely via REST apis.
If you are building a website, then serve html pages with sprinkled widgets here and there for interactivity.
Don't conflate the two. Users don't mind a slightly slow first load but super fast subsequent loads for an app. They'll love offline/PWA support, something that behaves like a native app. Search engines shouldn't care about indexing apps.
Web pages should behave like web pages. Search engines expect html as the format. Users expect the first load to be blazing fast. Proper href links, yada yada.
The worst is when its a half assed slow loading web page that wants to be an app, but is not an app.
I 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.
> It's like, does a button really need to to take up half the screen?
Bit of an exaggeration. Extra padding on buttons is more to do with enabling an increased hitbox for mobile and touch users, what with fingers being less precise than mice.
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.
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.
All the comments here are about frontend (which honestly comes as no surprise if you know a bit Basecamp [1]) but the interesting one for me is Kubernetes. It totally makes sense but I expected Basecamp to use something more "old fashion" (somehow like the rest of their stack).
I've switched to Stimulus since seeing a presentation on it at last year's Railsconf and it has been a real joy to use.
This is really the bit Rails was lacking for a long time. JS always felt like a second class citizen in Rails before, but webpacker finally brings the two worlds together in a way that makes sense. And with Stimulus, I actually find it a joy to write well organized js that is easy to reuse across my app. It's minimal, but just opinionated enough to keep me from mucking things up badly, the way I did in the asset pipeline days.
I wish Stimulus got more attention. It really is all most web sites need, and it works so well with the well proven Rails way of server side html added to judicious js. It's also a good tool to use as glue while you migrate legacy js over from the asset pipeline, you can just load your old js in a Stimulus controller and go.
I kind of wish Basecamp would promote it more, maybe even optionally bundle it with Rails, because it really is the missing piece that almost any Rails app could take advantage of. Having a little more guidance here would really help new Rails developers :)
Honestly stimulus is great if you have constraints around what you want to do with your JavaScript. However after working with it in a larger application, it is quickly obvious that more complex tasks are made extra hard and that lack of opinion turns into a wild west of different implementation patterns. When you start trying to get multiple stimulus controllers talking together.... Good luck.
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.
This is a valid concern with using any third party mail provider. Even if you own the domain though, you probably use a domain provider, for which it would be un-wise to use your own domain as the login email. Do you really have full ownership of any email address?
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 will pick no fight with Basecamp about using server-side rendering for Hey, but I'll still be a bit disappointed that this hasn't become an opportunity to extend Rails support in another direction.
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 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.
I assume this is their web stack. For their mobile apps they most likely use native iOS / Android codebases. The typical stack for a data heavy native app is to use an SQL store (or just filesystem) to cache data locally so its available offline. You won't obviously be able to search all of your emails offline though, only your most recent ones that happened to be loaded during online usage.
why did you assume that the fact that they are using elastic search means they don't support offline search?
You can have both... offline in device when no connection is present and online when it is...
There's something to be said for familiarity - I work in a Postgres shop now, but spent years operating large MySQL clusters in prior jobs. I'm learning Postgres, but still way more intimately familiar with MySQL (and in particular, InnoDB) internals and would probably reach for it for any new project I were architecting on my own.
Major relational databases generally all do the same stuff in similar ways for the 80% use cases, but when you get into the 20% of weird edge cases, operational concerns at scale, and troubleshooting... really knowing the storage engine internals like the back of your hand is useful.
They probably use MySQL for Basecamp and it's worked for them so they're also using it for Hey (same team developing both). As for Vitess it makes sense since it's made to work nice with Kubernetes (which they are using). I don't know of a Postgres equivalent.
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.
Basecamp (and 37 Signals) has been a MySQL shop forever, so I'm sure they have a ton of operational experience with it. There is no reason for them to switch to Postgres at this point, for much of the same reasons a place like GitHub is still on MySQL.
Changing database engines with large, established apps has a _huge_ cost and is usually not worth it.
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...
I'm not sure where I suggested "Hey, long time Postgres users, you should switch to MySQL!". The point is it's a solid modern database and a completely fine option in 2020.
MySQL8 supports functional indexes and concurrent indexing fyi. It still does not have transactional DDL nor partial indexes.
I've used them (via Postgres) to build large database-backed web applications (like Hey), realtime bidding systems (100mm+ records, 250,000+ requests/sec), and so on over the last 10+ years. Recursive CTEs as well, and MySQL finally has those as of a year or two ago. The feature gap is closing, but it's been a very, very slow process.
Is there a MySQL Roadmap somewhere? I cant seems to google anything up. Compared to Postgres which seems have way more information.
And Postgres still hasn't caught up to MySQL in multi / clustering solution. Or may be they dont ever intend to focus on it and leave it to third party.
Not that I'm aware of no. While the end product is released open-source, the development cycle itself is very much closed-source and there are very valid concerns about MySQL being owned by Oracle. MariaDB is a fully open-source alternative though I'd argue MySQL8 has surpassed MariaDB in terms of quality and features.
Probably in-house expertise and experience running previous services. That usually (or should at least) outweighs feature set in selection process, especially for databases.
I interpret it as "I didn't think about it, picked the first thing that worked in the past, and don't wish to make an argument about it, so let it go".
I think he means that if you use Postgres you are more likely to also be an evangelist for it. That doesn't tend to happen on the Mysql side. You don't hear people saying "you should switch from postgres to mysql" but you hear plenty of the opposite. Mysql works fine for most things and so that's what he used.
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.)
I am wondering have you considered the open source NewSQL database solutions like TiDB, CockroachDB? They have the best of both traditional RDBMS and NoSQL and would be the perfect choice to the hyper-growth scenarios.
TiDB could be considered as a scale-out MySQL and CRDB a scale-out Postgres. They are all Spanner-inspired solutions that can help avoid manual sharding.
If it does the job, the experience is good and ends up reducing the complexity for the development team, looks like a good solution for that particular kind of product/service.
Yeah I think the magic is something new. In the Rubular (I think) podcast for Rails 6 launch he mentions how he thinks front end is broken, and they are doing it in a new way/have ideas. This could be those ideas.
While learning about another tech stack is lots of fun for an engineer, I believe that great products aren’t written by great tools. They’re built by great engineers. A great tool helps but is not sufficient to build a great product.
Yes, based on replies on Twitter, the "NEW MAGIC" is almost certainly something like "reactive ActionView::Component". ActionView::Component didn't make it into Rails 6 but will likely land in 6.1 and this news from DHH makes it seem like they're going to support some kind of real-time piece a la Phoenix LiveView. The current Rails-land answer to this is Stimulus Reflex but it falls short in a number of ways and I'm not surprised Hey didn't use it. We ended up releasing our own version of this paradigm (put simply, HTML over websockets) because we thought the Rails world needed a proper LiveView incarnation.[1]
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. ️
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?
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.
Ehh, I'd say they are the worst in that category. They _do_ provide the most robust / expansive holistic platform though. So in terms of offerings-per-buck they are in the lead.
There are thousands of gems out there which either offer some functionality not in Rails, or replacing/extending some that is (typical example being rspec). Vanilla means no (too many) gems on top of Rails.
Some large companies have customized rails, and since Hey is built by the company behind rails, I assume DHH meant to imply that they are not using something special that everyone else won’t get access to.
Yes, Ruby on Rails, the name of a web framework for Ruby.
Just because there is Ruby in the name of the framework doesn’t mean the language itself doesn’t deserve a mention.
The generally accepted thing to do is say LANG/FRAMEWORK, like “Python/Django”. I don’t think DHH’s choosing to include the name of the Lang (an interesting choice in and of itself tbh) in the name of the framework he made changes that.
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.
You're getting downvoted probably because of your assumption that a vanilla tech stack is somehow absent of security best practices. Ruby on Rails "vanilla" is a well maintained server-side framework that receives constant security hotfixes. AWS is a cloud platform that supports robust IAM and VPC networks. It's more likely that a tried and true tech stack like this is more secure than something experimental.
"Our application databases are generally not encrypted at rest."
Particularly interesting would be a discussion of how they can index content with Elastic while preventing system operators from accessing that index, and with strong auditing of any such access.
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).
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.
Good retro old-fashion ruby stack from d̶i̶n̶o̶s̶a̶u̶r̶s veterans.
Nice :) No fancy magic. Went to check some of their stack on github and some component describe IE5 hacks.
Kind of awkward to see how they trying to create a PR driven fight with Apple for obvious reason.
"From creators of basecamp" sounds like anti-motivation to use product. They were first infomarketing company. Eventually they lost all the competition to every other company, but wrote books and succeed in this area while competitors went IPO with actual product. Why on earth someone would trust their business communications to outdated pre-hipster infomarketing company?
My negative comment is only due to this disgusting leverage on riot/liberal values when they created a stupid buzz around a 10+ years old 30% rule. Providing as an example Tesla app and 30% cost of the car which is not the case for obvious reason. Do you think people are so stupid? Yeah, it might force me to remember this product. As a product from company with extremely mean values you should never trust.
Basecamp is a very popular product, and they make a lot of money on it. I am not sure what the particular issue is. What point are you attempting to make?
Also, having worked with a lot of startups, they are living the actual dream. They have a product that makes them lots of money. They get to explore business areas and avenues what interest them. What exactly would be the point of IPOing? Have you ever IPOed a company? Do you realize why companies IPO? Or are you just spreading hatred towards startups that don't take capital investments and just make tons of cash?
My point is that when you see a path of any company that compete with them. You compare it with a books they wrote. The only feeling you can have is a strong disappointment. As a product they stuck in time and dont innovate. They market share clearly tells that. It's not correlate with focus on product.
" Eventually they lost all the competition to every other company..." -> Are your referring to Slacks?
"Why on earth someone would trust their business communications to outdated pre-hipster infomarketing company?" -> Probably because they are not under pressures from VC. In HN, we like to bash companies who have done unpleasant things because of pressures from VC. We like to said it like this, "Why did this company need money from VC? Can't they just aim the sustainable growth?"
...going IPO wasn't ever an indicator of success, and nowadays even less so. Meanwhile they're profitable enough that they can fund new products without having to do an IPO, and their product is fine, and to me preferable to things like Slack or MS Teams (not that that's saying much).
As an aside, I wish we could avoid undescriptive ad hominems like "magic" and "hacks" when talking about technology. There's pros and cons to any technology choice, but "magic" isn't one of them.
It goes to show that libraries like React and Vue are _not_ necessary to build smooth, modern, and fully-featured web interfaces.
Edit: removed mention of Angular because, yes, it’s a framework, not a view library.