developersBuilding trust with developersWritten by Emil Sjölander on Tue May 05 2020

Visly operates in the design-to-code tools space. We know it’s no secret that many tools before us have promised to take designs and automatically turn them into code, but failed to be taken up by developers. But we also believe the main problem is that these tools were built first and foremost with designers in mind, disregarding developers, and the practices they employ in building high-quality applications.

We’re doing things differently.

Our mission

We aim to improve collaboration between designers and engineers. We believe tighter collaboration leads to faster development cycles and higher quality products. I'm personally trying to re-capture the experience of working side-by-side with a designer, an experience I was lucky to have as an engineer at Flipboard. Today, teams talk about design handoff in a segmented way, as if design is something that gets finished and then handed off to engineering. But this isn't how companies should think about it; design and engineering is intrinsically a collaborative, back-and-forth process.

We think the way to achieve this is by enabling designers to manage design end-to-end, from initial sketch to production code. But essential to this is one thing: developer trust. For this to work, developers need confidence that using Visly - and collaborating with designers in this way - doesn’t harm the stability, quality, performance, or flexibility of their codebase. We believe these points are absolutely key to allowing us to succeed where other tools haven't.

No lock-in

For us, it’s incredibly important that you own your code and that you don't feel locked into Visly. This means all code lives on your machine and is checked into source control. If Visly would be shut down tomorrow (and don't worry, it won't 😝), then all your code would continue working and not a single one of your users would be impacted. You could stop using Visly at any time, but continue to use the code it generated for you. For this reason, we believe it’s important to keep the generated code as close as possible to what you may have written yourself.

Not only does all code live locally on your machine, but there is also no processing on Visly or third party servers required to build your app (Visly does collect a small number of anonymous usage statistics and does offer additional add-ons such as Github integration that do require Visly server access). This means you can build your app, or even develop new components in Visly, regardless of whether you are online or not.

A focus on developers

It's just a file - Much like when writing code, any changes you make in Visly result in a file on your file system changing. These changes are recorded by your version control system, allowing you to make use of branches, revert bad commit, and stash changes for later. This model also ensures Visly works seamlessly with hot-reload and other must-have features of modern web development.

Clean code - The code that Visly generates should look very similar to how you may have written it by hand. For every component, we generate a JS which includes the JSX code to render the component, a CSS file with styles, and a typescript definition file to document the props of your component. The code is minimal and the CSS is self-contained so that it cannot affect any other elements within your app or website.

Accessible by default - Where possible, we automatically output semantic HTML, and otherwise all the necessary aria attributes to ensure an accessible UI. Accessibility is not easy to do correctly; using a tool like Visly should hopefully make it much easier since Visly has enough context to automatically do this in most situations. If you’re using Visly today, you’ll notice we still have a ways to go here. We've made this a priority to improve before our public launch. Read more about how we think about accessibility.

Keeping bundle sizes small - Due to our compiler’s ability to output the minimal amount of code needed and a lack of any runtime dependencies you aren’t already using in your app (like React), we are able to get very close to handwritten code in terms of bundle size impact. In future, I think we can even outperform handwritten code.

Open source - We plan to open-source many of the core components of Visly. This benefits the community as a whole, whether you are using Visly or not. It also benefits us directly as we start to look into APIs for building plugins. While this is still very much a future plan, we've made a start by open-sourcing our flexbox engine. This is the engine that powers the yet to be released Android & iOS Visly components.

Striving for compatibility

We strive to be as compatible with your existing codebase as possible. For the vast majority of projects, this means you don’t need to change a single line of code or configuration. Visly will just work. Whether you have an app with millions of lines of code, or you just recently ran create-react-app.

The key to making Visly easy for you to start using is making it work with your existing code. If you're starting an app from scratch and choose to use Visly, we definitely recommend creating your design system and most of your UI components directly in Visly. However, if you have an existing app, we actually assume you won’t be converting all your components to Visly on Day One, or ever. Instead, you probably want to start small, moving over some design tokens like colors, fonts, and icons. Then you can try implementing a button or two before finally, once you have gotten a feeling for the workflow, starting to implement larger UI components and even porting over components that were built before you were using Visly. You can read more about how we think about incremental adoption here.

Visly is built with Visly

The only way to ensure we hold ourselves to the high standards we've set out for the product is to use it heavily ourselves. That's why we've built Visly with Visly. Much like all of you who may just be trying out Visly for the first time, we didn't start out doing this. We migrated our application over time. By now, all our assets, as well as dozens of UI components, are implemented in Visly. Not only does this allow us to focus our code on business logic, but it's also enabled our design team to contribute pull requests to Visly without any prior coding knowledge, as you can see below.

In conclusion

Visly is built for a future where designers and developers collaborate on a daily basis to build well-designed product experiences, with designers feeling confident managing design all the way to production code and developers excited to empower them to do so. To achieve this, building developer buy-in and trust in the code Visly generates is the essential first step. Using the product, we hope you'll agree 😎

If you have any questions about Visly or comments on the article, please reach out over email or Twitter. If you want to give Visly a try, please request access here.