The “Design-to-code” VS “Design-as-code” narrative
The “Design-to-code” narrative stands for converting design that is made in ideation tools into a coded design. Why is it a narrative? Because there is another narrative. The “design-as-code” narrative — Our narrative.
Relate is a “design-as-code” environment that lets you ideate in the actual medium, the web. In other words, you design lives as code, which has many benefits! In our case, we helps design teams create presentational UI components, handle deploying, versioning, and operational stuff to maintain a software product. Developers can continuously consume the components and easily plug whatever they need into it while focusing on logic.
Our goal is not to design a bridge (or a system of bridges), but to provide designers with a gateway to the web medium. As soon as they enter, there is no need for bridges. They communicate in the same language as the original islanders, the developers, who keep the code as the source of truth.
The issue I have with “design-to-code” is going through the following question (and I may not have a definitive answer) — Is it even possible to expect developers to consume code generated by traditional design tools? In what ways will it be integrated with developers’ components? Since these components go beyond solely the presentation aspect, wouldn’t they interfere with the developers’ work?
Let’s imagine someone took it very seriously and built the ideal “Design-to-code.” The design is beautifully translated into a production-ready piece of code. So if I’m making a commercial website, I’m fine! But what if I’m building a complex software product with complect design, with another ten designers and 30 developers. Now what? How do developers add functionality on top of the exported code? What if they have modified the code, tweaked it, and wrote their functionality on top of it? How do I maintain a system?
Where do designers and developers find the best ground for mutual success?
While the “Design-to-code” Narrative is engaging, we see it as s “honey-trap.” The problem is that these tools speak a particular and non-standardized language, so translating it into code requires a lot of underlay algorithmic work. Many players on the market are now fighting this war, and our hearts are with them.