Web development keeps surprising me. Even a couple of decades into the job.
The latest big eye-opener is the sheer amount of power available. Which is something I ‘knew’ intellectually but didn’t know ‘know’. It’s like the difference between understanding what a shotgun does and standing next to someone firing one.
(I don’t touch firearms as a rule. Never have. I don’t judge those that do. It just isn’t for me.)
Sometimes knowledge needs to be supported by a visceral experience for it to be properly integrated.
The shotgun analogy works in another way: it’s very easy to make very big mistakes that have major consequences. Once you have a build system and your basic web application scaffolding up, huge, project-crippling mistakes come almost naturally:
- Dependencies that work great in development but turn out to be gigantic, slow, and unusable in practice.
- Code that only works on desktops
- Forget entirely to re-implement one of the basic browser features that get disappeared by the switch to client-side rendering.
- Badly re-implement those basic browser features.
- Lose sight of your project’s accessibility because your rendering library abstracts a little bit too much away.
- Completely botch up focus management.
- Completely botch up state management.
- Layout thrashing.
I could go on. There’s a lot that can go wrong in a client-rendered web app.
Most of these things aren’t major risks if the service is built using server-side routing, server-rendered pages, and server-managed state instead. (These three features are usually intertwined but forgetting that the server-rendered app is indeed providing three distinct features at once makes it really easy to under-appreciate what it is doing for us.)
Server-oriented web development is less risky, less expensive, but also less powerful. The idea that all of the really interesting things to be done in web services are going to use client-side rendering is a very seductive counterpoint to the staid reliability and feature set of the alternative.
The only reliable way to cut that knot is to accept that what’s interesting to us, as developers, doesn’t matter. What matters is how interesting it is to the user.
‘Interesting’, from their perspective, is usually more of a question of how well the UX/UI designers understand the end user’s problems—even if they are forced to work within the boundaries of technology that’s old-fashioned from the perspective of the coders involved.
The job isn’t coding. The job is solving other people’s problems. That doesn’t make the shiny things less tempting but it helps put them in context. And, occasionally, innovation, research and the business case all do come together to justify applying the shiny new thing to the problem at hand.
On the other hand, I know I’m very good at applying clever post-hoc rationalisations to lessen the discomforts caused by cognitive dissonance. All of the above could be just that. It’s usually hard to tell until well after the fact.