Web development is hard. I am saying that as a professional of 20 years. It’s just not easy. Yes, you can still FTP a simple HTML file to a server. The barrier to entry is as low, or lower than it has ever been. With tools like Vercel, Netlify, and Surge this may be even easier than finding a host that still allows you to use FTP.
Web Development Concerns only Grow
Mastery is what is hard. And as we move into the future, web development, or front-end roles, get more complex than ever before. We have to worry about a ever-expanding set of concerns —
- Offline Access
- Responsive Layout
- Developer Experience
While it is possible to learn a great deal about any and all of these areas. The reality is that it's unlikely that you can master even one. Every year these areas expand. You see it all the time, where advocates and experts have gaps in knowledge. They race to understand a new performance characteristic of the JS runtime or the new serverless infrastructure.
The only thing constant with all this change is that it will change. That complexity will continue to grow.
My Changing Beliefs
Recently I have started to change my beliefs about how I approach web development. For 20 years, I have built instead of bought. Researched and reconstructed instead of copied. Understood instead of copy and pasted.
This has served me very well with my career. As a UI Architect, I had deep insight and understanding of the trade-offs. Do you build it yourself, and understand every element? Or do you use someone else’s work and be restricted to a possible black box? Or is the answer somewhere between? This always meant research and experimentation.
But we are getting to a point where the Pain of development is so high, others are solving the same issues now, and with increasing speed and alarm. I don’t know that it makes sense to build instead of buy now.
With the concern of web development expanding, using a framework which removes the non-creative pieces and enforced best practices may be the smarter play.
With the concern of web development expanding, using a framework that removes the non-creative pieces and enforced best practices may be the smarter play. After all, no framework completely fixes SEO issues or all your Accessibility problems. They don’t solve every usability issue or content task. There are just so many things to care about. I can’t keep trying to solve them all myself.
My Blogs Transition
This is the reason I have rewritten my blog, yet again. When I first wrote it, I used Vue and Gridsome to try and get away from React and the bloated bundle size. A few weeks later, I rewrote the code with Svelte and Sapper, once again to get away from bloated bundle size. But I had to make such a large engineering effort to reproduce all the features I had with Gridsome, that I spent a week customizing and adding to Sapper. And over the last year, I realized that I didn’t want to maintain it. So I re-wrote it again. This time I choose Next.js.
I have been using Next.js since 1.0. In that time I have seen it mature and expand as a product. While I initially left it because of the performance characteristics, chasing a smaller bundle size with Svelte. I see that they too did not standstill.
Today, a boilerplate Next.js 10 site will get almost perfect scores out of the box. The amount of work I had to do with Next.js 1.0 to do the same was monumental. This forward movement with the Next.js project is directionally what I wished would have happened years ago.
The Next Image component, just works. I had to custom build a Svelte component to use with Sapper to achieve anything close. And it required a lot of manual tooling even for basic savings. Next.js Image component gives the same benefits I slaved over without any thought.
Basically, many of the concerns that I have had to manage over the years, is removed by using a well-thought-out framework. I still like Vue and its SFC. I prefer Svelte and its more succinct syntax. But neither Nuxt, Gridsome, and Sapper really have as well of a thought-out decision on the trade-offs.
Technology will always be a conversation of trade-offs. Sometimes it will be cost, measured in both dollars and time. Other times it will be morality and ethics, measured in societal impact. Web development is no different.
For the longest time, I was focused on chasing a smaller bundle size. And I still feel that is a worthwhile and worthy goal. But I am not sure it’s worth sacrificing the convenience that using something like Next.js brings. The gaps I had to fill, cost me time and mental energy, and it may have been the wrong choice. I was too focused on one problem when I had dozens to solve. Meanwhile, the Next.js contributors solved many of my performance issues. Any many of the solutions were not just a smaller bundle size.