No (Front) End

Last week during lunch, I had a conversation with a contractor currently working with us. If he reads this: Hey Barney! đź‘‹ We talked about his experience working as a freelance frontend developer for different companies.

He told me that some companies look for contractors or new developers to help them migrate to a new technology or framework. When he asks for the reason of this change, it’s not rare that the answer is: We like to learn new things.

His experience provoked a question in my head:

What is the goal of the web frontend industry?

My immediate reaction to his story was, that our industry is currently playing a game called: In how many different ways can we build a web site/application? Having thought about this a bit longer I think the problem is bigger than that.

Let’s think about how we do our job.

Improving individual layers

From a high-level perspective the layers frontend developers work with when building web sites/apps are:

Each of them has different problems, which have to be solved and are constantly worked on. If any of these layers improves, frontend developers have an easier job.

Complexity increases

The problem is that improving a layer means adding new possibilities, solving new problems or replacing an insufficient existing solution. Unfortunately for backwards compatibility “replacing” on the web means adding an alternative way to solve a problem without removing the old one.

We have to stay backwards compatible, but it also means each layer becomes more complex — simply because the number of APIs increases and therefore the size of standards and code. Our job’s complexity keeps increasing.

One result of this situation is that the job of a frontend developer starts to be split up into multiple ones: CSS developers, accessibility experts, framework authors, language designers, JavaScript developers etc.

Unfocused progress

What does this mean for the future of our industry? We keep finding better solutions, deprecate old ones, add new features and web technologies keep improving and growing.

I am certain that in 10 years from now, we’ll have a better developer experience and more possibilities on every layer. But is this real progress?

If you take a step back and think about what we do, you probably end up with something like this:

Frontend developers convert a design into code.

Some of us are also involved in the design process and some write backend code too. Nevertheless the end result is an interactive user interface based on some design, which allows viewing and manipulating data of some kind.

Does this sound simple to you? To me it does. And I believe it should be simple. This was the promise of the web. Everything is decentralised and anyone can publish.

On the other hand I know that it is hard for the reasons described before. The question is: Is there so much essential complexity in creating web sites/apps or do we make it hard?

Complexity creates jobs

The reason it is possible for non-developers to publish content on the web today is, that our industry does the hard work of building and maintaining products on these complex layers. The downside is centralization of data, monetisation of it and limiting possibilities of what people can do on their own.

The current situation is great for us. Whoever wants to build something on the web needs us. We have well-paid jobs, because of this complexity and in the future there will probably be even more.

Although the status quo is great for us developers, it is only true to some extent. In my job I enjoy work that is close to the product and has a direct impact on users.

Every developer knows that this is not always the case. There are repetitive tasks we cannot avoid. The better the code base, the smaller is the amount of time spend on those things. Still, it is not possible to completely avoid suffering from the increasing complexity.

One problem, infinite solutions

With every new year of experience I see myself implementing the same problem differently every time. Sure, there is always an improvement in the way I do it and there are libraries/frameworks, but it’s still the same problem.

What I’m wondering is: Are all web sites/applications special? Does every website look so special that we need to handwrite code for it? Is every web application so special, that we need to handwrite a custom API and the code to talk to it?

Why do we need to write code to build web sites/applications?

The missing category of tools

Imagine a tool, which allows defining data types and their relationships visually. Then one can switch to design mode, which works like most graphic design tools, but instead of manually adding text, it references the previously defined data types. It also allows binding buttons to common interactions like adding, editing and deleting that data.

Once this process reaches a state, where you want to publish, click a button and choose a server/hosting provider. Future changes are synced with the server when hitting publish again. Live data from the server can be imported and used in design mode once available.

Thanks to the definition of data types, there automatically is a CMS set up, which people can use. Just invite them an they are ready to add content.

Deploying has multiple advanced options like database, server language and performance optimisations. It uses open protocols and standards, that any technology can implement to make it work with this new category of tools.

It wouldn’t support all data and layout possibilities. It wouldn’t have the same performance as handwritten code. It wouldn’t solve all use cases. But I do believe, that it solves the requirements of most small and medium businesses.

If our industry starts working on these high-level protocols by adding features and improving compatibility, over time these tools would become an alternative for more companies and individuals.

A common vision

I do believe this vision is real progress for our industry:

Let’s enable a new category of tools, which most businesses can use to design and publish websites/webapps without writing code.

Don’t confuse this new category with existing tools, that only cover one step of the process, don’t allow publishing to different technology stacks and often require/allow writing code for some things. This new kind of tool has its limits and embraces them.

We would still learn new things and keep improving each layer. Our jobs would probably become different. We’d focus more on how to improve these tools, their underlying technologies and protocols or handwrite code for the applications these tools cannot cover.

The big difference in this vision is, that we enable more people to build things on the web.

We would start removing us as a requirement to design and publish custom, interactive products on the web.