Has The Modern Web Made Things Better?

There's been some fascinating discussion and debate recently about the modern web, and whether what we often take for granted as "the right way to do things" is really better than "the old way". A lot of this has been centered around Hey.com, the new email service that's taking the world by storm.

Now if you're wondering what is the "modern web" let's use a pretty general definition. The modern web is a web app using some kind of front end framework - angular, react, vue, etc. with some kind of API server - node, .NET, Java, or even serverless cloud, and a back end that is possibly relational, but very likely NOSQL, and all the various bits that go with all of that.

The recent version of this debate started when Tom Macwright posted a very interesting blog titled Second Guessing the Modern Web. Well worth a read. In response, Rich Harris, of whom I'm a great admirer, posted his In Defense of the Modern Web.

The main points by Tom Macwright were basically "JavaScript is not faster than No JavaScript" which on the face is quite true. Adding overhead to do more still adds overhead. But in the defense post, Rich Harris points out that logic can give you things like caching, lazy loading, and make decisions that actually do improve performance while also improving functionality. Ultimately both are right. JAMstack is a great method that maximizes performance, and a key piece (although not necessarily required) of it is pre-rendering.

This is all interesting, and I highly recommend you read both blogs, but things REALLY got fascinating when Hey.com posted their tech stack.

For some background, Hey.com is a new email client that bucks the trends of most email clients with its feature set, and promise of no ads. It's a paid service at $99/year. It's built by the same people who created Ruby on Rails, and who run BaseCamp. It has been wildly popular, but their tech stack reads like something built 12 years ago. They use Rails, the only client-side rendering is Stimulus, a very lightweight JS framework, and some "magic" they discuss, and MySQL. Eschewing the typical "we must use NoSQL" thing.

The people involved have long been proponents of optimizing for developer happiness and productivity. They use Ruby on Rails for everything, which is very interesting because although Rails is a server-side rendered framework, and the "modern web" looks on server-side rendering the way Obi Wan Kenobi views blasters. Yet, Ruby on Rails has long been viewed as one of if not the one technology most loved by its practitioners over basically anything else our industry has produced, although many Smalltalk and Clojure practitioners would beg to argue that point. Nonetheless, there is a very prevalent feeling among those who have used Rails, that nothing they did before or since was as productive and enjoyable. Your own mileage may vary.

For this and many other reasons, the team behind Hey.com chose to use Rails with minimal client-side rendering. This twitter thread documents the stack and many of the surprised and frankly judgemental responses to using this stack.

For your convenience, here's the breakdown of their stack:

• Vanilla Ruby on Rails
• Stimulus (minimal front end "framework" for rails) and a few other tools for front end interactivity
• MySQL
• Redis & ElasticSearch
• AWS/K8S

Again it's fascinating to note that this tech stack is very much NOT the "modern web". No heavy front end framework. Almost exclusively server-rendered. Relational DB. And they're doing well. By all reports, they're doing really well.

So does this mean that the "modern web" is really just a bunch of empty promises and unnecessary cruft that we can abandon?

Perhaps the most interesting response to that original thread is this response here, where Rich Harris basically says that although the app is great, there are a few things he would expect of a modern app that don't exist in Hey.com because of the lack of client-side rendering.

Take Away

This discussion leads us to some interesting takeaways. First, you don't have to use the "latest and greatest". First, mastering a tool will often be more effective than constantly switching to whatever came out in the last five minutes. Second, new tools and techniques can give you capabilities that don't exist in older ones. But perhaps my favorite takeaway was that we are looking at what a top-notch team can produce give tools they have been mastering for years. This probably indicates that this isn't a good reference point for all of us "average humans". When you see a true master using a tool and think that the difference is the tool, and not the hands using it, you may be missing the forest for the trees. I'll illustrate this with an apocryphal golf story.

A man was golfing with Tiger Woods. Tiger hit a particularly good shot, and the man asked him which club he used. Tiger didn't reply. Instead, he went to his bag, pulled out two more golf clubs, and went back to where he hit the shot. He dropped two more balls and proceeded to make essentially the exact same shot with the exact same fantastic result with the other two clubs. When he was done, he asked the man if he still wanted to know which club he used.

It's good to learn new tools, but to be a great programmer, don't focus on the tools.

Happy coding!

Signup for my newsletter here.

Visit Us: thinkster.io | Facebook: @gothinkster | Twitter: @gothinkster