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.
Top comments (14)
For my perspective there is no such thing like "X group of people have more complicated tooling". For a frontend dev, the backend tools seems to be more complicated, while for backend is the oposite and it seems to be very normal, because they have diffrent way of working, goals, background and often even attitude or type of personality.
As you said, it's hard to be good in both, and I don't think the Hotwire (or the approach in general) will change that, so why "force" one to be the other? Let them be experts in one area and it will be beneficial of both "sides", because people always work on the stuff that they comforatable with and will be able deliver as good backend / frontend code as possible, due to their extensive knowledge in that area.
Unfortunalety it's a model where one developer probably can't deliver the whole solution, but isn't that just sing of the times we live in, that things are not simple anymore and it's extremely hard for a single person to be as least good enough in all things necessary to deliver?
Anyways, thanks for this post, realy like it, make be think πββοΈ
Thanks for sharing your perspective here.
I'm not accepting the current status quo around frontends/backends - I find it over-complicated and not productive at all.
I also have a different opinion on tooling - it's not subjective. Tooling ecosystem, while hard to measure is in some cases less mature or more mature and thus can be objectively evaluated as worse or better. Frontends just didn't have enough time to mature similarly to some of the backend ecosystems (not all).
Finally, I'm not fine that one developer can't deliver a whole feature alone. While I agree that things are getting more complex, I don't think web overall has to be that complex as it is now.
Peace :)
I cannot agree with you more. The whole front end / back end thing has created a huge amount of friction. As you say a single developer should be able to understand and deliver a feature. It causes friction between developers (I don't mean arguments, just that things slow down), and it causes friction between the customer and the developers.
I've worked on full stack teams a few times, and each time I find people are still drawn to one side or the other. I always ended up with the front end work and the backend-focused developers always shied away from it.
I've also worked at places where the gulf between FE and BE devs was so huge, there was some real animosity between the 2 sides.
The problem is that all BE developers think the whole app should be served up by the backend, and front end devs think the entire app should be driven by js.
For me ive found the best way to keep the 2 sides in parity is to work on having a similar architecture and ethos between the 2. If a backend developer looks at the frontend code and feels familiarity with it, that lowers the supposed complexity barrier immediately.
Man you said it. That is exactly why we use hyperstack.org at our business. Sure some folks are better at front end and others are better at backend, but at least with a framework like hyperstack (there are others) everbody can read, understand, and fix everybody elses code.
Article hit all the right points. Wish you had mentioned hyperstack.org . I recently did a little comparison of Hotwire vs Hyperstack here: medium.com/@mitch_23203/hyperstack...
The nice thing about Hyperstack is its goal is to completely bust down that barrier between front end and backend.
Thank you for this comment β€οΈ
Indeed, I could have mentioned Hyperstack. I love all the Opal ecosystem but never found enough time to see how cool it is exactly.
Are there non-Ruby such ecosystems?
For javascript there is meteor.com/
Of course I am biased as a core contributor to hyperstack but indeed it is pretty cool. You simply write the same code on client as you would on the server. Even back in the "good ole days" of HTML, you had to mix HTML with Ruby using ERB. In hyperstack you just write your front end component code (roughly like a rails partial) in Ruby. All your active record models are accessible directly on the client using the same AR API that you would on the server.
I don't think it would be possible to build such a productive system in any other language because 1 - Rails gives you so much to start with, and 2 - Ruby is so good at building clean DSLs and APIs.
Huh? There was frontend. In my own and many colleagues' experiences, it was similarly separate, albeit in slightly different ways. We frontend folks weren't considered real engineers back then, not with our managed hosting, relatively simple query-and-display code using templates, and our design sensibility that cared more about human factors than about what Facebook funded. Some people say that frontend folks had a desperate need to prove they were just as SMRT as any engineer and that some of them decided to make frontend more like backend and ruin it for everyone else. A mess has certainly been made, but who can really say why.
That aside, this next generation of stuff that tightens the integration is very exciting. I'm particularly interested in no-sweat trisomorphic rendering.
Htmx, successor to Intercooler
Thanks! I didn't know about this one.
Thanks for mentioning it. I learned about it two weeks ago and am eagerly watching that project.
A barrier sounds like a organization problem. Iβve never worked on a team where developers were not responsible for the entire stack.
Neither me, but when I talk to the people around it's clear that the separation is the mainstream now.