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.
1. Component Oriented Development
These days every JavaScript framework is adopting a component-oriented approach. It doesn’t matter one you’re using - React, Angular, Vue are the big three, but looking further at tools like Ember, Dojo, Mithril… they’re all using components as a core abstraction for thinking about the UI.
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.
JSX is not everyone’s favorite solution. I prefer Vue’s Single File Component approach, and there are valid arguments on both sides of the debate around templating languages vs sugaring up JavaScript. Regardless, the key change is the mental shift of conceiving of components as small bundles of tightly coupled HTML, CSS, and JavaScript which then themselves can be loosely coupled with other components.
2. Declarative Coding
In the early days of the web, and still to this day with many simple non-framework JavaScript applications, we used an imperative paradigm. Do this thing, change this thing, and do it this way.
Increasingly, JavaScript frameworks are themselves consolidating towards a declarative paradigm, where instead of saying how to do things we describe the outcome and the framework itself is responsible for figuring out how to make it happen. We now just state the what, and the framework handles the how and when.
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.
3. Consolidation of State Management
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.
4. Single Page Applications & Client-side Routability
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.
5. Types to Manage Complexity
JavaScript has long been a fast-and-loose development environment. Types have been loose, arguments not checked, and even automated testing was long neglected. But as the complexity of what we’re building on the front-end has grown, so have our needs for assistance managing our code and preventing errors.
And the biggest megatrend for how we’re getting assistance is with Types. Starting with tools like Flow, and now increasingly by using a compile-to-JavaScript language like TypeScript, the front-end is embracing type checking.
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.
Bonus: Server Side Rendering and Universal JavaScript
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.
Wrapping Up
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.
If keeping up in frontend development is something you care about, you might also be interested in my weekly newsletter the Friday Frontend. Every Friday I send out 15 links to the best articles, tutorials, and announcements in CSS/SCSS, JavaScript, and assorted other awesome Front-end News. Sign up here: https://zendev.com/friday-frontend.html
Top comments (4)
Wes Bos' Advanced React with GraphQL is a really nice way to touch upon a number of these areas in one go: you get Next.js, Prisma and Apollo, styled components, a bit of discussion and uses of reusable components (although knowledge along those lines assumed), and as the app is built, there's a lot to explore on the latency and rendering side of things. Even for a React dev, there'll be something new to try.
I learned to code in 2016-17 and was already starting to feel out of date - the course made me feel more confident in JS/React, but also more aware of the issues themselves rather than simply working in the stack I was employed in without question.
It's certainly made me want to delve more into moving away from Redux/Flux-style state management and the speed and simplicity offered by Next.js.
The whole read reminded me of Web Components and PWA Starter Kit
Fascinating what's already possible on the frontend and where it's going!
Great thread! Really helps me out in what I'm aiming to learn next.
Nice read