- 13 Dec, 2025 *
Here I’m collecting objections to my front-end maximalism post, with my reactions.
If you put more on the back end, you can test with more of the environment under control. (h/t patanegra on HN)
There are situations where keeping things on the back end makes testing, especially wide-scope testing, easier. That said:
- If your tests are on the back end only, they don’t have the whole environment under control. (You can’t have the front end under control if you don’t have a front end!)
- Front-end testing has come a long way, and you should be able to test anything you need to test on the front end.
- Beware overreliance on wide-scope testing.
As always…
- 13 Dec, 2025 *
Here I’m collecting objections to my front-end maximalism post, with my reactions.
If you put more on the back end, you can test with more of the environment under control. (h/t patanegra on HN)
There are situations where keeping things on the back end makes testing, especially wide-scope testing, easier. That said:
- If your tests are on the back end only, they don’t have the whole environment under control. (You can’t have the front end under control if you don’t have a front end!)
- Front-end testing has come a long way, and you should be able to test anything you need to test on the front end.
- Beware overreliance on wide-scope testing.
As always, understand your situation as well as you can, then make the best decision you can.
If you put more on the back end, you can support multiple front-ends more readily. (h/t patanegra on HN)
This claims works only if the front ends need the same thing from the back end. Often they won’t, especially as products evolve and user experiences conform more closely to their environments.
Take a simple example: you have an app with a list. On a phone, the list should be 10 items long. In a Mac app, it should be 25 items long. You might address this by putting pagination logic on the back end. That’s fine, but eventually you’re likely to run into lots of edge cases. (If X and Y are adjacent in the list, then you should show either both or neither; some subset of items doesn’t make sense to show on mobile; and so on.)
If you can get away with it, the best way to support multiple front-ends is to ship them lots of accurate data and then let them support themselves. The front-end maximalist approach excels at that.
If you take a front-end-maximalist approach, you wind up with huge bloated front-ends. (folklore)
This also came up on HN. I think that this belief, sometimes latent, drives a lot of the resistance I get to these ideas. Until recently, it was widely and explicitly believed that the front end was:
- Mostly about UX and layout;
- Nearly impossible to test;
- Just a mess in general.
Front-end tooling–including the computers the tools are running on–has gotten so much better that it’s misleading to say only that "front-end tooling has gotten better." The whole idea of the front end has changed. Beliefs and feelings change more slowly than tooling, however.
I say a bit more about this in the "Some common objections" section of the original post. More simply, however, if you and the people around you have absorbed the basic idea that the front end is a horror show, of course you won’t like the idea to do more on the front end. But instinctively disliking something is not the same as having an argument against it.