It can feel overwhelming to be a web developer.
Constantly trying to keep up, learning new frameworks, learning new language features, sometimes learning entire new languages. It’s no wonder that front-end developers are often stressed out of their minds.
But there is hope: In the last few years, while there has still been tremendously rapid change, and there are more front-end frameworks and packages available than ever, there has also been some consolidation of concepts into a few megatrends.
If we have an understanding of those megatrends, that can help us to focus our thinking and understand what to learn. With this context the decision of which particular framework or tool to learn feel is less daunting - so long as the one we choose fits within these megatrends, we will be able to transfer much of our knowledge.
The more we can understand the big picture, the more we can ride this crazy wave that is the web instead of feeling swamped.
So here they are: The Top 5 Front-end Development Megatrends.
This orientation is also present in CSS, both at the methodological and the framework level. Methodologies like BEM are designed precisely to support a component-oriented approach to CSS. UI frameworks like Bootstrap, Material, or Foundation are essentially just collections of pre-made components. This is at the root of almost all modern front-end development.
Why has component-oriented development taken off so much? Because it allows for a separation of concerns and modular development in a manner that makes sense for user interfaces.
We’ve always known the importance of modularizing code - it allows us to develop far more complex systems while maintaining manageability of the code. But the right way to do this modularization for the front-end hasn’t always been clear. React’s big insight to push the separation barriers to components rather than programming language has revolutionized the front-end world.
If we want a UI element to change, we simply tell our framework what the new final state should be, and let it make all of the updates necessary to make that happen. It can use tools like a Virtual DOM to make those changes efficiently, and other things like time-slicing to make it happen in a way that doesn’t interfere with user interactions, but we the developers don’t have to worry about it.
This unlocks two things.
The first thing it unlocks is a phenomenal improvement in code readability & understandability. Instead of having to dig through many lines of jQuery to figure out what is being changed and try to infer what the final state is going to look like, we can just look directly at the template and see it straight up.
The second thing it unlocks is the ability to take advantage of framework authors to implement best practices easier and faster. React is already pursuing this with time slicing and suspending components while they fetch asynchronous data, but I also suspect this will be one of the highest leverage places for WebAssembly to impact the frontend. The more the framework is managing, the more it can invisibly do things for us behind the scenes.
As more and more complexity has moved to the front-end, we’ve also had to come up with better and better solutions for front-end state management. Purely component-oriented development is great for local state, but sometimes we need to share state across disparate components. One of the unique challenges of the front-end is how everything happens asynchronously, but sometimes we need to force predictability into our state management.
This has to two distinct, but I would argue related developments.
The first is the development of the Flux architecture. This pattern has been implemented in tools like Elm, Redux, Vuex. The beauty of this architecture is that it forces a unidirectional dataflow, making it far easier to manage and debug state. Everything ends up going through a central dispatcher, which means that you can create predictability, reproducibility, and debugability in state management.
The second development which I believe is attacking the same problem is the rise of GraphQL. This takes another pass at the problem, by creating a consolidation layer that instead of living at the front-end in a dispatcher lives on a GraphQL server. Front-ends no longer need to manage all of the many different places they need to fetch state from, and their inter-relationships… they simply ask for exactly what they need and the GraphQL server takes care of packaging it up for them.
When complex front-ends were first coming into their own, it wasn’t immediately clear how we were going to organize them. Would we simply embed more and more powerful components inside independent server-rendered pages?
Over time it has become clear that the URL is one of the greatest innovations of the web, but there could be tremendous advantages to moving between pages entirely within our client-side applications.
Ember.js was probably the first framework to really lay this out as a philosophy, but it has since been absorbed into pretty much every major client-side framework. While not every project requires a full single page application, or just one, it is more and more common to have at least part and possibly all of your front-end doing it’s own routing.
And whether you’re using React Router, Vue-router, Mithril’s routes, or something else entirely the core concepts are pretty similar. A URL maps to a set of components and state, often with nesting of components based on nested routes.
Jawdropping adoption stats like 46% of npm survey respondents using TypeScript show this is taking off, and all signs in 2019 are that this trend has continued.
While more of a “deployment” or operational innovation than a front-end development innovation, one more megatrend that has very clearly showed up is the trend towards facilitating server-side rendering of single page applications.
This allows you to take advantage of the best properties of both server-side rendered and SPA applications - a fast time to first page view, while also being network efficient and having all of the latency and interactivity benefits of a SPA.
The advantage of having identified these megatrends is that you don’t need to panic as much about “keeping up” or figuring out what to learn. You can focus in on one stack, but as you learn it take note of the big picture lessons that you’ll be able to apply quickly to other stacks as needed.
For example, you might chose to dive deeply into Next.js using TypeScript. This will have you touching every single one of these megatrends.
You’ll be building with React, a component-oriented framework with a great declarative style. You can choose to use Redux or GraphQL, and you’ll get routability and server-side rendering out of the box.
If later you decide you want to move to Vue.js as an example, all of these learnings will translate - the details of Vue are a little different, but the big picture is very similar, and there’s even an equivalent higher level framework: Nuxt.js.
If you want some help with how to learn about some of these topics, you might check out my top 5 frontend topics to learn in 2019 where I break down 5 more specific topics with lists of great resources.