Utopia, a visual design tool for React, with code as the source of truth | Hacker News Reader

Utopia, a visual design tool for React, with code as the source of truth

utopia.app

750 pointsrheeseyb171 comments

To me this editor gets it right in the sense that we don’t need to get rid of code as the “nocode” movement is trying. Instead we need to make coding more enjoyable and figure out ways to make it more interactive.

One specific thing Utopia addresses to me is the need for the code and the actual thing to be treated more as one single interactable component and not two separate things.

Instead we're treating the thing as a one-way compile step. There's no way to sync the DevTools in-memory changes we make to the DOM with the actual code.

The fact that Utopia allows the two things to be treated as one is a huge step towards making webdev more enjoyable.

And they’re following good steps… SwiftUI’s editor is very similar in this regard. Using the code as the main thing but having all kinds of interactable components around it that make writing code simpler with cool visual autocomplete widgets & visual aids.

Before with direct DOM changes building something like this was impossible but now with the React paradigm is seems natural to have this sync between code and visuals.

Kudos to the team for pulling this off.

> One specific thing Utopia addresses to me is the need for the code and the actual thing to be treated more as one single interactable component and not two separate things.

The Smalltalk way.

Thank you! This is pretty much exactly the ethos behind Utopia - that there is ultimately some underlying thing that you want to make changes to, but you often want to be able to make those changes from different viewpoints (or in different contexts) depending on the types of changes you want to make. The React paradigm, especially with functional components, is absolutely right for this kind of a tool.

> There is ultimately some underlying thing that you want to make changes to, but you often want to be able to make those changes from different viewpoints (or in different contexts) depending on the types of changes you want to make

This is something I thought a lot about and really hope to see more in programming. Everything - every object, every concept, every program - has multiple representations, and in order to understand that thing you need to see it in multiple representations. But code is one representation, static text. Having other representations (like the laid-out website), especially that you can not just view but also edit, makes your project a lot easier to understand.

Recently I started incorporating n8n, a workflow automation software, into my backend. Initially my use-cases were Zapier-like. But I realised it was more powerful as a visual program editor. For certain kinds of workflows, it is more intuitive to code and manipulate them using graphical nodes. Perhaps, we can have a similar text+graphical editor for such backend code as well.

is this how Framer[1] works? They have a react<>UI interactions. How do you see it?

[1]framer.com

Framer, at least when I last tried it, was more of a prototyping tool. You could generally only one-way import React components into Framer, and then you could use Framer to assemble new components, but not in a way that allowed round-tripping. It's very possible to import production components into design tools, it's rare when a design tool can output production components again.

Largely because production-ready visual layout tools themselves end up being canvases that are shortcuts only to those who know what controls they want to use and how other layout controls work - they speed up developers, or those technically-minded enough to learn and compose new layouts with the existing controls and markup, but they won't make it easier for someone to design a new production-ready component from scratch when they don't know existing programming patterns, layout controls such as CSS flexbox, etc.

In that regard, Figma, Framer, and even Facebook's Origami are less about creating production code and more about assisting designers and product folks with rapid prototyping. It's not meant to be production-ready. It's not a developer-friendly toolset because the programming is secondary. And that's fine. Less to learn that way, but not instantly ready-for-production either.

There is some overlap though, for tools like Dev Tools, like Utopia, that need to be learned first (or customized into something like a CMS) but can be very visual ways of programming. As pointed out earlier, Xcode Storyboards and SwiftUI are both visual tools which output production code. It's unclear if this will follow the same standards and patterns that production code demands (such as styles, state management/mapping, shared components, and re-use across projects) but this programmer-friendly model is much more the future of visual programming than previous designer-first tools would allow.

Slight correction, though it’s too late to edit: I meant to say at the end, “it’s unclear if Utopia will follow the same standards and patterns that production code demands,”

That's exactly our aim - if making a change via the canvas or inspector doesn't result in production grade code then the tool is failing in our eyes. We're well aware that there are parts where we're not hitting the mark there (effectively we're in an alpha stage here), but we're working hard to improve that.

Congratulations to you and your team on the launch!

I have added Utopia to my curated list of startup tools[1] under 'Visual Programming | Low code | No code'(Yep it's the only heading which I had to add alternatives as well).

[1]https://startuptoolchain.com

Patience. nocode and this both are the same. Utopia will evolve.

This is why I like Business Process Modelling Language as a better UML too

> we need to make coding more enjoyable and figure out ways to make it more interactive.

Honestly, this isn't the reason. The reason for the nocode movement is that businesses are sick of constantly trying to find technology talent for big salaries, and want to DIY. I cast no judgement on whether that's going to be a disaster or not, or for whom.

Business cost savings are a huge pull factor, for sure (if you counted all the Excel spreadsheet "apps" as software, some old school companies would be in the top 100 apps by usage, easy :)

I also wouldn't underestimate the push factor from the creative folks who are technical enough to "read" code / reason in abstract patterns, but can't write it. Fun definitely comes into that, as does a learning curve that's very shallow and near-infinite.

I was lost but Since I've read along this SwiftUI’s editor is very similar in this regard. Using the code things get well

Product designer here. I just spent the past few hours fine-tuning some visual details in our Figma component library. Now I need to file tickets for each change and work with our frontend developers to make sure the updated Figma details get properly mapped over to React.

I've grown numb to the friction, but I think this Utopia demo just reset my pain tolerance. Going back to manually mapping designs from Figma mocks to React components feels so dated. Almost like those PSD2HTML websites of the early 2000s.

The market absolutely needs a product like this.

Utopia Founder here, also a designer. I agree, and for me this cuts both ways - seeing the changes I make in a real UI makes it so much faster to understand edge cases. Not to mention that I used to inevitably re-create production components in my designs. And sure, there are tools for that, but often they just add overhead.

Not sure if you're familiar with the movement, but standardized design tokens[1] seem like the future to me, depending on how well they are done. There's a list of major vendor like Adobe, Figma, etc. that are already onboard and the standardization process is progressing slowly but surely.

As I'm designing an app I don't want just click & drag visually to get some eye-balled spacing or size value. I want a design system with consistent spacing rules. Design tools enable this somewhat but the token standardization is pushing this much further. For example: there's already a hub/API for distributing design tokens to other services. I've seen a live demo of Specify[2] pushing token changes from Figma to a GitHub PR or creating JIRA task during a design token talk from a token w3c group member.

And it's not just about design -> code. If these tokens are standardized, design tools themselves (among others) could have a standardized way of transferring designs.

Heck, even Utopia could embrace this at some point to provide you an alternative view/workflow for your already standardized design tokens.

[1] https://www.designtokens.org/

[2] https://specifyapp.com/

After five minutes of playing with it and failing to find it... where is the panel of components to drag and drop into the tree? Seems like the most basic functionality in an editor like this. Something that VB had in 1993. This should be something that is obvious and visible on a first glance.

Another issue I have with the UI is that a lot of elements are greyed out even though they remain interactive. The convention is that UI elements that are greyed out are not interactive due to the current state of the application (wrong mode, unmatched requisites etc). This application seems to violate that and I'm still baffled as to what greying out of UI elements means in in this app. If they aren't disabled why are they greyed out?

25 years later, and we're back to FrontPage. "Time is a flat circle."

> 25 years later, and we're back to FrontPage.

And... about bloody time IMHO. There's a reason tools like FrontPage and Flash were so popular - those tools made the internet available to millions of people who aren't into tedious coding.

I totally agree. I'm not sure why they fell out of popularity. I would've never learned HTML/CSS/JS had it not been for my 9-year-old self messing with FrontPage.

They fell out of favour because you couldn't realistically build a dynamic site that didn't generate spaghetti code. They were fine for static sites, but the moment you needed to make things _happen_ they become unmaintainable, unversioned messes.

Right. We gave a lot of thought (and iterations...) to why those tools felt like they are holding developers back instead of making them faster, and why were they ultimately abandoned.

We believe the answer is that one-way code generation is a trap: if you export code from a tool which cannot be edited by a human and then read back into the tool, it is going to end up being edited by a human anyways, but the tool will be abandoned for that file / project.

So we made it our number one priority that Utopia must work with any valid javascript/React code. There is a happy path where we can understand a lot of that code and populate the inspector and enable editing on the Canvas, but even if you veer off the happy path, Utopia is still going to be able to parse/preserve all of your code, and render it on the Canvas as well.

This means that if an application gets complex and a team of people start working on it, making refactors to the code, write complex components, add any kind of state management, etc, people on the team who use Utopia will still be able to open the code and make changes to the design.

One thing hugely working in our favor is React and its functional reactive component paradigm. If you look at an individual component, the JSX part is just about parseable enough for us to be able to reason about it and update it while preserving the javascript code that surrounds it. This means we can avoid printing ugly machine-generated code around them to be able to track the changes. ( for example we don't need to litter the code with markers like  ) Plus, as React applications grow in size and complexity, most of the individual components remain small and simple. This means that if you open a real produciton React app in Utopia, there is a good chance you will find leaf components that are used for the actual content rendering, and you will be able to make changes to those without creating a mess.

I think tools like Dreamweaver and FrontPage ultimately failed due to many factors. By respecting the existing code you address one.

Other is that CSS can be shared between unrelated elements and cascading. FP and Dw worked pretty well for HTML where the looks of the elements were determined by their properties. Once CSS showed up they tried to adjust by encoding same things in inline styles of the elements. There was some support for css classes but it wasn't first class. You couldn't easily click to make a group of visual properties a style, name it (or choose a selector for it) and use it in other element somewhere on the page. The css classes are one thing, the other is 'cascading'. You couldn't do that conveniently either. So the moment you wanted to use the actual innovation that css brought to the table you had to pretty much drop into code and rarely ever come back to gui, which made visual part of FP and Dw obsolete.

And since you are dropping into editor you might want to drop into your favorite one where you have your own file tree, plugins and such. I think Utopia would make more sense if it could be run as a VSCode plugin.

To try to avoid that fate I think Utopia might consider some way of extracting those sliders on the right hand of UI out of specific component and into a shared group of styles. If you were working with CSS instead of css in js react-style the best idea would be to just mirror what css has, like named classes and complex selectors. And when you click a component you should let edit both inline component style and all the selectors that apply to it. It should basically mirror Chrome CSS inspector but in visual form with sliders and friendly names and other stuff. Since you are using React it would be best to mirror what React developers use to share styles between components. Some commentators here mentioned some libraries and solutions for sharing styles between components in React. But it doesn't look in Utopia it is as essential for survival since in React sharing styles by sharing whole components is a valid approach.

The other thing that made me abandon FP and Dw was that my HTML was generated server-side with a lot of PHP and parts of it kept in multiple files. You neatly address this using React and keeping it alive enough to populate the page you edit with state. React also enables composition of the page from components that can be edited separately which neatly resolves the issue of web page being spread over multiple files. I see that Utopia deals with editing components that include other component from different files neatly and it could be used flexibly to edit all the components however small and large and complex they are.

Other than that visual tools like that are great, both for people learning web development and people doing their work. I hope that Utopia thanks to your effort and power of React and its ecosystem will eventually becomes the standard way how people begin React project. Sort of like visual form of create-react-app.

Thank you for taking the time to write this!

Wrt the VS Code plugin, it was an idea we were toying with. Ultimately we decided to go with a standalone editor because we didn't want to limit our market and run the risks involved with coupling our existence to them. That being said, a VS Code plugin is absolutely in our future and something we would want.

You're absolutely right that by targeting React we are mitigating some of those issues you've mentioned, but they are still issues that we still need to address, so we do need to adjust or introduce further tooling. All of these things are on our roadmap, but we're a small team so it's a case of prioritising, which is where comments like this come in to play as they help us add weight to those priorities.

We've got a long way to go, but thoughtful and constructive comments like these help us immensely along the way :)

It's understandable that you started with standalone for the control and independence. I'm happy to hear that you have VSCode plugin planned. I wish you all the best and I see massive potential for your project to become essential part of visual IDE for the web.

Also: Visual Basic and Delphi.

Visual Basic was my introduction to programming - I still have somewhat of a fondness for designing GUIs in Visual Studio

Delphi gang here! Encountered Delphi as a kid by accident, and playing with that first form was a life changing event for me: realizing that I can make something new, real, tangible, that I'm in control. Coming from a non-tech family/background, this was big for me, I don't think I'd have gone into tech if not for it.

As a kid (and adult) you need to see some immediate tangible result of your virtual labor.

That's absolutely true for sure, and I'd go so far as to argue that it's one of (if not the) primary driving forces behind development tooling decisions. Whereas some changes are well suited to e.g. unit testing (and where a passing suite of tests provides that instant feedback), when working on the design or interactions of an interface it's very important to actually "see" and/or play with the result of each minor tweak, so the faster you can make that loop the more pleasurable the development experience will be.

Dreamweaver is still around actually.

https://www.adobe.com/products/dreamweaver.html

Utopia founder here. Yep, I loved the idea of Frontpage, and learnt so much, and yet - it sucked so much in practice. What kept us honest here was having the real-time feedback loop between design and code, and real-time two way editing. It really pushed us to "only make the smallest, surgical updates possible", and ultimately "make sure the editor actually understands the code"

We also are trying our best to preserve intent (eg if you resize a flexbox element, we don't set a width on it but default to flexBase, unless there's already a flexGrow on it).

This is actually really neat.

Do you think there'll be a "standalone" version of the live-preview / UI, without being tied to VSCode and allowing a separate code-editor?

I'm getting old, too *sigh.

Technology stacks appear, and go right ahead reinventing dependency managers and repositories, IDEs with autocompletion, refactoring & WYSIWYG editors, a strong type system, comments and schema validation for configuration file formats (JSON)...

Nice work though, looks really promising!

Something something smalltalk in the 80s something something. I'm old enough to remember Smalltalk systems running on Sun workstations being a thing. I still don't know if we've reached that level of development effectiveness with modern tools.

Yup, worked with that, was great.

Needed Envy VC for teams though.

Ah, haven't heard of that, I was just a wee lad at the University computing center before I got out of high school.

This what you're referring to? https://paulhammant.com/2017/09/01/smalltalk-envy/

I can't recall front-page doing script/interactivity much? This is more like Dreamweaver?

Ed: it's strange that the lively-kernel.org approach (the Self/Smalltalk approach) never did seem to gain any real traction. Rather we get these odd half-meassures like source-maps, bundled js and what-not.

Well, any small progress towards the 80s in the 20s is good i guess...

Dreamweaver Ultradev, released in 2000, was the first version to introduce scripting with PHP and ASP.

Oh, I'd blocked out server side script support. As if the Javascript widgets weren't bad enough :D

This is why it's important to evaluate tools without bandwagoning and believing the hype. Sometimes, the hype turns out good, but more often than not it doesn't.

A tool I've experimenting with a lot recently is https://www.plasmic.app/

It outputs React code as well. But the approach is more similar to Figma. You can create components with variants etc.

It can automatically sync changes to your local repo or create a pull request on GitHub.

I always wanted a tool like this, and wondered why it didn't already exist. Many others have tried this before (code + visual editor, albeit not necessarily React). I'm interested in what challenges the developers faced to make this and how they overcame them.

If this works well, it will be amazing and I'll almost definitely use it for my next webapp.

Big no for me if styles are injected as inline styles. As a developer I don't want to work with that generated code. At the very least look at using styled components or generate accompanying css module file.

Yea, optimally it would give these three options as alternatives for user to choose.

See: https://news.ycombinator.com/item?id=27522714

Utopia founder here. Totally with you on this, inline styles are at best a starting point. We already support changing the style target to `css` (styledC / emotion) and the various pseudo states. We also have primitive support for CSS classes.

We started with inline styles because typically that's the starting point when designing / prototyping. A lot of the features on our near-term roadmap are about then abstracting those: "take this element with styles and make it a component", "refactor this manually styled thing with the best matching layout component" etc.

Our design philosophy here is to help you do what you'd do in code (heck, you can even do it in code!), but not make broad assumptions about what that is or should be. Inline styles, helper components, utility css classes, styledComponents all have their place, and it's your job as a designer / engineer to decide on where to use what. What we can do is make those changes as fast as possible, while always showing you the resulting code. No black box, no "smart" decisions.

What's the problem with inline styles? Just curious. Trying to understand what the difference between styled components and inline styles actually is in this case.

First, congrats on the tool!

Have you thought about supporting multiple use-cases for each component? So for example the component might be showing a list. I want to test (and visually design) the use-case when the list is empty, then I want to switch and visually design when the list has one element, then when the list has a lot of elements..

Also it would be great that in those cases you could define not only the data but also the surrounding canvas and browser properties. Test&design for mobile, laptop, dark background, old browser, changed styles, etc.

It seems to already support that - see the section "Working with generated and conditional content"

This is really nice! Although I’d find it impractical to use, especially for existing projects, unless it also supported different CSS-in-JS libraries (e.g., Emotion, Styled Components), rather than inline styles with the `style` prop.

These other libraries offer a great deal of more support, such as targeting children and pseudo-elements (e.g., :hover).

Any plans/timeline on adding support for other React-in-CSS libraries?

This. From the video it’s hard to see if you can declare and reuse styles or if all styles are inline and need to be repeatedly applied to identical components.

Either way, this is really awesome. Huge congrats on the release. It reminds me of one of my fav talks which I can’t find right now but it’s a guy that codes up a Mario clone while toggling back and forth between the game and the code and making changes in the game updates the source code. If anyone knows what I’m talking about please reply here.

Probably Bret Victor - "Inventing on Principle" (2012) - https://www.youtube.com/watch?v=PUv66718DII

Bret Victor is our idol! I didn't even have to click the video to know exactly which one you were talking about :)

I've been working on a WebGL project that had extremely low frame rates to start with and refused to give up until it rendered in real-time because of this talk. It's one thing to make something useful but I think the real measure of success is if it's useful and the value is created in real-time like you've done. Congrats!

This is it!!! Thank you.

This is similar to what we tried (and failed) to achieve with Blocks UI[0] at Gatsby.

The critical piece almost all current-gen UI editing tools are missing is that there needs to be a sync between changes in the code and changes in the design. John Otander and Chris Biscardi built a complex system based on Babel to manage syncing visual changes to the code.

I wonder how Utopia solved this! How do you "move" the visual changes made in the editor to the code?

[0]: https://blocks-ui.com/

Yes exactly my question. How does the bloody thing work?

I am very interested in this. I am a low-coder you could say. I have to start coding a front-end in React soon (and I have yet to learn React) so with all the overhead of learning React as well as fiddling with html, css etc, it feels like a really big task. I saw some visual builders for React , downloaded/tried a couple but they had pretty big learning curves of their own so I didn't bother taking it any further.

You guys seem to be addressing the right pain point in the right way.

I will definitely give this a go soon

Thank you! I'm one of the developers working on Utopia.

> I saw some visual builders for React , downloaded/tried a couple but they had pretty big learning curves of their own so I didn't bother taking it any further.

This was our experience with existing low code or code generating design tools as well – you actually have to put a lot of time into learning how to use them, time you could spend on learning actual React.

One of our guiding principles was that people who use Utopia should not need to learn anything that is proprietary to our platform.

I am student and I think my instructors who teach a Software Engineering class would be very very interested. We typically have non-CS majors in that class and it can be a bit of a learning curve.

Helping people learn to code is something that we're very keen to achieve with Utopia.

I wonder if they've drawn inspiration from SwiftUI?

Yep, I was wondering the same - it reminds me a lot of the SwiftUI visual editor in Xcode. Very nicely done.

Funny you should mention this, we were actually working on it for a while before SwiftUI was revealed, but taking a slightly different approach at the time (the original approach was more inline with Unity, meaning an engine would be required to run the apps). We had reached the conclusion that that approach was wrong (primarily because of the lock in and how much of an uphill battle it would be for us to move to away from it), and had just started working on the new code-first approach when Apple dropped that at WWDC. Our jaws hit the floor because we knew we were on the right tracks then.

When you see things side-by-side you realise the React devs foisted XML back onto the world :D

JSX is XML... but with blackjack and hookers?

...in fact, forget the XML :D

Product Designer here. Is there a specific reason why tools/demos(Framer comes to mind) such as these are tied to React? Is it just because of the popularity of React these days or is there a technical reason for it that's lost on me?

React is very popular in the market.

React/JSX converts what was previously DSLs nested within DSLs into code. This is why dev tools like this oft use React, or more specifically JSX. It complements the HTML DSL, but in a coding context. Most other similar browser tools use templating mechanisms with DSLs for embedded logic. For this reason, React will have jQuery like longevity, and people will continue to design for it. It's easier to code for code than multi-layer DSLs (see Jinja, Vue, angular, swig, etc). Forgive me if that was a little meta or over simplifying.

As someone who worked with React, Angular and Vue professionally the last 6 years I cannot agree.

React will be around for a while because of its popularity. It has nothing to do with JSX. Acutally, Vue, especially Vue 3 with the compositiona API is much easier to work with than React. You could use JSX with Vue as well. React has quite some leaky abstractions, which makes it more hard to master than Vue or Svelte. React seems easy, but it is not.

This is a really cool idea!

A bit of self-promotion: I've been building something similar but without the visual editing, integrating directly in your VS Code editor (and soon IntelliJ/WebStorm too). See https://reactpreview.com for more info.

Direct link to the latest beta for Visual Studio Code for HN friends: https://reactpreview.com/download/releases/reactpreview-vsco...

(it's very early days, this beta isn't even a week old, so expect to find bugs)

How hard would this be to get it working with preact instead of react? I always liked that preact has a very easy "no build tools" route for creating simple frontends that you can simply open and run in a browser.

This looks promising! I’ve been waiting for something like this. Will give it a try.

How would you hydrate the app with data while you dev? Feels like adding some storybook like features to test components could be useful.

> How would you hydrate the app with data while you dev?

This is precisely what the scenes are for in the storyboard.js file - it allows you to create multiple scenes that render your components with different data / props.

> How would you hydrate the app with data

Never heard the word "hydrate" in this context before but it sounds very… appropriate :)

(founder here) You totally can do this, we use it like that all the time. "Dev" edits the running application or component, not a scaffold - so if you've got {list.map(x => <Card>{x}</Card>} you can select each card and it'll map it back to the instance inside the map. Same with ternaries etc.

Wouldn't this be better as a VS code plugin versus a web-based tool?

Or a full electron app. Not sure I like the idea of uploading my code to test.

It seems to be open source - one might imagine it can be run as a local instance?

I agree, but is it even possible to effectively monetize a VS code plugin?

E. G. https://wallabyjs.com/ does pretty well

> Wouldn't this be better as a VS code plugin […]

I think it is: https://github.com/concrete-utopia/utopia#build-editor-vscod...

(founder here) we do have a vscode plugin (that handles the "follow me" side of "I click on something in the design" as well as triggering updates on the canvas, but it's not a VScode plugin _of_ Utopia. The monetisation isn't the big issue, it's more around performance management (and candidly also the internal dev cycle). We don't believe single-player use should be monetised anyway, that just creates the wrong incentives for us.

I was planning on building something similar. My first attempt involved trying to get grapesjs to work with react. This attempt was very cumbersome because grapesjs generated html, and I would try to manipulate the html into react.

https://github.com/artf/grapesjs

Later however, I discovered craft.js, which is basically a framework for creating systems similar to this (page/component editors). Craft.js was inspired by grapesjs, but is specifically made for react.

https://github.com/prevwong/craft.js

Of course craft.js only solves the UI editor, not the code parsing/generation part. Babel is an obvious choice for code generation/manipulation, but I found its imperative approach unnecessarily complicated, so I built react-ast to enable declarative and composable code generation using react.

https://github.com/clayrisser/react-ast

The part I had not figured out was using the code as the source of truth for the editor and syncing it back. I definitely thought about it a lot, but postponed solving it since I had more pressing problems.

So, I have a lot of curiosity about this project. How does it work? And how does it stack up against a technology like craft.js? I noticed it’s not using craft.js, so I’m guessing the developers rolled their own equivalent.

What I really want is a way to sync back changes made in the inspector to my css-in-js code. Does Chrome offer hooks that a library could use to accomplish this?

If you're referring to the Chrome devtools inspector - unfortunately, that's a no. To start with, no such hooks are available. Additionally, the truly hard bit is figuring out what code the resulting HTML maps to, especially when there's lists, conditional content, and nested components involved.

Eh, I don't think that's necessarily the truly hard bit, at least for common cases with a library design that works. With something like `useStyles()` from material-ui, you get a fairly unique className, and coupled with a build tool that injects the file/line/col location into the className, should be able to map directly back.

Like many others, I think this is super cool, and something that I think has been missing in the ecosystem for a long time.

I feel like the thing that would really make this over-the-top powerful is deep integration with a component library, either a company's in-house one or an open-source library. It would allow for super fast UI prototyping that would also serve as scaffolding for the full-featured product.

This is ultimately one of our goals, to allow maintainers of those kinds of libraries to publish that kind of integration, or for us or even other users to provide it (thinking along similar lines to TypeScript type definition files)

Love what you're doing! Happy to hear you have component libraries in your plans. I'd love to see this integrated with storybook

Looks amazing, I will definitely check it out, any information in supporting other forms of styling, like CSS modules or styled components?

I had the same thought about styled components. In the meantime I'll just use emacs to convert the default style objects to styled components when I'm done using Utopia.

I imagine I will use Utopia and then tailor the code afterwards with a code-editor to add my own idiosyncrasies. Still pretty darn efficient to design UIs this way honestly. I'm pretty stoked!

If it doesn’t support styled-components, how does this work with real React components?

We had this question earlier in a reddit submission so copying and pasting the answer here (so that you don't think I'm being insincere!) - We fully support styledComponents, or any valid React for that matter. You can even use utility CSS classes in code. The design tool can edit some of these today already (e.g. you can pass in additional styles to a component instance). Better support for creating and managing styledComponents / Emotion is high on our roadmap so watch this space!

Also worth looking at some of what was possible back in 2008 (and was sidetracked for unrelated reasons) - it's great to see these ideas coming back in a viable way

https://www.youtube.com/watch?v=ouzAPLaFO7I [280 North Atlas]

I've only skimmed the video but it looks like your philosophy was a bit different, in that you were pursuing a visual programming / no-code approach?

Sorry, should have clarified - that was work done by 280 North, a YC company from W08, all ex-apple. They built:

  - Objective-J (JavaScript equivalent of Objective-C)

 - Cappuccino (Objective-J equivalent of Cocoa, from what I remember)
 - Atlas (equivalent of InterfaceBuilder)
 - Slides (equivalent of Keynote)

The UI builder serialized to the nib equivalent so code wasn't the source of truth, but it was definitely not a no-code approach (code methods were exposed in their GUI builder, and you could consume the nib artifact from your code).

As soon as I resize the code menu this[0] happens. Everything shifts up and I cannot scroll it down or get it back to normal without refreshing.

[0]https://imgur.com/a/N82Zutz

Hmmm that's incredibly frustrating. I'm trying to reproduce this but failing. Are you able to do this every time? If so is there any chance you could take a screen recording please to help us debug it?

First I have to apologize. I hadn't upgraded chrome. After updating it did not happen again on chrome. It does happen on firefox[0], and I do realize that you've stated your app works best in chrome.

Lastly, thanks for making this. It looks really cool.

[0]https://streamable.com/jth0pn

We used to call this WYSIWYG editing, and it ushered in a whole generation of FE and flash devs. Editors like this went out of favor because, sadly, it can never quite keep up with the cutting edge.

This is so cool. I built something similar for my startup https://panakit.com. It’s a tool de create blogs and I have a UI builder where users can customise the blog. The code is hidden away since it is aimed at non-tech people. My UI builder is way limited in functionality and only works for blogs and it was still quite a bit of work to build, I can’t even imagine the amount of work your tool required. How do you plan to make money out of it?

Awesome to see it's open source.

Yeah we wanted to go the open source route from the beginning. The thinking was that it would help us build a community with meaningful relationships with our users (or at least the ones that get annoyed enough to log bugs or even contribute), but also most of our favourite tools are open source.

Gret work!

I find it similar to Hadron App[0] that generates modern HTML and CSS. I was very excited about that tool. Unfortunately, the blog[1] and changelog[2] went silent last year.

[0] https://hadron.app/

[1] https://medium.com/@HadronApp

[2] https://hadron.app/updates

This looks very cool. I'm very new to JS/webdev and I wonder if it could eventually be possible to use this with react-native (if you can't already).

I have been searching for a technology like this for a long time. I have several specific features I’m searching for in a technology like this, and I’m curious how many of these features Utopia supports.

- Extendable component library and property panel so it can support custom component libraries and styling systems

- Native integration with vscode (maybe as an extension)

- Tailwind style editor and theme ui style editor - Full TypeScript support

Very cool! Using “follow me” mode is a neat way to see what you are editing in both the code and in the visual design.

We are working on something similar at Builder.io that utilizes jsx-lite to allow visual editing right alongside code. Feel free to check it out here: https://jsx-lite.builder.io/?outputTab=react

I really hope the community will settle on one tool and invest in it. Something like that would make React development so much easier

Utopia founder here. Obviously this is a privilege we need to earn, but we made Utopia open source (MIT) for that very reason, and free for single users for the same.

Looks nice!

It seems that any "logic" (conditionals, iterators, etc) in the components will prevent the component (and their children) from being inspectable.

Is the intent to keep it "no-code" in this respect (i.e. effectively a visual JSX editor), or will you be adding the ability to inspect more "dynamic" components to make it useful for app development?

Our goal isn't a no-code tool, but rather an editor that provides the tools for both developers and designers. We're iteratively improving the level of complexity of code that we can fully parse and expose to the rest of the editor, so you can expect these kinds of cases to become fewer and far between over time.

If you do have specific cases that you come across and are interested in following the development or just want to let us know of them, please do file an issue on our GitHub repo.

Are you planning to expose the JSX editing capabilities as a library, so that it could be used for e.g. non-web-UI editing?

I've been working on a React/JSX wrapper for OpenJSCAD (a solid CAD library), where the "viewer" (that shows the rendered model) offers simple interactivity that is decoupeled from the code. It would be amazing if that could be extended to allow for editing the code when you interact with parts of the model in the viewer (as you would do in traditional CAD programs).

I am curious if at any point functionality and power of these Web tools will ever come anywhere close to something like Delphi.

Nice work anyways.

You beat me to it. Good old Delphi ... I still consider UX in Delphi unparalleled.

The page is completely broken for me with most links failing due to certificate errors:

  Failed to load resource: net::ERR_CERT_INVALID 4b99d2cfb81c64aed531.css:1
  Failed to load resource: net::ERR_CERT_INVALID cdn.utopia.app/_next/static/chunks/webpack-50bee04d1dc61f8adf5b.js:1

etc

Same in Chrome and Safari

Is this still the case for you? I don't believe we've seen this issue from anyone else, so I'm wondering if it was a blip or something more insidious

Thanks, yes I guess it was a consequence of something about the network I was on.

So they invented react-aware FrontPage ? =)

Macromedia Dreamweaver :-) I have extremely fond memories of setting up an FTP access from cPanel (you all remember cPanel, right?), then syncing the website through Dreamweaver over FTP. It was awesome. Those days were the best I don't care what anyone says.

Hey, we didn't invent it, we just discovered it ;) Nah, so it's a "kind of". Philosophically, we're much more code-based in our thinking, and have allergic reactions to unnecessary code changes. The design tool doesn't prescribe your styles, but follows what's there and lets you choose. And it's built from the ground up for multi-file projects with different components.

Sometimes just the "I click on something, it opens in the code editor" is a huge time saver compared to "hunt for the element in devtools, search in VSCode for what file that component / instance lives in"

Nice! I especially like that one can easily view and edit the code generated.

How long did it take you to arrive at this version?

Thank you for the kind words! From the germ of the "code is source of truth, code editor and design tool are just lenses to edit it" to where we are today, about 2 years with a small team. A lot of it went into "table stakes" (VSCode-in-the-browser, multifile, npm imports, console, performance, real-time updates). The design tool side has had a lot of experiments and prototypes, and is finally getting the love it deserves :)

So, say I were to attempt to swap out React for Vue 3, how difficult would it be? How tightly coupled is React?

I would love love love to contribute to a vue version of this

Piggy-backing on this question, is it possible to use React alternatives like Preact or my own DIY React clone?

At the moment, it's coupled but not tightly so: we rely on the TS compiler to do the heavy lifting re: mapping design to code. The code that does that is of course React-specific, and we make somewhat implicit assumptions in other places. We do want to make sure we support React well before we expand out to other systems, but if you're technically minded and want to help explore this, would love to talk more!

I’m certainly interested! I’ve been looking through the source to see where it all ties in.

This ticks so many boxes for me - I've been wanting a code-based visual editor for React since like forever.

Thanks! :)

I love that it feels somewhere between figma and xcode. Very approachable UI. super cool tool.

Thank you. All too often we found ourselves having to pick "Do I design this in a design tool or do I just prototype in a JS playground" - all the while looking somewhat jealously at Xcode, Unity etc.

Great work on this and looks interesting at first glance and very happy to see this open source.

Doesn't really look ready or supported out of the box for M1 Macbooks, unsurprisingly. Probably going to install this on my other machine to try it out instead.

It's a browser based tool. I'm not sure what you mean by "Doesn't really look ready or supported out of the box for M1 Macbooks". JavaScript cannot target chip architectures, AFAIK.

So you didn't read the prerequisites and the troubleshooting sections first then? [0]

[0] https://github.com/concrete-utopia/utopia#troubleshooting

Isn't that for development?

There is indeed some messing around required, but some of our team are developing this using M1 macs

Just wondering: how is it different from a live reload yarn run serve+IntelliJ +a browser?

It lets you edit things inline like the browser dev tools. And drag them around like Figma.

The main thing is that you can edit visually, and changes are reflected in code. So it goes in both directions. Editor + Live Reload only goes in one direction.

Ooookkkk. Sounds good indeed!

Well, It is an interactive GUI for one...

Damn, I'd been meaning to build exactly this for ages but never got around to it. It's always felt like a key missing piece, particularly after working with tools like Android's preview tab. Major kudos to the team!

Thanks, so had we! It definitely wasn't a "just a few months" thing :) Editors have demanding UX, performance is hard etc. Inspiration definitely came from things like Unity, and native devtools (esp SwiftUI that gave us conviction two-way editing "could be done"). If you're interested in what we're doing and have ideas (or even code) to contribute - it's an open source MIT-licensed project. Would love to chat and learn!

Pretty cool, congratulations. Any plans to support Vue in the future?

We've had a lot of requests for Vue. It's not going to be a walk in the park, and we want to make sure we support React well before we add more surface area. But we're not super tightly coupled to React, so (hello, Dunning-Kruger) it shouldn't be impossible! If you're technically minded & want to have a chat about helping us explore that, would love to chat more!

Fair enough. Your decision to focus on one platform first, while still maintaining a relatively generic / flexible codebase, is definitely the optimal one. My interest in Vue stems from me selecting it as a front-end framework (FEF) of choice for my startup (work in progress). I have selected Vue after doing some relevant, but limited, FEF research; however, I might change my mind and go the React way at some point in the future. I'm certainly technically minded, but not an expert in JavaScript and Vue/React. So, while I love helping others, where possible, I'm most likely not the best person to help you explore the potential Vue support for your product. I might be a future user, though. Good luck!

This is cool, the UI and preview reminds me of BB10's IDE for qml... Still miss those days and I still don't understand why we don't have qml for the web.

https://journeyapps.com/platform/oxide/

Is Vue support in the works? Or maybe even react native?

Wanted to clarify that this looks really awesome- just that my projects are all in Vue, except for one that's in react native. Any insight appreciated!

We are actually going to start designing our Front end this weekend , about to do it from scratch. absoulatly going to put this to extensive test.

Fantastic news! We would love to hear your feedback in that case :)

How does it detect source element when hovered on preview?

Preview would have a dynamic ID that maps to the source JSX.

At the very high level, yeah that's pretty much what's happening. We generate IDs that we map to each of the elements statically and that we inject into the DOM so that we can capture metadata about the element. We're currently writing an in-depth explanation of how this all works, which will be uploaded on our blog in the very near future.

Thanks for the explanation

Why is CSS & HTML written in JS?

maybe this should be a VsCode extension that can work offline

Excellent, now do one for Angular! And Web Components!

This looks amazing, cant wait to try it out

Vue support would be great :)

maybe this should be a VSCode extension so that it works offline aswell

Very impressive!

please consider adding support for svelte!

How does Utopia compare with Dreamweaver or FrontPage?

Ctrl-f "winforms" - 0 results. Really?

this looks awesome! Great job and its a great team work.

So this is cool because it's for React but I'm curious, this is not a new idea right? Lots of UI tools hold the source of the UI in code. For example the original C# in Visual Studio did this IIRC. I think Android Studio does this (well it edits XML which is used at runtime?). Swift?

Reply on news.ycombinator.com