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.
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.
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
Basically it's a new, unreleased version of Turbolinks[1] + StimulusJS[2]
The "native" apps are wrappers [3] for the webapp, but with some native integrations for navigation, etc.
It might be smaller or faster than other frameworks, but it definitely has much of the complexity and pitfalls of its brethren.
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.
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.
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.
And by "you", you mean "you or anyone on your team"
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.
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.
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.
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.
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.
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.
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.
(And I say that as a big RoR fan!)
_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.
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 thought DHH rejected the idea?
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.
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.
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.
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.
Just don't do things the way Microsoft says to. ^_^
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.
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.
* 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 can't wait for the pendulum to swing back.
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.
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.
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.
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.
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 :)
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.
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.
Curious why not postgres?
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.
Changing database engines with large, established apps has a _huge_ cost and is usually not worth it.
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.
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.
[0] https://gist.github.com/dhh/782fb925b57450da28c1e15656779556
> gem 'turbo', github: 'basecamp/turbo'
I get a 404 when trying to access it, so maybe still private till the big reveal?
indeed, it was at the top of the front page for having the highest vote. Now it was sent the second page.
Weird, why could this be?
fastmail is to this day the fastest website ive ever used
Also is every mail stored in a row? Attachments too? That isn't how I'd expect it.
> The HEY stack:
- Vanilla Ruby on Rails on the backend, running on edge
- Stimulus, Turbolinks, Trix + NEW MAGIC on the front end
- MySQL for DB (Vitess for sharding)
- Redis for short-lived data + caching
- ElasticSearch for indexing
- AWS/K8S
https://github.com/github/view_component
The web socket/Stimulus Reflex/Live View approach is orthogonal.
But AWS is really pleasant to use in most cases. Especially for anything more than a trivial application.
DHHs whole career is based on it, why should he use something different?
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).
I'm not sure PostgreSQL sharding ist there yet
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.
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?
"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).