At WillowTree, our engineering team knows that focusing on high-level architecture decisions first can help alleviate some of this paralysis. This saves you money and critical development time, and most importantly, results in a better product for your users.
The quickest path to understanding your options is to understand how web development has bloomed over the last ten years.
How we got here
Call this a spicy take if you want, but the current state of the web app ecosystem can be traced in large part back to the introduction of the iPhone and the resultant explosion of native app development and app stores.
This isn’t because web apps now had to compete with a whole new breed of native siblings - apps that had access to device-level functionality and clear distribution channels. Or at least that’s not the whole story. Much more important was the fact that companies of all stripes, in all industries, were now building data-rich APIs, exposing crucial user data in a format that was suitable for consumption by native apps.
How do we know? WillowTree’s DNA formed in the early days of Apple’s App Store. Our web practice grew primarily out of a belief that users deserved better than the static, “obviously web” UX of the past. An explosion of software tools and browser capabilities has helped us reach that goal.
When “Single Page Apps” were all the rage
“Single Page App” became the best available shorthand for this architecture. Apps were, quite literally in many cases, a single page of HTML. Not every app had to adhere that strictly to the rules (sometimes you might have a single page per feature set, for example), but the concept is still the same.
React exploded onto the web development scene in 2013, and WillowTree started building production apps using it as soon as it was released to the public shortly thereafter. React was a game changer in the world of single page apps, and we’ve shipped dozens of high performance apps that use it. We’ve found React apps take less effort to make performant and are easier for developers to reason about - and thus build and maintain.
But arguably React’s biggest contributions to the web app ecosystem have been:
- Tremendous staying power. React won large market and mind share for a huge percentage of the web developer community and has held it for a long time. This means developers have been able to build up a host of best practices around its use and haven’t had to constantly switch from framework to framework.
- Versatility. In particular, it works well in a server-rendered environment.
I can hear you now: “But wait - server-side rendering? Isn’t that the model of apps built years ago? How does that even work?”
Server-side rendering refers to the practice of assembling a “complete” HTML page by way of display logic that executes on the server. The user gets the whole page all at once - without loading spinners, but with the drawback of a potentially longer wait before the user sees any rendered content.
No single tool (since React) has captured the attention of the web team at WillowTree as completely as Next.js. Why? It is, quite simply, the most user-friendly attempt yet to provide a toolkit for building out Universal JS applications.
But what’s providing even more sticking power is the feature set Next.js continues to build. Baked-in tools for building out data-rich APIs gives the team another way to provide network APIs to power apps of all varieties. The team at Next.js also keeps up with advances in the tooling space - providing automatic code splitting and hot code reloading, for example - to help developers stay more focused on the job of building apps and less concerned with maintaining development environment tools.
But one of the most interesting and … well, fun arguments for Next.js’s importance in the evolution of the web ecosystem is that it also includes a sane way to do static site generation. In other words, to build static HTML versions of your site that can be hosted as flat files on a server or CDN.
It’s possible, even likely, that this functionality, itself a throwback to the very earliest days of the web when static site generation using scripting languages like Perl was used often, is the least used feature of Next.js. But it nods to a fact that seasoned developers have long understood to be true: there’s nothing faster in the web world than static, flat files.
A mature ecosystem means more - and better choices
Tools are important, but they’re not nearly as important as choosing the right architecture for the job. What a mature ecosystem, like the one that has developed in the front-end web space over the last 10 or so years, gives you is a tool that addresses a wide array of different architectural patterns. Moreover, a mature ecosystem has some semblance of tool stability in each of those architectural arenas.
Future pieces on this blog will talk about some of the architectural patterns discussed here, and the circumstances in which you may want to pick a particular one. These include:
- Static Site Generation
- Single Page Apps
- Server Side Rendering (with Universal JS)
At the end of the day, end user experience is more important than any tool or even architecture. The current ecosystem provides developers with enough high quality tools, servicing enough well-conceived architectural models, to deliver rock solid software on time and then iterate often. That’s good news for both developers and end users of modern web software.