This might someday be based on a true story. No one can predict the future, but if what I write here comes to pass.. then this article is indeed based on a true story and we will all be dead-ish.
- Development will move towards modularity, reusability and standardization. Composition of components will be the new black. We’ll see the beginning of the steep rise of web components.
- We will see a lot of design systems based on Design-Code-components — components that are 1:1 code and design.
- We fight zombies (those sneaky bastards) and eventually kinda loose…
You’re still reading? Good!
Design systems, which are ever increasing in popularity, brings to the table the idea of modular, reusable, design assets that are being composed into application UIs.
What to do? What to do?
Me: Mirror, mirror on the wall, tell me which framework will be the fairest of them all.
Mirror: React will still be the the most popular, but Vue.js will be a closer and closer second. May I suggest a more standardized way?
Me: How do we create modular, reusable code components that can be used with any framework (or even without a framework) and aligns with the idea of design systems?
One standardized way to rule them all and in the ShadowDOM bind them.
Mirror: Web components. They are like universal puzzle-pieces.
Mirror: Web components consists of three main technologies: Custom elements, Shadow DOM and HTML templates. These can be used together to create versatile custom elements with encapsulated functionality that can be reused wherever you like without fear of code collisions. It allows you to create new HTML tags, fine-tune their properties — from the look, to the internal mechanisms and features of working with Shadow DOM.
Since Web components act exactly like built-in HTML elements they should work within any framework. If your framework can render arbitrary HTML elements, then it can render a custom HTML element. If you’re building an app; Just render the HTML that you want in your template language.
The first to adopt the usage of web components will be the library authors because instead of targeting a specific framework; why not target them all at once?!
Me: But wait a second! What if we could export design assets from Sketch, Figma, Invision or Adobe Xd as a library of web components?! These Design-components will then be 1:1 design-to-code!
Mirror: Yes. The way of creating web applications in 2020 will most likely be to have one of the big frameworks as a backbone (React, Vue.js, Angular, Ember) and have modules and libraries of web components based on e.g. StencilJS or LitElement making up different parts of the UI (I know, I know, I called React a framework).
Even if a company (or project) has invested heavily in one specific framework, it can add new functionality as web components and over time replace bigger and bigger parts of their applications with components built as web components.
Web components will also add re-usability of components among applications build on the micro-front-ends architecture. Applications who’s architecture is based on many smaller teams creating individual parts of the application, each using their own toolsets and frameworks.
It’s a lot of controversy around web components. Just have a look at this article (especially the comments-section). You probably shouldn’t build a complete framework based on web components just yet.
There is a lot of talk going on about design system and ultimately where to keep the “Single-Source-Of-Truth” of the design. Should it be in the design tool or in the code base, or somewhere else completely like design-tokens in a cloud-hosted database imported from application X and then consumed by both design tools and apps?
To achieve a complete two-way sync between design and code, the design-tool must be build on an architecture that, from the start, supports two-way sync. It’s going to be really hard (maybe even impossible?) to implement it into an already existing application like Sketch.
At the time of writing the only design-tool with properly integrated two-way sync design-to-code is Framer X.
We are seeing more and more design-to-code third party applications such as Sketch2React, Anima App and Haiku Animator (to a certain extent). However, these applications are only ”one-way”.
Different companies will choose different design-flow directions. Some will use Framer X, others will use Design-to-code (e.g. Sketch2React) while others will use Code-to-design (e.g. Airbnb).
Just make sure that it leads to closer collaboration between designers and developers and mutual respect for each others crafts. This will lead to a much needed hand-over optimization and a lot less friction between developers and designers.
When Sketch2React releases version 2.x – Sketch, Figma and InVision Studio will have (one-way) design-to-code support; all from within one and the same app! Sketch2React will also provide the output-option of web components!
Design systems will keep growing in popularity which in turn will help to speed up the evolution of design-to-code.
Because of the ever increasing popularity of design systems we will see a fast evolution of Design-Code-components which are either:
1. Code components imported into the design-tool for reuse in design-documents.
2. Design assets exported from the design-tool as code components* for reuse in applications.
* gradually shifting from framework specific components to Web components
These Design-Code-components can then be composed into bigger applications. “Component compositioning” will be a common-place term in the years to come.
This shift in how we design and develop our applications and libraries will not happen over-night. We are at the dawn of a new era when it comes to web development. Enjoy the ride. It’s going to be legendary.
Mirror: Look behind you!
Then we battle the zombie-invasion that snuck up on us while we were bickering about front-end frameworks. We win, but only because we team up with the vampires. The vampires betray us at the end and we all become cool vampire-zombies with awesome futuristic assault-rifles.