As someone who feels liberated when using {reactive framework}, and very much constrained when using {low-js-dom-manipulation framework}, there’s one aspect I keep seeing repeated that is a great misdiagnosis, IMO.

Which is this notion that somehow the backend has to be extra complicated or slow or somehow worse off when using a fancy reactive framework.

Indeed, one of the selling points of tools in the Laravel / PHP space is that “you don’t need to build an API” and can “just have normal controllers returning views”.

But this mindset takes several disparate things (the backend’s complexity, the amount of data it returns, the data format returned by the back end, and how the frontend works) and basically combines them into some mutually exclusive set of decisions.

But they aren’t. At least not the way most people talk about them.

Whether your server returns a blob of JSON or a blob of HTML should have absolutely no bearing on the complexities or capabilities of your back end.

If it does, then you’re probably coupling your back end work too tightly to its presentation, which will cause you pain eventually, no matter how your front end works.

But people have this notion that if you use a reactive framework that calls the back end, the back end not only has to return JSON, but it also needs to be this ideologically pure REST API that returns all the things you will ever need for the given objects being requested. Or that you need to build some complicated GraphQL model abstractions.

You don’t. If you previously had a route that returned the user’s full profile including their long Naruto fan fiction they posted when they were 13 years old when you only really needed the user’s name and profile pic, then you don’t have to switch to a full HTML page render to fix this. Just return what you need, but in JSON form.

And by doing this, you gain flexibility on the front end to use whatever framework you want, the ability to re-use these same routes for multiple clients like mobile apps (because if a page on the web only needs the user’s name and profile pic, then that’s probably all that the app needs when loading that route too!)

People seem to think that having a reactive framework calling an API means that you have to have a pure REST API, and that a REST API necessitates a crappy back end experience that returns the monkey, banana and entire jungle at once.

And then when they go back to {html-render with lite JS framework} they get to throw caution to the wind, write single use queries and page specific routes and suddenly anything and everything goes on the backend.

Either way, you need discipline and discretion on the back end. If you go straight HTML renders, you still want to have proper separation of concerns and reusable queries and lightweight controllers that don’t really care whether they are returning HTML or JSON or Bob’s Bit-flipped Binary Blobs.

And if you go for a reactive framework, you STILL want all of the above on your back end, but you also still need thoughtful route design that returns what you need for the thing you’re doing, and not much more.

It’s not all or nothing either way, but if you approach it like that, you will feel pain. Yes, even with plain old HTML.