The “Design-to-code” VS “Design-as-code” narrative

the “design-to-code” narrative represents converting design made in ideation tools into a coded format. 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, your design lives as code, which has many benefits! in our case, we help design teams create presentational ui components and handle deploying, versioning, and operations to maintain a software product. developers can continuously consume the components and easily plug whatever they need into them 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 the presentational aspects, wouldn’t they interfere with the developers’ work?

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 written 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 a “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.