DEV Community

Cover image for Has The Modern Web Made Things Better?
Joe Eames for Thinkster

Posted on

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, 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 posted their tech stack.

For some background, 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 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 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: | Facebook: @gothinkster | Twitter: @gothinkster

Top comments (4)

zeedu_dev profile image
Eduardo Zepeda

I agree with you! There has been this framework explosion these late years, it appears everybody want a piece of the cake. A new framework appears every week (I'm looking at you, JS), and all devs just jump inside the train.

aminmansuri profile image

I've been doing web programming since the 90s.. and with the risk of sounding like a grandpa, I really don't see the point of why we need to be changing frameworks and technologies all the time.

I think too often we fall for companies that are trying to lure developers for their own reasons rather than making sound development decisions.

I yearn for the day we can just have some stable platforms and not change front-end and backend frameworks every year.

What frustrates me most of all this is that the "new" frameworks rarely learn the lessons from the older ones so they reinvent the wheel and just when they start to catch up they become "old" and the new fad comes along.

I don't think this is beneficial to the industry as a whole. And the web doesn't change that dramatically that we need to be throwing away our tools and expertise every couple of years.

ericchapman profile image
Eric The Coder

Great post!

josepheames profile image
Joe Eames