Most web front-ends communicate with the server using REST-like API, GraphQL or WebSockets. And the UI consists of some layout components, tables, charts and forms. Pretty the same story almost every time, only the design is different.

Yet, many developers are reinventing the wheel, coding everything themselves. The smarter ones use frameworks and UI kits. I belonged to the first group and grew up in the second one.

But still, I had a feeling that it was too complicated - installing all the packages, configuring Webpack, and putting everything together. A lot of boilerplate code. Finally, when you tune the entire setup, you proudly save it as a template for your next project. But when that time comes, you update dependencies and your awesome setup breaks into little pieces. Usually, it looks like a shower of compile errors.

Uh, finally, my setup is working again. Let's build something useful! As your project grows, you are adding more and more boilerplate code just to link together UI components with the data. Even when trying to keep the reasonable architecture, it's becoming a little spaghetti, and it takes more and more energy to keep it clean.

Here I have to add a store, and a few reducers, map the store to the component props, compose the UI and put it together. Sounds straightforward, but actually, it's a lot of code to do a simple thing! I just want to get some data and display them in a simple table. And then I just want to add more and more pages, sections and forms.

I am not even mentioning debugging. How should I know that my API call to the back-end is working correctly? Probably, I need to put some code somewhere to call it and do the console.log (or dump the store). When I do a change, I have to wait until it recompiles and injects the change into the browser so I can see the result. Hmm, this doesn't work. Let's try it this way. Okay, that button click event throws an error - what happened there? I have to put a console.log here and there and try it again.

Boilerplate, compile, reload, console.log, compile, reload, test, boilerplate, compile, reload, console.log. What's wrong with you people?!

I'm talking about SPAs written in React, Vue, Angular or similar tech. But definitely, there is an analogy for server-side generated front-ends as well.

I asked my friends what they hate about software development, especially in the JS world. These are their answers:

  • Boilerplate code
  • Repetitive work
  • Fast-changing technologies
  • Learning how to do X with Y
  • Maintaining old code
  • Debugging issues

How do I imagine my ideal front-end development world?

  • Fast and stable project setup - few clicks, and my dev environment is ready—all the time.
  • Stable but evolving technology - I can count on it in the long term. It won't break my app (often).
  • No or minimum boilerplate - so I can focus on delivering value instead of tons of lines of code.
  • Good reusability - I don't want to repeat myself.
  • Scalable and straightforward architecture - I will learn how it works once, and all the libraries and plugins will follow the rules. As well as my colleagues :)
  • Real-time testing - I change something and can see the result immediately.
  • Transparency - I have tools to test and debug data flows and user interactions. I can inspect internals in real-time.
  • Cloud-based IDE - So I can work on my project from anywhere with anyone.
  • Serverless - I don't want to deal with infrastructure. I just want to put my app online.

You may argue that there are entire frameworks such as Next.js or Angular that solve the mentioned problems. Well, yes, you are right. It gives you a stable environment, predictable architecture and tools like web IDEs with fast refresh and serverless deployments (I'm talking about Vercel here). But the entire editing and debugging experience are far from what's possible.

Still, you have to write a lot of boilerplate code to link things together. And you have to think imperatively. And there's a much better way - to think declaratively.

Summary

I love to code, but even more, I love to build useful software. And I want tools that allow me to go from ideas to production-ready apps efficiently.

And that's the reason why I've started using the blueprint-driven development and why we've founded Adapptio.

In the next chapter, you will learn what blueprint-driven development is and what's are its benefits.