My Web Framework Rant
EDIT 2023-07-04: I wrote this at 3am when crashing on a friend's uncomfortable couch after having a couple drinks the night before. It may have been lightly edited the following day for coherency, but I otherwise have not touched it since the published date. While I somewhat agree with the sentiment, some of the metaphors may not land and my writing may come across as whiny. Still, I think the perspective is important to think about as we build software. Hopefully it helps!
Nowadays, it seems that everyone has an opinion on what "the right way" to build web applications is. Some swear by certain patterns, frameworks, paradigms, etc. While there is usually merit to these arguments, we're thinking about it the wrong way.
Technology is a tool. Nothing more.
Like all tools, they have at least one (maybe a couple more) use cases that they were designed to solve. And they're good at it!
Let's say that I'm a carpenter that needs to build a couch. Carpenters are equipped with several tools that have specialized use cases. I might ask myself:
- What materials do I need to set this up?
- What tools allow me to use these materials to build the couch? Which will then prompt more smaller choices about which tools to use in which contexts. Do I need to connect two pieces of wood? Maybe I should use some glue if it's no load-bearing, or maybe nail them together and add support if they are load-bearing. Or, maybe one of the pieces of wood is too long, so I need to saw it down to the appropriate length.
Notice that most of the questions were not centered around the tool, but the problem at hand. It would be foolish to ask myself “how can I build a couch with a screwdriver?” I’d be trying to work backwards from my goal!
Working backwards in this sense would only create more problems for myself as I encounter the actual problems I’m interested in solving. When faced with two pieces of wood that I want to connect, I now have to solve how the screwdriver can do this. I’m wasting my time since this is a solved problem: just use a hammer!
Application developers are like software carpenters: we have something we need to build and we need to choose the correct tools to do so. However, often we start backwards by considering the technology first and then molding it to fit our application. This can happen any number of ways. We have an existing app, let’s use the existing one as a base to save us some setup time. Or, some of the engineers here really like X, so we should use the XYZ stack.
This approach feels easier because it allows us to start building something now. This initially feels good because we can close tickets faster. As we close these tickets and add new features, though, we can incur a cost of discovering problems that the tool we chose just wasn’t meant to solve.
The best way we can mitigate this cost is to be more deliberate about choosing our tools. How do we do this? By asking ourselves how users will be interacting with the page and what kind of interactions will feel best for them while allowing them to accomplish their goal. We define the problem first and then pick the tools.
If the application is highly interactive and has a lot of local state, like an online code editor or a photo editing app, then [your favorite JS framework] as a Single Page App might suit the needs of the project. Or, if your application is mostly comprised of pages populated with dynamic data from your database, a traditional MVC type server might be better. Have something different? Then a combination/completely different approach might be best. As the “software carpenter,” it is your job to choose the right set of tools.
New is not always better, and old is not always bad. Different tools were meant to solve different problems. The reason for the new thing existing might mesh well with the problem you’re facing. If so, use it! If the old ways suit your needs just fine, then that’s the right choice. Hype and “best practices” aren’t a replacement for thinking critically about your specific problem space.