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 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?
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.
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).
So, say I were to attempt to swap out React for Vue 3, how difficult would it be? How tightly coupled is React?
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.
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!
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.
Just wondering: how is it different from a live reload yarn run serve+IntelliJ +a browser?
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.
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!