The Future of Web Development

Spoiler: writing code is going to get a lot easier

Prophesizing is no easy task — when looking at social phenomena (and web development is a social phenomenon), one knows well not to expect a simple linear projection from current events into the future.

Gathering data and observing trends will always leave some unnoticed facts, some overlooked trends, and may very well include irrelevant data that should have been ignored. Having said that, making an educated guess will probably be more beneficial than choosing to remain completely indifferent and oblivious to the future.

It’s our responsibility as software developers to anticipate what’s to come and to deliver long term solutions accordingly.

Web development, as a set of technologies, practices, and institutes, is formed mainly by two forces: hardware, or more specifically, consumer devices, and the same old eternal pursuit of financial gain. When taking the task of predicting the future of web dev, an investigation of these two should be our starting point.

Increase in the diversification of consumer devices

In the last years we’ve seen an explosion in the diversity of consumer devices — smart watches, smart glasses, smart speakers, smart TVs, foldable smartphones, etc. — in this age of IoT (internet of things), we are hardly surprised when a new ‘thing’ puts the “smart” hat on and joins the club.

What does it all mean for us as web developers? A greater diversity of devices means a greater diversity of platforms and of types and shapes of inputs and outputs. Long gone are the days of a single web app (or website) for a limited range of devices, all of them equipped with a square and large screen and a web browser.

If our aim is to get the maximum usage for our web apps, we must plan ahead and make them available to a large and unpredictable range of devices. That means, building them in such a way that would enable us to customize them easily to any existing device but also, to be prepared for the next new thing.

Web dev is too expensive

Software developers are expensive. Good developers are in shortage, and the demand for them keeps rising. It is predicted that by 2026, more than 253,000 new software developer roles will be created in the US alone. That means more money spent on highly expensive labor.

So far, the market has reacted with a few limited actions. We have seen the rise of drag-n-drop-low-code kinds of platforms that are geared toward low-skilled programmers or implementers. Google App Maker, Microsoft Power Apps, and web design platforms like Wix are just a few examples.

It seems obvious that these platforms, as good as they are, are far from being a complete solution to the problem as they are too limited to be widely used. If the current trends won’t change we will not only have a problem with expensive software but we may also see bad code written by unqualified developers for what would turn out to be bad software.

Writing code is too hard

We have so far discussed two main problems:

1. It’s getting harder and harder to keep up with the increasing diversification of devices
2. Just like any other natural resource, we are running out of developers 😃

Both problems have a shared cause — writing code is too hard! Because of that, there are no “mechanics for code” there are only engineers. Every job requires an expert and every task requires dealing with fragile and obscure code — a frighting thing, even for an expert.

When it comes to the future of the JavaScript-based web development, we’re dealing with a rich, complex and rapidly changing ecosystem. Therefore every job requires mastery of a wide set of tools, technologies, and architectures.

Why is building web apps such a difficult task?

Writing a web app requires tremendous work. There are so many different pieces to take into consideration, each of them with the potential to make the entire app fail. As Peter Jang wrote in his wonderful blog post (“Modern JavaScript Explained for Dinosaurs”):

“We went from plain HTML and JS to using a package manager to automatically download 3rd party packages, a module bundler to create a single script file, a transpiler to use future JavaScript features, and a task runner to automate different parts of the build process.”

The words ‘components’ and ‘modularity’ are being thrown around a lot these days. An outsider to the field of web dev may be fooled to believe that modern web apps are just like Lego — made out of atomic blocks of code, each is able to function on its own, each is easily replaceable.

In reality, while our apps are built in a modular fashion, they are modular only on the surface. Modules or components rely on many other pieces of code in their hosting project, they rely on the project’s compiler and they rely on the project’s repository/repositories.

Moving pieces in a web app — less like Lego and more like Stackers.

Components, components, components

The future, my friends, lies in components — real components. As mentioned earlier, “components” and “modularity” are well-respected concepts in the field of web dev.

Evidence for that can be found everywhere, whether it is in the tremendous success of component-driven frontEnd frameworks like React , the conception of a standard component model (a.k.a ‘web components’ ), the growth of tools built for components, the increase in popularity of backend architectures like microservices, the move towards more modular repositories (like, Lerna) or even, in the much emphasis that is put lately on functional programming.

Before we continue our one-way discussion about the wonderful merits of components, let’s take a quick pause to get a clear definition of how components should actually look like. For that, let me summon the words of Addy Osmani, the author of Yeoman, TodoMVC and Material Design Lite:

“Components Should Be Focused, Independent, Reusable, Small & Testable”

And —

“If you’re building components to be shared with the community or even just your team, ask yourself if features in your API will be used by 90% of users. If so, it’s likely pretty core functionality and should stay. If a feature it going to be used by the 10%, it should probably be a separate component or module. Avoid code bloat.”

Great. Now that we got that out of the way — let us go over the list of all that is good about writing componentized code:

• Components are easy to share and reuse: That one goes without saying. If you write code in a component-first mindset, you’ll have a much easier time reusing it in other projects and even share it with others in your team and community. Well-defined components with a clear API and no side-effects are a treat to deal with.
• Components allow for separation of concerns: Writing your code as components makes separation of concerns a natural thing. Each component takes care of a single task or feature. That allows for updates to be pushed more frequently and with greater peace of mind. It will also allow for a common language between the business side if the project and the developing side of it since both are feature-oriented.
• Components make your code easier to test & maintain: That one’s also a no brainer. Writing single-purpose, small and simple pieces of code, makes understanding, testing, changing and replacing your code, a walk in the park.
• Components allow for a more abstract and friendly coding: Last but definitely not least is the ability to deal with code in a more abstract way. That means — components do not require an understanding of the bits and pieces of code, in order to be used. A good component is an abstract entity that is ready to be used in an API-like fashion.

Easier coding

Components allow for more robust development. Pieces of codes can easily be shared, reused, changed and replaced. That means, adapting your app to whatever comes is a lot easier. In a dev-world ruled by components, an app is more like a set of Lego parts, each of them ready to be reused, than a monolithic frightening beast.

From engineers to architects?

Components can even make a new role in the industry — not only engineers but also component architects**.** The former group will deal with concrete code — it’ll make sure it’s written correctly and fully optimized, while the latter group takes the job of composing new apps or molecule-components out of them. It’s a win-win situation. Excellent code made in an accelerated time, with lower expenses.

The Prophets of our time

Within a few years, the history of web development went from the “page age” of JQuery through the “mvc age” of Angularjs and Backbone to the component age of React, Angular and Vue. Web components are almost here.

Many technologies come to mind when thinking of the foreseers of our soon-to-be fully componentized dev-world — but, in an effort to keep this post short and to the point, I’ll skip the shopping-list and name just a few that are, in my own humble opinion, exceptional in the way they push forwards the concept of components into the future. There are plenty more just as important.

React and friends

React surely needs no introduction but I’ll be doing great injustice if I don’t mention it in a list of technologies that “push forwards the concept of components”. React it is an ultra-lightweight frontend framework. It’s so lightweight that it’s hard to consider it as a full framework.

To quote React’s official blog:

“React isn’t an MVC framework.

React is a library for building composable user interfaces. It encourages the creation of reusable UI components which present data that changes over time.”

Why is that important? Well, any technology that truly pushes forward the use of encapsulated and reusable components simply cannot be a heavy framework, otherwise, it defeats the purpose.

React is designed in a way that decouples the two different practices involved in web dev: building and composing.

“React doesn’t use templates. (emphasis added)

Traditionally, web application UIs are built using templates or HTML directives. These templates dictate the full set of abstractions that you are allowed to use to build your UI.

React approaches building user interfaces differently by breaking them into components.”

And —

“Build encapsulated components that manage their own state, then compose them to make complex UIs.”

Looking into the new future, web components will bring forth an inevitable sanitization that will consolidate web development around framework-agnostic components. We can already see it happing (tools, libraries).

Bit

“ In Bit’s philosophy, components are building blocks and you are the architect. Bit just removes the barriers from making that practical…”

Bit makes the forward jump from superficially modular to modular in the full sense of the word. It is an open source tool that lets you easily share and manage your components across different projects and applications.

It tracks your components independently and exports them encapsulated with their dependencies, compilers and testers. Components can then be consumed with package managers, or sourced right into a new project.

Bit lets you control and manage both source-code changes and dependency updates to components across multiple projects and apps, so repositories no longer limit modularity or how much code you share between them.

Bit also makes sure each component is easily discoverable with its component-hub UI and search engine. You can search for components in the organization and even the entire open source community. When you find what you’re looking for, Bit’s live playground renders it to you so you can try it hands-on.

Share reusable code components as a team · Bit

Framer

Framer is a great tool for designers prototyping apps. It’s unique in its landscape because it lets you design actual components written in real JS/TS. It brings newfound modularity into the web design world, smartly leveraging the age of components to bring new possibilities for application design.

With Bit on the developer’s end and Framer on the designer’s end, it seems like a very promising future for those who wish to see application building more like a composition of components, from idea to a fully-functional app.

Components in Framer X are the real deal. Pull them in from production, or create your own from design or code. Get every animation and micro-interaction just right. Create custom UI for every component, and reuse across multiple projects.

A lightning-fast interactive design tool.

Conclusion

Looking into the past, we’ve come from JQuery all the way to React, and are on the verge of the age of web-components and ES modules.

Just imagine how great it will be to have robust and modular apps. To never have to write the same code twice. To be able to deal with code in an easier and more friendly way. To focus more on logic and composition, rather than on the implementation and integrations details of what we’re building.

This is the future of a world with an ever-accelerating software developing.