Intro
note
Instead of documentation, think of this as a living document on how to solve a bunch of really hard problems. More of a conversation, if you will.
In fact, if (when) you read something you don't agree with or that we got wrong or that you just have a better idea of how to solve, please make liberal use of the chat in the bottom right of your page.
When you should use Rapidream (and when you shouldn't)
We're a bunch of full-stack devs who (just like you) hate wasting our time. And sitting there for hours with a Figma design on one screen, VSCode and Chrome on the other, painstakingly copying hex colors and assets and eyeballing what the flex values should roughly be and then tweaking them over and over until the responsiveness is sort of right, is... well... a waste of time.
So if you're building a design heavy website (e.g. a landing page), there's plenty of design-to-code tools that will take the exact structure of the Figma design and convert them into a perfectly matching DOM tree. And that can be just fine when you don't care much about the code itself, just that it basically looks right.
But that's not where we (or likely you) spend most of our front-end dev time. The timesucks are the web applications, where you've got to have direct control of every line of code, where "div"-itis is a terminal disease, and where you care just as much or more about what the code looks like as you do about what it renders.
Rapidream is tackling exactly this use case. And so we do things a bit differently:
1. The designer does not have any input on the generated DOM tree
Rapidream completely ignores the way that the designer has nested or ordered design elements. We also don't expect or require the designer to "tag" or name any elements. The tree of their design elements may look like a DOM tree, but of course it's not at all.
Instead we examine the design from first principles, working our way from the inside out to determine the ideal DOM structure and element order.
And along the way we also put in a ton of effort to reduce the number of nodes. As long as the design looks right the designer doesn't care if a Card element is composed of four boxes positioned on top of each other, but for a developer it's a non starter. We'll merge nodes wherever we're certain that they can be merged, and the same goes for deleting useless nodes.
info
On an average Figma design, Rapidream will reduce the number of nodes by 50-70%.
2. All responsive styles are recalculated on the fly as you freely edit the DOM tree
The problem with other design-to-code tools is that the code generation is run once and then you're stuck with whatever was outputted.
Our approach is the imperative dream. As you move nodes around or create components or delete nodes, Rapidream will instantaneously recalculate the responsive styles for you.
After all, you know exactly how you want to structure the code and how it should be broken into components, and having first-class support for just that is a core feature of Rapidream.
3. The outputted code and styles are kept as simple as possible
No exotic CSS or some kind of magical hard-dependency on Rapidream. We output good, simple, clean code that you put inside your project with absolutely zero dependency on us or any other library.