Launch HN: Pagedraw (YC W18) – Compile UI Mockups to React Code
Pagedraw lets you annotate mockups with extra information (like how to connect to the backend, resize for different screens, etc.) to get full, presentational, React Components. They’re React Components just like any others, so they can be interleaved freely with handwritten ones. They don’t require any new dependencies and work well with any existing JSX build system.
You can import the mockups from Sketch or Figma, or draw them from scratch in Pagedraw.
Working as full stack devs, we constantly had to do this translation by hand. It was our least favorite part of our jobs, since the creative work had already been done by the mockup designer. It's so repetitive and mechanical that we decided to stop hand-coding divs and css and write a program to do it instead.
There have been many attempts to automate this stuff in the past. For 20 years, people have been trying to solve the problem with tools like Dreamweaver, Frontpage, and so on. Broadly speaking, they tended to fall into one of two buckets, each with their own problems. In one corner are tools like Dreamweaver, which can produce correct code but have to expose some of the underlying HTML model, making their users play a puzzle game to do something as simple as move an object around. In the other corner are freeform design tools that generate position:absolute code. That doesn’t work if you care about working on different screen sizes, or reflowing the layout around variable-length content as simple as “hello <username>”.
We think the problem is that you have to look at it like a compiler. Past tools never fully worked because they tried to unify two fundamentally different mental models: the designer’s mental model of a free form canvas like Sketch or Photoshop, and the DOM’s mental model of <div> followed by a <p> followed by an <img> and so on. What always happens is one of two things: either the computer’s mental model is imposed on the designer, or the designer’s mental model is imposed on the computer. The former results in a clunky design tool, and the latter results in position:absolute.
What we do instead is recognize that these are two fundamentally different models. Designers work with Sketch by saying “put this button at this pixel”. We can let them do that and still generate flexbox code without positon:absolute, and let everything resize and reflow correctly. Pagedraw does it by inferring constraints from the relative geometries in the mockup. For example, if object A is to the right of object B, we infer it should always remain to the right, regardless of resizing or content reflowing. Sometimes, the developer does have to ask the designer about their intent regarding resizing, which is why Pagedraw also needs you to annotate that information. We then compile those constraints, inferred and annotated, into HTML layout mechanisms like inline-block and flexbox.
It turns out that a lot of other nice things follow from a compiler-like architecture. For one, we separate codegen correctness from codegen prettiness by cleaning up the generated code in discrete optimization passes. Another is the ability to easily retarget for AngularJS, Backbone, React Native, and so on by just swapping the compiler backend. We even have some nice editor features that fell out from hacking a Lispy interpreter onto our internal representation.
We’re excited to see what you all think and hear about your experiences in this area! You can try it at https://pagedraw.io/
124 comments
[ 3.2 ms ] story [ 198 ms ] thread> Working as full stack devs, we constantly had to do this translation by hand. It was our least favorite part of our jobs, since the creative work had already been done by the mockup designer. It's so repetitive and mechanical that we decided to stop hand-coding divs and css and write a program to do it instead
This is definitely repetitive and annoying, just to add another data point to your own. I think people fundamentally want excellent WYSIWYG tools, it's just that the implementation leaves a lot to be desired usually (e.g. Frontpage). Really glad to see someone take another swing at this.
Quick nitpick: One of the links on your homepage ("Learn more") is broken (https://documentation.pagedraw.io/worfklow, looks like it's missing a trailing slash)
UPDATE: the tutorials just loaded... looks AMAZING!
If I could drop support for it completely I would open up a bottle of champagne. It truly is the new IE of the web.
Unfortunately, while most of the editor works in all browsers, getting full support is really hard. We're doing a lot of things that get pretty deep in the browser, so we wanted to lock things down as much as possible.
We almost were electron-only to ensure consistency, and can still give you the electron app today. We felt it was better to launch with Chrome + Electron than just Electron for an optional installation-free experience, which is why we only support Chrome.
I'm personally really sorry as an engineer that we don't support Firefox, Safari, and other browsers yet. It's on our roadmap :)
As soon as I saw it was Chrome only, I closed out.
For my part, I look forward to trying the product!
By supporting only Chrome, you're showing that you consider Firefox/Safari/Edge as second class citizens, making it harder to trust that you will keep supporting non-Chrome browsers in your generated code.
Rule #1 is do feature detection not user agent detection. What are you doing that is "pretty deep in the browser"? NaCL? Experimental Chrome features?
It's the same mechanism we'll use later to let you choose between React, Angular, React Native, ERB, etc.
The name in the UI is Text 4, the prop is text3 and the css class is text_4.
That said, I’m totally in love. Can I just ask for Typescript generation, please? (UPDATE: My god it’s already there in the full version - Thank you!)
https://documentation.pagedraw.io/data-binding/
> You can import the mockups from Sketch or Figma
How do I import Figma designs? I tried the Sketch import, doesn't work through that.
Excited to use this. Congrats on your launch.
Also I think that Vue is arguably more straightforward than React in the minimal model-view one-way binding use case. Whereas React is a subset of the more general functional reactive programming model and will probably be outpaced at some point with something language-agnostic.
The reason why I ask is that I tried importing several semi-complex but not uncommon (structure wise) files and I got an error saying that I should make sure that the file is correctly formed.
That right away is bad UX. If the designers need to reformat or change the behavior of their files, then they need to be part of the user journey. Right now there's nothing of that as far as I can tell.
Probably a bug on our side. Could you try emailing the Sketch file to team@pagedraw.io and we'll see if we can debug it?
I feel that eventually, you will need to set a certain standard. Not because is required on your side, but because this is how every designer/developer relationship should work. People just don't know how to do it because there's no standard or methodology. Think how horrible would be if developers didn't have Git to collaborate... Well, that's basically the state of developer-designer collaboration. I think with this product you guys are in a good position to help solve this problem.
Internet Explorer all over again. ️
I don't agree. Especially for a startup trying to get an MVP out the door.
If your product is aimed at a technically oriented audience then its a reasonable assumption that they have Chrome installed.
If you don't learn the history of technology, you will be doomed to repeat it.
How does it work with CSS?
I often get a new version of a sketch file now and then and would need to import that new version while keeping/updating the old components I already have
We're pretty proud of the mechanism (it fell out almost for free from our live collaboration mechanism!) and will almost certainly blog about it when we have time.
https://documentation.pagedraw.io/sketch/#bring-in-future-in...
Can I get this on my desktop? (In other words: Can I work on this from a plane?)
I don't see anything about pricing in there, so using a web service (and having to log in...) to use this, I'm not super happy about. Balsamiq has a good system: They have both a desktop and a web version, let you import/export between the two, and charge you for licenses and online storage.
[edit: And furthermore, if you do a desktop version, you can also do it as a vscode extension, that'd be super cool]
I'm using the latest version of Firefox... what features does Chrome have that FF hasn't?
I get it's early stage, so you might have just done a blanket 'If not Chrome show message' check.
If the latest version of FF can support, I would do a more fine grained check.
Will check with Chrome later...
So luckily they can fix this issue by re-generating their site, using their site.
Based on the feedback in this thread we're going to bump up the priority of this concern. Getting this kind of feedback is why we're doing this launch thread, so we really appreciate it.
- What was the thinking behind supporting only Chrome?
- For a tool that support cross-browser, wouldn't it expected that tool itself runs on multiple browsers?
- Is it really reasonable not to spend time to support multiple browsers and have let possible first adapters to have bad taste with the product ?
Super excited for the Figma + React-native support, I think ~20% of my time this past month was converting our designer's figma sketches into react native!
tl;dr: would you like the Electron app instead? It's available at https://documentation.pagedraw.io/electron/
It was tough for us, because we're big believers in the standards-based web. We 100% promise that all the code we generate works across all browsers.
Our editor was almost electron-only, but felt it was better to launch with Chrome + Electron than just Electron. Our editor isn't a normal webpage; it's doing all kinds of crazy nonstandard things webpages shouldn't do. It's only in the browser at all so we can re-use a web engine as our editor's rendering engine, since we occasionally show you snippets of compiled code.
I'm personally really sorry as an engineer that we don't support Firefox, Safari, and other browsers yet. It's on our roadmap :)
>all kinds of crazy nonstandard things webpages shouldn't do
- we do a lot of work with the selection/focus browser API, which doesn't always work the same / have the same APIs
- until recently, Firefox had a different opinion about where an outline should go wrt positon:absolute children
...and what seems like a million more little things. We decided it was more practical to do Chrome + Electron (basically the same) than try to cover every browser where the standards don't exist or aren't met, since we're touching a lot of surface area and weird corners of the browser.
Anyway, will try out the Electron version and definitely be keeping an eye on this one...
I've worked on React Studio (https://reactstudio.com), which is pretty similar. We also used the compiler metaphor to describe it. The original codegen targets were iOS + Obj-C and Android + Java, and later we built Tizen + C (at a customer's request on their bill) and then React + JS in an attempt to reach a larger audience through a free app. My regret is that we ended up with a sprawling native Mac codebase at a time when a lightweight cloud solution would be more suitable for the average interested potential customer. Oh well. It seemed like the right choice back when generating Xcode projects was the target...
If you don't mind the question, what's your monetization strategy? Right now Pagedraw looks to be completely free, and that's where we ended up with React Studio too. Business-wise, the only thing that's sort of worked for React Studio has been to make customized enterprise editions for large customers. I'm curious if you have something in mind that doesn't involve enterprise sales hell :)
Having said that, this looks like it could provide a great starting point for development.
Do you see this product as a tool for developers or a tool for designers to publish their creations directly to the web?
Pagedraw is not a code free tool. It never will be. I don't think it's possible either.
Programming needs to happen in language. Even if you did something like Scratch, (to which I prefer typing,) you still need the arbitrary constructs of language in order to express whatever you want.
Pagedraw is not programming, which only works because we don't really think HTML and CSS are either.
You will absolutely still need to write code to make novel algorithms and custom business logic until the AGI revolution comes. Pagedraw is meant to be used side by side with code implementing the business logic, state management, and anything else novel about your app. Pagedraw will take over more and more of the non-turing complete parts.
Today, with Pagedraw you write state management and API code just like you did before.
> Do you see this product as a tool for developers or a tool for designers to publish their creations directly to the web?
Yes. Both, eventually :) Today the product is a strict replacement for HTML and CSS, so it's something a developer would use to bring designs into production after the designer's done with them.
I'd beg to differ; I don't think the scenario is as clear cut as you suggest, because there are a huge number of ways of developing FE for a design. Lots of compromises inevitably need to be made, and lots of choices need to be taken.
Humans are great at filtering and choosing based on experience, instinct and an understanding of industry norms / best practice .. and are able to continuously update their 'mental model' of the options available.
Having said that, tools that help to take the repetitive strain out of developing for FE are a great idea. I just wouldn't look to such a tool as a panacea.
Did you get to https://pagedraw.io/tutorials/basics? It's the button in the first section that says "Continue to demo"
I couldn't find any reference to this in your documentation. Exactly how easy and/or do you have any samples projects I can check out? ReactNative would be my primary use and I assume alot of other potential users as well.
Do you have plans to open source the backend ? So devs over time can make it even smarter for all sorts of use cases ?
Open source and profitable are orthogonal things. You can still be profitable and build a solid product with a raving community.
We're huge on backwards compatibility (and think everyone should be), which is why we don't want to expose something we haven't stabilized yet. We'll have a way to export our just-before-codegen internal representation (shame on me for forgetting the PL term) once it settles down a bit. It's very much like a DOM, so there's not too much craziness there.
We'll be launching a bunch more backends in the coming weeks, so there's a good chance we'll have first-party support for your favorite framework anyway :)
This is a great first minimum delightful product. Good job.