Frontend, backend - let's be friends again

Programming is my passion. There's nothing better than working as a team, together to deliver something working to the users.

Working together creates this bond. It creates the connection that allows us to trust each other.

What are you talking about, Andrzej? Is it some kind of boomer's talk again?

Yep.

Back then, not that long ago, we didn't have the frontend/backend separation.

We have rendered html on the server. It was sent to the browser as a whole page.

Yes, it had limitations, as the browsers and machines back then.

The browsers got better. The computers and mobiles got stronger. They are now able to run more JavaScript.

Around 2010 the shift has started. Over time more and more apps went into this backend with JSON and frontend as a Single Page App. I was one of the advocates of this approach. It was new and promised more modularity.

It almost promised us to think about Single Page Apps as desktop apps.

Almost.

The browser is this weird hybrid monster.

The browser is on one hand a document browser. Read this article, click next, read this list of documents, click, read another article.

The second face of the browser is being a runtime for running JavaScript apps.

The lie that I felt into was that I thought browsers would become less hybrid and became more the runtime part.

Then certain things could be simpler.

There's not much sense to have a Back button in runtime apps. What does it mean for a chess app which runs in a browser? It's confusing. Yes, desktop apps have undo/redo often. But here it doesn't make sense. A back button makes a lot of sense when we think of browsers as document viewers. Go back. In desktop apps it's very confusing.

That's why this part of frontend apps behaves weirdly when you click Back.

Then we have URL's - they make perfect sense in document viewers. Documents are resources. Resources have addresses, like URLs.

But maintaining a meaningful URL state in a JS frontend which behaves like a desktop app? Should every little message have their own URL? Again - what about games like chess and other more advanced stuff?

Don't get me wrong - it's all possible to work around and make it consistent. You've probably done that.

It just adds more work. It adds more complexity.

I hoped the browsers would stop being just document viewers.

Instead, we will switch to treat it as a runtime to run document viewer apps. That's a difference.

I was either wrong or just to quick with my expectations. I can't imagine how we can have those hybrid browsers in the next decades.

I hope for simplicity.

But what does it have to do with frontend and backend?

The frontends became more complex (like desktop apps).

New technologies appeared - react, redux, maintaining the state on the frontend. This became a specialization on its own.

This together with a huge influx of new developers in the market created this almost generational difference. Many
young people specializing in frontends. Old boomers, like me, who stayed closer to the backend.

At the beginning it was fine. But over time, the more backend-inclined developers were not able to catch up with what's happening on the frontend. The frontend tooling was complicated and it's still complicated. It's hard to be a good backend dev and at the same time be a good frontend developer.
People don't want to be mediocre. They choose sides.

This is where we stopped being friends.

We now have this fence between apps.

"When can we expect this API to be ready?" ask frontend devs.
They come up with ideas like GraphQL to talk less to backend devs.

"It's your fault, my API works, but you screwed the JS part and now the users can't use the app" shout backend devs to frontend devs.

We have created this boundary between ourselves.

It's us vs them.

We're not friends.

What's worse, we're very close to become enemies.

Not everywhere, not always - but this is the trend I see around.

I don't like that.

Is there a hope?

Yes. But I might be wrong again ;)

The hope is the potential shift back to backends.

The shift of where html is rendered. React has introduced Server Rendered Components - which to old people sound exactly like what was there before. But in JavaScript.

Then comes the Rails world with its innovative approach. What if we agree that frontends stay with us and be cool with JavaScript "sprinkles". But, the HTML is rendered on the backend and sent to the client via Web Sockets (allowing nice updates on other clients too).

In this approach maintaing the state is needed only on the backend.

*This simplifies the frontend by a lot. *

This simplifies the whole app by a lot. Potentially less bugs, faster shipping of features.

Two places to watch are Hotwire (to become part of Rails soon) and Stimulus Reflex. Very likely there are similar things in your technology too.

This is our hope, dear backend and frontend friends.

This means simpler technology stack. This means backend people can deliver some frontend features. This means frontend people can have more time to learn backend stuff.

This means we work together again.

We're friends again.