If something dont work on firefox i just dont use it, i am doing that for some time and it´s been great to me, others should do the same and tell the product owner that, so them make more acessible products from now on
Babel (specifically, babel-preset-env, which I assume you're referring to) only ensures that your code's syntax can run within a given browser. It doesn't make sure all the web APIs and browser features you take advantage of are compatible, or that they produce the same result.
Pagedraw looks very polished. I can take some wild guesses why it didn't succeed but glad to have it live on as open source.
My best guess would be that it either did too much or not enough. Getting an extra developer's worth of productivity from a tool is great but there could be other ways to make gains as noted in the shutdown page. Visual editing is a different way of programming and can be more or less productive depending on specifics. I recall doing some IBM DirectTalk voice/telephony app dev using a visual flow editor--it was the worst. There are of course success stories like the original Visual Basic 1.0. Xcode and autolayout is less productive but more expressive.
On the doing less side, are there tools for parsing/editing/outputting HTML+CSS rather than a full React integration? I've worked with designers that used Figma or Zeplin but we only tended to export the graphics and copy/paste the styles.
> On the doing less side, are there tools for parsing/editing/outputting HTML+CSS rather than a full React integration?
I worked on a thing like that for a long time. I wasn't trying to "draw" HTML and CSS, but rather I wanted a way of building rich and structured content in a natural and visual interface without sacrificing control of the markup. I ended up bogged down because little by little it tried to be a design tool, and I ended up with a complex project that doesn't do any one thing very well.
It's on the back-burner for now, and it may end up open source. Link below:
Drag and drop a UI in powerpoint with your layout, and poof, you get a UI in HTML/CSS. Don't try anything too complex or fancy, and take a look at the limitations.
I haven't published on Show HN yet, still a work in progress - but a side hobby of mine
Would a member of the Pagedraw team share a postmortem? Seems like this is a huge need and will be the future state of web / mobile design - what stopped you guys?
I think the reality is, no matter how awesome and impressive these tools are, they just don't seem to have a fit in the market.
Prefacing this with the fact I don't know all that much about the product, only a quick glance
For a big team of developers, building a big website with complicated interactions or requirements, a tool like this isn't going to meet all the requirements the developers have
If you're building something simpler, then you're probably better served by something like Webflow or Squarespace.
At a high level, that makes some sense - these tools might not be the most practical way to get from point A -> point B today for a typical web or mobile app.
In my head, I'm wondering if they are just way too early? Going from design -> code -> UI is, in theory, less efficient than just going from design -> UI, in a programmable, customizable, scalable way.
Skuid, which is a page builder for Salesforce (now branching out to more platforms) is doing very well.
At the company I work at we are going to switch away from it due to the limitations you insinuated, but there's definitely a fit for it in the Salesforce world.
Thanks for this - interesting that you focused the postmortem on technical lessons (other than #1).
I'm super curious around what the sales strategy was.
I'd imagine for devs, it would have to be around productivity (time saved by exporting vs. manually coding, adherence to consistent CSS standards, etc.).
For designers, I would imagine it would be around taking more of the software dev lifecycle - e.g. designers can now eat up part of the value that front-end dev provides. Based on that, designers should be more in demand, paid more, and so on.
Those seem like huge levers to pull from a PMF perspective, but to your point, maybe it all sounds great until you get into that conversation, and it's really not something that teams are looking for (at least right now).
Probably the same as every other attempt at this since the mid 90s. People who can code front-ends don't need such a tool. People who cannot code front-ends hire people who can, and still don't need such a tool.
Not all UI-builders are a fail. Visual Basic, Qt, Delphi, MS Access all had/have some very popular and useful UI-Builder. There is always a middle between no skill and high skill.
It’s a pity they’ve shut down, though hopefully it can live on somehow as open source.
There’s a lot of activity in the Sketch/Figma/whatever to React space at the moment, including Hadron [0], Alva [1] and Lona [2].
There’s a real gap in the workflow between design - basically a drawing - and working code. Handoff tools like Zeplin help, but it seems redundant to build everything twice, first in a design and prototyping tool, then again in working code.
However I’m not sure where these tools fit in, as a team that uses React in production would have the skills - and would probably prefer - to dive in with code, rather than use the output of a code generator.
It’s meant to make things easier, but the tech is so complicated it’s way out of reach of those who might actually benefit from it.
>There’s a real gap in the workflow between design - basically a drawing - and working code.
In tools like Sketch and Figma you're digging for the underlying visual rules, one "component" or layer can have a ton of variations, and I can quickly compare and compose them side by side on a canvas. You build an evolving system to build design systems from.
In code you're implementing the version or composition that made it, one composition. Unless you can move, juggle and manipulate items as convenient as in design tools, exploring compositions with code is a much lesser experience for a designer, even if he can code.
To make tools that generate React/Vue code work well you have to go far and beyond what most of the front-end oriented tools currently do...At Codesolvent we're taking a different tack..some samples:
yes we do have users, there is a cloud hosted version in the works.
It is an object model based solution so it does take some getting used to...basically imagine your vue/react application constructed as an object model, the product provides a UI environment for creating and manipulating that model.
Of course there is always room for improving the workflow so what you see today is definitely not what we envision the final state to be. What we are really excited about is the underlying tech which is going to allow different UI based solutions.
I was tasked by my company with using Pagedraw in the early days. The team behind it was extremely patient and helpful and would literally fix bugs in real-time. I would keep an eye on them and look out for their other products. Good folks.
> Ultimately, we think Pagedraw is the wrong product. We think you can get 90% of the benefits of Pagedraw by just using JSX better. Our findings on this will be controversial, as they go entirely against the current “best practices,” so we’ll save them for a later blog post.
There is certainly a grey area for tools that are too limiting for developers and require too much setup for designers to use out of the box.
We've been working on solving this problem for over two years with a decent sized team. Designers and developers use different tools that don't understand the same formats causing hard handoffs and conversion steps to get a digital product to the customer.
This is an extremely ambitious problem to solve because it requires building an entire Wix or Webflow that also speaks and outputs some sort of web component (in our case React). It needs to allow designers to work in a completely visual way without worrying about tools like Git while developers can at the same time add logic and state to the otherwise static design. You have to remove all hard handoffs that fork the source of truth and keeps ideas from flowing from the canvas through the development pipeline. InVision and other tools are "glue" that attempt to solve this, and they definitely make things easier, but the handoffs are still there.
Many of the tools I'm seeing get close, but they don't go all the way because it would be insanely expensive to replace all the tools in the pipeline (InVision included) and make a single environment that everyone works in to produce a full UI from blank canvas to prototype to production. Gamers have Unity, that's what we need in the web/native app development arena.
We've been working on it here: http://www.shift.studio. While I'm sad to see Pagedraw go (and I've reached out about getting lessons learned from the founder who responded and was extremely helpful/nice), I still believe this is a good idea and we are going to push forward and get it done. I also really love seeing that others here agree that something like this needs to be built.
I would love to hear from HN, what do y'all believe is the fundamental list of features required to tackle this? (no matter how bold/crazy the request)
Agreed a Unity like toolkit for general purpose UI would be awesome. I would be happy to pay a reasonable subscription for such for my team. A killer feature for us, would be easy wiring up of forms and display grids to Postgresql functions and views for storage and IO - we don’t want direct to table. Maybe you could somehow incorporate PostGrest for this.
Tried to open the demo and got an "Only Works in Chrome" error page. That doesn't give me a lot of confidence in the tool, as my audience for my UI should be larger than just one browser, and I know that I have to test in multiple browsers.
I don't think the output from this tool is necessarily non-compliant with other browsers. This tool/app itself might be - and I think it's OK given it's audience (web developers) who anyways overwhelmingly gravitate towards chrome for it's superior debug tooling
Hmm I was desperately looking for something like this and only ever found was Framer X. Strange I never came across this but definitely excited to give it a go!
hey, I'm currently building an app in this space - could I ask you a few questions about what you're looking for? My email's in my profile if you're interested.
"Ultimately, we think Pagedraw is the wrong product."
So what does this mean? Does it mean it is the right product when it is open source, or is the code being made open source just for the purposes of archiving?
Or now that it is open source is it seen that it might become a more useful tool?
Actually, it's not that hard to build a UI Builder for React.
Just output normal HTML, then transpile to JSX.
For method handlers, transform into Redux actions.
And you've done.
"Sorry, our editor is optimized for Chrome"
Please don't fall for the monopoly. Spend a little time and make it work everywhere, for the sake of the open web
I went to write the exact same thing. I fear this will only happen more and more once edge becomes chrome... It is a sad state of things.
If something dont work on firefox i just dont use it, i am doing that for some time and it´s been great to me, others should do the same and tell the product owner that, so them make more acessible products from now on
Considering it was a failed product, made open source, I don't think they were necessarily concerned total browser compatibility.
How does this happen when you compile through Babel?
Babel (specifically, babel-preset-env, which I assume you're referring to) only ensures that your code's syntax can run within a given browser. It doesn't make sure all the web APIs and browser features you take advantage of are compatible, or that they produce the same result.
Where are you reading that?
https://pagedraw.io/tutorials/basics
If you visit the linked tool in Safari on OSX that message is what you get.
Pagedraw looks very polished. I can take some wild guesses why it didn't succeed but glad to have it live on as open source.
My best guess would be that it either did too much or not enough. Getting an extra developer's worth of productivity from a tool is great but there could be other ways to make gains as noted in the shutdown page. Visual editing is a different way of programming and can be more or less productive depending on specifics. I recall doing some IBM DirectTalk voice/telephony app dev using a visual flow editor--it was the worst. There are of course success stories like the original Visual Basic 1.0. Xcode and autolayout is less productive but more expressive.
On the doing less side, are there tools for parsing/editing/outputting HTML+CSS rather than a full React integration? I've worked with designers that used Figma or Zeplin but we only tended to export the graphics and copy/paste the styles.
Here's a postmortem-ish https://medium.com/@gabriel_20625/technical-lessons-from-bui...
> On the doing less side, are there tools for parsing/editing/outputting HTML+CSS rather than a full React integration?
I worked on a thing like that for a long time. I wasn't trying to "draw" HTML and CSS, but rather I wanted a way of building rich and structured content in a natural and visual interface without sacrificing control of the markup. I ended up bogged down because little by little it tried to be a design tool, and I ended up with a complex project that doesn't do any one thing very well.
It's on the back-burner for now, and it may end up open source. Link below:
http://www.cicerone.co
Yes, there are tools that output plain HTML/CSS.
For example, we (Anima - YC S18) are doing it (https://www.animaapp.com)
are there tools for parsing/editing/outputting HTML+CSS? Yes!
Creator of Airppt here -> https://airpptx.github.io
Drag and drop a UI in powerpoint with your layout, and poof, you get a UI in HTML/CSS. Don't try anything too complex or fancy, and take a look at the limitations.
I haven't published on Show HN yet, still a work in progress - but a side hobby of mine
Would a member of the Pagedraw team share a postmortem? Seems like this is a huge need and will be the future state of web / mobile design - what stopped you guys?
I think the reality is, no matter how awesome and impressive these tools are, they just don't seem to have a fit in the market.
Prefacing this with the fact I don't know all that much about the product, only a quick glance
For a big team of developers, building a big website with complicated interactions or requirements, a tool like this isn't going to meet all the requirements the developers have
If you're building something simpler, then you're probably better served by something like Webflow or Squarespace.
At a high level, that makes some sense - these tools might not be the most practical way to get from point A -> point B today for a typical web or mobile app.
In my head, I'm wondering if they are just way too early? Going from design -> code -> UI is, in theory, less efficient than just going from design -> UI, in a programmable, customizable, scalable way.
Skuid, which is a page builder for Salesforce (now branching out to more platforms) is doing very well. At the company I work at we are going to switch away from it due to the limitations you insinuated, but there's definitely a fit for it in the Salesforce world.
Here it is: https://medium.com/@gabriel_20625/technical-lessons-from-bui...
Thanks for this - interesting that you focused the postmortem on technical lessons (other than #1).
I'm super curious around what the sales strategy was.
I'd imagine for devs, it would have to be around productivity (time saved by exporting vs. manually coding, adherence to consistent CSS standards, etc.).
For designers, I would imagine it would be around taking more of the software dev lifecycle - e.g. designers can now eat up part of the value that front-end dev provides. Based on that, designers should be more in demand, paid more, and so on.
Those seem like huge levers to pull from a PMF perspective, but to your point, maybe it all sounds great until you get into that conversation, and it's really not something that teams are looking for (at least right now).
Probably the same as every other attempt at this since the mid 90s. People who can code front-ends don't need such a tool. People who cannot code front-ends hire people who can, and still don't need such a tool.
I can code frontends and I rather be productive with any help I can get, than writing everything by hand.
Loved Delphi, Forms, Blend, Netbeans Matisse and JSF designer, Blend, Outsystems, ...
As mentioned in another thread, these kind of tools with good workflows and developer experience don't get written for free.
Not all UI-builders are a fail. Visual Basic, Qt, Delphi, MS Access all had/have some very popular and useful UI-Builder. There is always a middle between no skill and high skill.
yup you can(surprisingly imo) make a pretty penny on freelancing just setting up static websites on wix for people
making stuff is never going to go mainstream when you can just pay someone to do it for you
I guess the common trend that not everyone wants to pay for their tools.
It’s a pity they’ve shut down, though hopefully it can live on somehow as open source.
There’s a lot of activity in the Sketch/Figma/whatever to React space at the moment, including Hadron [0], Alva [1] and Lona [2].
There’s a real gap in the workflow between design - basically a drawing - and working code. Handoff tools like Zeplin help, but it seems redundant to build everything twice, first in a design and prototyping tool, then again in working code.
However I’m not sure where these tools fit in, as a team that uses React in production would have the skills - and would probably prefer - to dive in with code, rather than use the output of a code generator.
It’s meant to make things easier, but the tech is so complicated it’s way out of reach of those who might actually benefit from it.
[0] https://hadron.app
[1] https://meetalva.io
[2] https://github.com/airbnb/Lona
>There’s a real gap in the workflow between design - basically a drawing - and working code.
In tools like Sketch and Figma you're digging for the underlying visual rules, one "component" or layer can have a ton of variations, and I can quickly compare and compose them side by side on a canvas. You build an evolving system to build design systems from.
In code you're implementing the version or composition that made it, one composition. Unless you can move, juggle and manipulate items as convenient as in design tools, exploring compositions with code is a much lesser experience for a designer, even if he can code.
To make tools that generate React/Vue code work well you have to go far and beyond what most of the front-end oriented tools currently do...At Codesolvent we're taking a different tack..some samples:
Showcase:
https://youtu.be/hgFkzrqxDcs
https://youtu.be/IpX47gAe150
Demos:
https://youtu.be/u6uV2X1MGeY
https://youtu.be/s2dYVret-Ck
https://youtu.be/X6pL0St6NM4
Happy to answer questions.
does anyone actually use this? it looks convoluted.
yes we do have users, there is a cloud hosted version in the works.
It is an object model based solution so it does take some getting used to...basically imagine your vue/react application constructed as an object model, the product provides a UI environment for creating and manipulating that model.
Of course there is always room for improving the workflow so what you see today is definitely not what we envision the final state to be. What we are really excited about is the underlying tech which is going to allow different UI based solutions.
I've been compiling a list of these design-to-component code apps here: https://github.com/skunkwerk/awesome-design-to-component-cod...
Wanted to add Modulz [3] to this list
[3] https://www.modulz.app/
Please add http://www.shift.studio to the list as well :)
I was tasked by my company with using Pagedraw in the early days. The team behind it was extremely patient and helpful and would literally fix bugs in real-time. I would keep an eye on them and look out for their other products. Good folks.
this comment, alone, made it all worth it :)
Thanks =)
> Ultimately, we think Pagedraw is the wrong product. We think you can get 90% of the benefits of Pagedraw by just using JSX better. Our findings on this will be controversial, as they go entirely against the current “best practices,” so we’ll save them for a later blog post.
There is certainly a grey area for tools that are too limiting for developers and require too much setup for designers to use out of the box.
I don't understand why they shut this down before they even attempted to start charging money for it.
You should run it and look at it, its kind of obvious.
We've been working on solving this problem for over two years with a decent sized team. Designers and developers use different tools that don't understand the same formats causing hard handoffs and conversion steps to get a digital product to the customer.
This is an extremely ambitious problem to solve because it requires building an entire Wix or Webflow that also speaks and outputs some sort of web component (in our case React). It needs to allow designers to work in a completely visual way without worrying about tools like Git while developers can at the same time add logic and state to the otherwise static design. You have to remove all hard handoffs that fork the source of truth and keeps ideas from flowing from the canvas through the development pipeline. InVision and other tools are "glue" that attempt to solve this, and they definitely make things easier, but the handoffs are still there.
Many of the tools I'm seeing get close, but they don't go all the way because it would be insanely expensive to replace all the tools in the pipeline (InVision included) and make a single environment that everyone works in to produce a full UI from blank canvas to prototype to production. Gamers have Unity, that's what we need in the web/native app development arena.
We've been working on it here: http://www.shift.studio. While I'm sad to see Pagedraw go (and I've reached out about getting lessons learned from the founder who responded and was extremely helpful/nice), I still believe this is a good idea and we are going to push forward and get it done. I also really love seeing that others here agree that something like this needs to be built.
I would love to hear from HN, what do y'all believe is the fundamental list of features required to tackle this? (no matter how bold/crazy the request)
Agreed a Unity like toolkit for general purpose UI would be awesome. I would be happy to pay a reasonable subscription for such for my team. A killer feature for us, would be easy wiring up of forms and display grids to Postgresql functions and views for storage and IO - we don’t want direct to table. Maybe you could somehow incorporate PostGrest for this.
My wish list is short:
- A look and feel similar to Pagedraw would be perfect
- The output should be just: js, html and css. No frameworks.
- The tool should not offer its own components, only the possibility of integrating off-the-shelf webcomponents (w3c)
Tried to open the demo and got an "Only Works in Chrome" error page. That doesn't give me a lot of confidence in the tool, as my audience for my UI should be larger than just one browser, and I know that I have to test in multiple browsers.
I don't think the output from this tool is necessarily non-compliant with other browsers. This tool/app itself might be - and I think it's OK given it's audience (web developers) who anyways overwhelmingly gravitate towards chrome for it's superior debug tooling
I don't think the output from this tool is necessarily non-compliant with other browsers.
Their home page doesn’t even render correctly in Firefox.
Hmm I was desperately looking for something like this and only ever found was Framer X. Strange I never came across this but definitely excited to give it a go!
hey, I'm currently building an app in this space - could I ask you a few questions about what you're looking for? My email's in my profile if you're interested.
"Ultimately, we think Pagedraw is the wrong product."
So what does this mean? Does it mean it is the right product when it is open source, or is the code being made open source just for the purposes of archiving?
Or now that it is open source is it seen that it might become a more useful tool?
Actually, it's not that hard to build a UI Builder for React. Just output normal HTML, then transpile to JSX. For method handlers, transform into Redux actions. And you've done.