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 <!-- 53170a63-315f-4bb0-9f32 --> )
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.
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 <!-- 53170a63-315f-4bb0-9f32 --> ) 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.