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.
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.
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).
> 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.
> 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.
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.
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.
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?
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.
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).
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.
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)...
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.
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...
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.
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.
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.
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.
Readit News
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.
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.
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
[1]framer.com
The Smalltalk way.
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.
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'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.
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/
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?
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.
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).
https://www.adobe.com/products/dreamweaver.html
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!
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...
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.
If this works well, it will be amazing and I'll almost definitely use it for my next webapp.
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.
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.