[sktrdie]

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.

[rheeseyb]

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.

[Jakobeha]

> 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.

[dreamer7]

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.

[Abishek_Muthian]

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

[redindian75]

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

[1]framer.com

[lstamour]

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.

[lstamour]

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,”

[rheeseyb]

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.

[goatlover]

> 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.

[trhoad]

> 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.

[maltenuhn]

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.

[13daug]

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

[tlarkworthy]

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

[imvetri]

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