To code or not to code: that is the question.
While both programmers and visual developers will present their own reasons for why one is better than the other, the answer is much more nuanced.
UI engineers often cite 3 reasons why they prefer to write code:
Ability to use full syntax and APIs without artificial limitations
APIs are messy, there are bugs, and oftentimes workarounds are required to get around limitations. But that’s the thing—there are workarounds. It’s rare to hit a limitation, and even if you do hit some sort of limitation, there’s probably a workaround for it. This is because there aren’t walled gardens. There aren’t limitations caused by abstraction that can prevent you from achieving what you need by whatever means necessary.Ability to use frameworks and various rendering techniques
Programming frameworks provide developers with tools and best practices that simplify developer workflows—a lot. Not only do frameworks make programming more efficient, but they also increase security and reliability. By using standard practices, you can focus on the unique aspects of your application, rather than infrastructure. Plus, frameworks can be constantly updated and improved by the developer community, so that you’re always up-to-date with best practices.Ability to reuse code from anywhere
Programmers are notorious copy-pasters. A ton of code that powers the web is not written from scratch. Developers copy-paste from various resources, including the same code-base—and as of recently, AI assistants. This is great, because code gives developers ultimate flexibility to aggregate its functionality into a powerful product. Rather than having to start from zero or learn how to replicate certain functionality you may want, chances are that there’s already code out there that you can leverage for your own build.Lots of maintenance
Code-based development has generally a lot of syntactic nuances that change functionality in dramatic ways. A space or comma is often the difference between broken and working. This means that it's up to the developer to organize code in a way others can understand and ensure consistency across the entire code base. Given that there are often multiple developers developers working in a codebase—each with their own way of writing and organizing this code—this is one of the most challenging aspects of coding.Disjointed feedback loop
When building UIs, you're usually working in a text editor, while the product you're building is rendered in the browser. This means that there's a strong disconnect between writing the correct text and getting the correct rendering. In an ideal world, building a UI should happen through direct manipulation of that very UI on a canvas, so that you don’t have to process all the translation from code to rendering in your head.Inadequate designer and developer hand-off
Designers typically focus on designing, and developers typically focus on developing. This means that when it's time to translate a design from a different platform or media (e.g., Figma to CSS), it's difficult to specify all aspects of the design. This is because the differences between the design and development aspects get lost in translation. As a designer, not only do you have to explicitly express everything for all supported device resolutions, but you also have to convey the design system in a uniform way that becomes translatable for the developer. This process becomes exponentially harder if you also have to convey animations or interactions. The lack of clarity and uniformity leaves a lot to be desired.Maintenance reduction
While it's not universally true for all design tools, on principle, using a visual tool provides a more intuitive interface between humans and machines. A UI that translates visual manipulation to a strict set of guidelines ensures that the exact same output is produced no matter who was using the interface. This eliminates a lot of the syntactical and semantic complexities when writing code. Moreover, the difficulties of expressing the correct semantics with code so that someone else can understand are reduced.Feedback loop
The UI becomes the translation layer between the human and computer, which means that the feedback loop is instantaneous. With that said, it's still up to the software's UX to allow users to see all aspects of the build quickly and correctly.Removing or minimizing the handover
Whereas code typically requires hand-off between a designer and developer in order to bring the build to life, visual development empowers the designer to actually implement the visual components and systems they designed—without writing code.Lots of vendor lock-in
The platform you choose to build on becomes the visual language you rely on. This can come at a price, since the learning curve for many platforms can be steep. After all, more complex build requirements require more complex platforms. In addition to the platform's visual language, this also means that you become dependent on the company and people who run it. If the platform you invest time into raises prices, changes features, or ultimately closes down, you're forced to pivot in one way or another.Not everything is easier to express visually
There are many aspects of software development that are easier to express with code than with a visual tool. For example: when it comes to complex logic or integration points with existing platforms, the flexibility code provides is currently unmatched.Opinionated rendering
When a visual tool is too opinionated and controls the entire end-to-end building process, producing code may suboptimal, because those opinions simply get translated into code.Integration with developer processes
When it comes to designer and developer collaboration on a complex product, design tools that can’t follow developer processes are hard to integrate. With that said, not everything can be visually expressed in a simple manner. This means that a lack of integration with traditional developer processes creates shortcomings for visual development.No vendor lock-in
Webstudio Builder is open source, which means that you're not trapped in a walled garden.Expressing development visually
Webstudio’s focus is the UI—a tool for responsive design and built for the web. Webstudio itself doesn’t solve the complex logic problems for you, but rather aims to help you solve them by providing code-components with the logic you need, and then integrating them with the visual components. If you need custom logic and you're not a developer, you can let a developer write a code component, then keep visually building the rest on top of it. The goal is a seamless collaboration between a developer and a designer.High-quality UI
There are various approaches when it comes to building a UI. Webstudio’s approach stays close to web fundamentals: HTML, CSS, and HTTP. Webstudio doesn’t hide these fundamentals, but rather surfaces them visually. The interaction with the UI provides you with tools and tips intuitively as you tinker with the platform. This approach is fundamentally similar to Webflow, with changes and improvements that'll be highlighted in a future article.Unopinionated rendering and security
Webstudio’s architecture is designed to support any rendering approach you may want. We achieve this through third-party code and SDKs. The goal is to be able to swap the components and frameworks used on the canvas. SDKs can be written by the user or by the community. Webstudio's default SDK is written using Remix and React, but in the future, we'll also have SDKs based on frameworks like Vue, Svelte, Solid, or just plain HTML/CSS and web components. The power of open source will inevitably lead to an open ecosystem given enough time and engagement. Most importantly: there’s no need to trust the user’s custom code or custom SDK. Webstudio’s hosted architecture deploys using Workers, which is a zero-trust environment. If you write custom code, only your project can be affected by it. This means that a third-party code-component can’t steal any data from your project, except what's available on the current page where the component used.Seamless integration with developer processes
Webstudio's idea of integration is simple: developers should be able to use their tools of choice. For example, if you are used to Git, VSCode, and the CLI as a developer, you should be able to publish components to the Webstudio project without leaving those tools. If you want to integrate the UI that was built in Webstudio with a custom code base, Webstudio will allow creating pull requests for UI changes made in Webstudio Builder without needing to leave it. This allows the publishing pipeline to be fully controlled over the platform of your choice (e.g., GitHub or GitLab). Developer-oriented workflows play a critical part in Webstudio’s vision.The ideal world is a combination of visual development and coding, often referred to as “low-code.” The balance between both will depend on the product you're building. For example: a landing page can be built 100% visually. Sprinkling code components onto that landing page would decrease the visual aspect, and increase the traditional code aspect.
Webstudio can be used in multiple ways. If you decide, for example, to visually build the design system components, but also build a complex application separately, Webstudio's responsibility becomes the design system, and nothing else.
So how can you know which approach is best for your project? Here’s the guiding principle:
Use no-code tools as much as possible to benefit from their speed and ease of use. Then you can choose to add code to enhance the project, or export the code that was generated by the tool and use it any way you like.
Keep visual development accessible to a designer, and involve developers where needed to build integrations and components—without turning a designer into a developer, and vice-versa.
