[canada_dry]

> 25 years later, and we're back to FrontPage.

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.

[maltenuhn]

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

[WhyNotHugo]

This is actually really neat.

Do you think there'll be a "standalone" version of the live-preview / UI, without being tied to VSCode and allowing a separate code-editor?

[dvt]

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.

[phist_mcgee]

They fell out of favour because you couldn't realistically build a dynamic site that didn't generate spaghetti code. They were fine for static sites, but the moment you needed to make things _happen_ they become unmaintainable, unversioned messes.

[bayjorix]

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.

[scotty79]

I think tools like Dreamweaver and FrontPage ultimately failed due to many factors. By respecting the existing code you address one.

Other is that CSS can be shared between unrelated elements and cascading. FP and Dw worked pretty well for HTML where the looks of the elements were determined by their properties. Once CSS showed up they tried to adjust by encoding same things in inline styles of the elements. There was some support for css classes but it wasn't first class. You couldn't easily click to make a group of visual properties a style, name it (or choose a selector for it) and use it in other element somewhere on the page. The css classes are one thing, the other is 'cascading'. You couldn't do that conveniently either. So the moment you wanted to use the actual innovation that css brought to the table you had to pretty much drop into code and rarely ever come back to gui, which made visual part of FP and Dw obsolete.

And since you are dropping into editor you might want to drop into your favorite one where you have your own file tree, plugins and such. I think Utopia would make more sense if it could be run as a VSCode plugin.

To try to avoid that fate I think Utopia might consider some way of extracting those sliders on the right hand of UI out of specific component and into a shared group of styles. If you were working with CSS instead of css in js react-style the best idea would be to just mirror what css has, like named classes and complex selectors. And when you click a component you should let edit both inline component style and all the selectors that apply to it. It should basically mirror Chrome CSS inspector but in visual form with sliders and friendly names and other stuff. Since you are using React it would be best to mirror what React developers use to share styles between components. Some commentators here mentioned some libraries and solutions for sharing styles between components in React. But it doesn't look in Utopia it is as essential for survival since in React sharing styles by sharing whole components is a valid approach.

The other thing that made me abandon FP and Dw was that my HTML was generated server-side with a lot of PHP and parts of it kept in multiple files. You neatly address this using React and keeping it alive enough to populate the page you edit with state. React also enables composition of the page from components that can be edited separately which neatly resolves the issue of web page being spread over multiple files. I see that Utopia deals with editing components that include other component from different files neatly and it could be used flexibly to edit all the components however small and large and complex they are.

Other than that visual tools like that are great, both for people learning web development and people doing their work. I hope that Utopia thanks to your effort and power of React and its ecosystem will eventually becomes the standard way how people begin React project. Sort of like visual form of create-react-app.

[rheeseyb]

Thank you for taking the time to write this!

Wrt the VS Code plugin, it was an idea we were toying with. Ultimately we decided to go with a standalone editor because we didn't want to limit our market and run the risks involved with coupling our existence to them. That being said, a VS Code plugin is absolutely in our future and something we would want.

You're absolutely right that by targeting React we are mitigating some of those issues you've mentioned, but they are still issues that we still need to address, so we do need to adjust or introduce further tooling. All of these things are on our roadmap, but we're a small team so it's a case of prioritising, which is where comments like this come in to play as they help us add weight to those priorities.

We've got a long way to go, but thoughtful and constructive comments like these help us immensely along the way :)

[scotty79]

It's understandable that you started with standalone for the control and independence. I'm happy to hear that you have VSCode plugin planned. I wish you all the best and I see massive potential for your project to become essential part of visual IDE for the web.

[rho4]

Also: Visual Basic and Delphi.

[maga]

Delphi gang here! Encountered Delphi as a kid by accident, and playing with that first form was a life changing event for me: realizing that I can make something new, real, tangible, that I'm in control. Coming from a non-tech family/background, this was big for me, I don't think I'd have gone into tech if not for it.

[rho4]

As a kid (and adult) you need to see some immediate tangible result of your virtual labor.

[rheeseyb]

That's absolutely true for sure, and I'd go so far as to argue that it's one of (if not the) primary driving forces behind development tooling decisions. Whereas some changes are well suited to e.g. unit testing (and where a passing suite of tests provides that instant feedback), when working on the design or interactions of an interface it's very important to actually "see" and/or play with the result of each minor tweak, so the faster you can make that loop the more pleasurable the development experience will be.

[shpongled]

Visual Basic was my introduction to programming - I still have somewhat of a fondness for designing GUIs in Visual Studio

[pjmlp]

Dreamweaver is still around actually.

https://www.adobe.com/products/dreamweaver.html