A recorded chemistry lecture about what detergents and conditioners are and how they function, including how conditioner achieves the smoothness effect and the chemistry of hard water.
The last bit (about people listening to hip hop because they "respond to the beat" vs the talent & popularity of 50 Cent) is intriguing and I wish they'd explored more.
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 :)
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!
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"
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.
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!
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!
(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.
(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.
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.
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.
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.
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.
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).
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.