Being a Full-Stack Developer is no longer a dirty word

My last “article” caused quite a stir. Something about the Tweet went viral. I don’t have a large Twitter following, I don’t have a massive newsletter, and this blog, which used to get about 20 visitors a day, was my primary sales channel(an effective one too).

Who knows why things take off? The idea came to me as I was walking my dog. It took 5 minutes to execute and continues to be shared. (You can view the stats for my site here.)

I thought maybe that would be funny to share with some friends. I never thought people would share it around our small corner of the web just like that.

There are 1000s of engineers who call themselves React engineers(similar to how I call myself a Rails dev). Maybe it was because, like me, developers have enough of the JS ecosystem nonsense to render a simple ToDo list app. Perhaps it was because it attacked people’s sense of identity, which prompted an emotional response.

Who knows, but I believe the complexity and folly of the SPA approach had something to do with it.

Let me make things abundantly clear. I’ve not been a fan of React, Angular or Ember(yes, I have worked with them all). However, they are not the worst part of the SPA world. The worst part of the whole SPA approach was the complex tooling and over-engineered solutions that tried to replicate built-in browser behaviour. All that work for a product that took longer to build and fell apart as soon as someone removed one npm dependency. It always left me frustrated to see our work fall apart so easily. I was also perplexed because, in the Rails community, we had Turbolinks which gave the advantage of the SPA without the overhead. Sure, there were gotcha’s with Turbolinks, but they were worth it to get that smooth transition when navigating around an app.

In the many forums I visited where my article ware shared, there was lots of chatter about how we should go back to simpler times. Just build apps with PHP, some JavaScript and CSS. Maybe people have forgotten about the JQuery spaghetti soup that came before the React revolution. Nostalgia can play tricks on you.

As an industry, when we started separating Front-End Developers from Backend-Developers, we should have started asking if this was the right approach.

Indeed, many people did, but the majority ignored them in favour of progress.

“Separation of concerns”, they would preach.

“Facebook do it, so should we if we want to be a fabled unicorn.”

Being a full-stack developer started to feel like a dirty word. People would tell me it was impossible to do everything involved in maintaining and building a modern web application. I remember being told that the Turbolinks approach I espoused had too many shortcomings; everyone would do it otherwise. Yet, a corner of the internet remained steadfast to profitable Rails way.

I felt I was living in a mad world, seeing more and more apps built using SPAs. From the get-go, startups were hiring two engineers instead of one. Every day, new JavaScript frameworks were starting to appear to solve problems created by other javascript frameworks. When was it going to stop?

So in 2019, when I saw Stimulus Reflex and LiveView use web sockets to update parts of the page with minimal code, I thought to myself, FINALLY!. A bit of sanity has returned.

Stimulus Reflex was a breath of fresh air. It made me do even more with less. Then more frameworks started making it easier to support sockets, and now, Rails 7 launched with a WebSocket philosophy from the beginning. HTML over the wire will enable a whole new breed of startups. They will be leaner and meaner but ultimately will run into further problems.

The Downside of the Hotwire Approach

I’m not the only one who is delighted with the new emerging methodology for building web apps. There are tons of people who email me asking about changing their app from React to Hotwire.

Yet, in this flurry of excitement, I want to point out one or two downsides with Hotwire.

Latency

No matter how you look at it, sending HTML over the wire will result in more latency because more bytes are sent through the network.

The problems of the SPA era will continue to be problems of the Hotwire era. The closer you are to a server, the better the service will be.

Rewriting everything. Again

Rust has come along and has prompted us to revisit old C-libraries, which is a great thing. We seem to have a habit in our industry of rebuilding things. Sometimes it’s needed. Other times, it’s insanity.

In the JQuery era, we had tons of libraries hooked into JQuery to deliver everything from data-tables to sliders. In the React era, we have the same thing.

In the Hotwire era, we will again be doing the same thing. Vanilla javascript will do what it can(or a smaller library like Stimulus), but people will start rewriting libraries with the Hotwire approach. How do I know this?

I have had to rewrite a react library to be more hotwire-like already.

Now it’s an exciting time to be a small company again. We can get all the goodies that SPA’s have had for a fraction of the complexity price.

The Future

The last few emails I’ve gotten through this site were from people looking to switch from React to Hotwire. The motivation is simple. They want smaller development teams that give them more bang for their buck.

You would think that this is not unusual. Doesn’t every business want to maximise profits and reduce their costs?

In my small sample size, I can say that many startups that approached me wanted to spend money as fast as it poured in, notably by expanding their front-end and back-end teams before increasing their sales and marketing teams.

With the looming global recession, I can see new startups embracing a more hotwired approach to building their apps.