[HN Gopher] Utopia, a visual design tool for React, with code as...
___________________________________________________________________
Utopia, a visual design tool for React, with code as the source of
truth
Author : rheeseyb
Score : 698 points
Date : 2021-06-15 14:42 UTC (1 days ago)
(HTM) web link (utopia.app)
(TXT) w3m dump (utopia.app)
| tW4r wrote:
| Looks amazing, I will definitely check it out, any information in
| supporting other forms of styling, like CSS modules or styled
| components?
| codemonkey-zeta wrote:
| I had the same thought about styled components. In the meantime
| I'll just use emacs to convert the default style objects to
| styled components when I'm done using Utopia.
|
| I imagine I will use Utopia and then tailor the code afterwards
| with a code-editor to add my own idiosyncrasies. Still pretty
| darn efficient to design UIs this way honestly. I'm pretty
| stoked!
| Aeolun wrote:
| If it doesn't support styled-components, how does this work
| with real React components?
| [deleted]
| rheeseyb wrote:
| We had this question earlier in a reddit submission so copying
| and pasting the answer here (so that you don't think I'm being
| insincere!) - We fully support styledComponents, or any valid
| React for that matter. You can even use utility CSS classes in
| code. The design tool can edit some of these today already
| (e.g. you can pass in additional styles to a component
| instance). Better support for creating and managing
| styledComponents / Emotion is high on our roadmap so watch this
| space!
| supermatt wrote:
| Looks nice!
|
| It seems that any "logic" (conditionals, iterators, etc) in the
| components will prevent the component (and their children) from
| being inspectable.
|
| Is the intent to keep it "no-code" in this respect (i.e.
| effectively a visual JSX editor), or will you be adding the
| ability to inspect more "dynamic" components to make it useful
| for app development?
| rheeseyb wrote:
| Our goal isn't a no-code tool, but rather an editor that
| provides the tools for both developers and designers. We're
| iteratively improving the level of complexity of code that we
| can fully parse and expose to the rest of the editor, so you
| can expect these kinds of cases to become fewer and far between
| over time.
|
| If you do have specific cases that you come across and are
| interested in following the development or just want to let us
| know of them, please do file an issue on our GitHub repo.
| hobofan wrote:
| Are you planning to expose the JSX editing capabilities as a
| library, so that it could be used for e.g. non-web-UI
| editing?
|
| I've been working on a React/JSX wrapper for OpenJSCAD (a
| solid CAD library), where the "viewer" (that shows the
| rendered model) offers simple interactivity that is
| decoupeled from the code. It would be amazing if that could
| be extended to allow for editing the code when you interact
| with parts of the model in the viewer (as you would do in
| traditional CAD programs).
| n_morningstar26 wrote:
| We are actually going to start designing our Front end this
| weekend , about to do it from scratch. absoulatly going to put
| this to extensive test.
| rheeseyb wrote:
| Fantastic news! We would love to hear your feedback in that
| case :)
| asiachick wrote:
| So this is cool because it's for React but I'm curious, this is
| not a new idea right? Lots of UI tools hold the source of the UI
| in code. For example the original C# in Visual Studio did this
| IIRC. I think Android Studio does this (well it edits XML which
| is used at runtime?). Swift?
| mashaole wrote:
| maybe this should be a VSCode extension so that it works offline
| aswell
| mattdeitke wrote:
| This is really nice! Although I'd find it impractical to use,
| especially for existing projects, unless it also supported
| different CSS-in-JS libraries (e.g., Emotion, Styled Components),
| rather than inline styles with the `style` prop.
|
| These other libraries offer a great deal of more support, such as
| targeting children and pseudo-elements (e.g., :hover).
|
| Any plans/timeline on adding support for other React-in-CSS
| libraries?
| tppiotrowski wrote:
| This. From the video it's hard to see if you can declare and
| reuse styles or if all styles are inline and need to be
| repeatedly applied to identical components.
|
| Either way, this is really awesome. Huge congrats on the
| release. It reminds me of one of my fav talks which I can't
| find right now but it's a guy that codes up a Mario clone while
| toggling back and forth between the game and the code and
| making changes in the game updates the source code. If anyone
| knows what I'm talking about please reply here.
| throwaway-42808 wrote:
| Probably Bret Victor - "Inventing on Principle" (2012) -
| https://www.youtube.com/watch?v=PUv66718DII
| rheeseyb wrote:
| Bret Victor is our idol! I didn't even have to click the
| video to know exactly which one you were talking about :)
| tppiotrowski wrote:
| 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!
| tppiotrowski wrote:
| This is it!!! Thank you.
| mashaole wrote:
| maybe this should be a VsCode extension that can work offline
| enahs-sf wrote:
| I love that it feels somewhere between figma and xcode. Very
| approachable UI. super cool tool.
| maltenuhn wrote:
| 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.
| zpj5005 wrote:
| Product designer here. I just spent the past few hours fine-
| tuning some visual details in our Figma component library. Now I
| need to file tickets for each change and work with our frontend
| developers to make sure the updated Figma details get properly
| mapped over to React.
|
| I've grown numb to the friction, but I think this Utopia demo
| just reset my pain tolerance. Going back to manually mapping
| designs from Figma mocks to React components feels so dated.
| Almost like those PSD2HTML websites of the early 2000s.
|
| The market absolutely needs a product like this.
| maltenuhn wrote:
| 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.
| jastuk wrote:
| Not sure if you're familiar with the movement, but standardized
| design tokens[1] seem like the future to me, depending on how
| well they are done. There's a list of major vendor like Adobe,
| Figma, etc. that are already onboard and the standardization
| process is progressing slowly but surely.
|
| As I'm designing an app I don't want just click & drag visually
| to get some eye-balled spacing or size value. I want a design
| system with consistent spacing rules. Design tools enable this
| somewhat but the token standardization is pushing this much
| further. For example: there's already a hub/API for
| distributing design tokens to other services. I've seen a live
| demo of Specify[2] pushing token changes from Figma to a GitHub
| PR or creating JIRA task during a design token talk from a
| token w3c group member.
|
| And it's not just about design -> code. If these tokens are
| standardized, design tools themselves (among others) could have
| a standardized way of transferring designs.
|
| Heck, even Utopia could embrace this at some point to provide
| you an alternative view/workflow for your already standardized
| design tokens.
|
| [1] https://www.designtokens.org/
|
| [2] https://specifyapp.com/
| brettcvz wrote:
| Like many others, I think this is _super_ cool, and something
| that I think has been missing in the ecosystem for a long time.
|
| I feel like the thing that would really make this over-the-top
| powerful is deep integration with a component library, either a
| company's in-house one or an open-source library. It would allow
| for super fast UI prototyping that would also serve as
| scaffolding for the full-featured product.
| rheeseyb wrote:
| This is ultimately one of our goals, to allow maintainers of
| those kinds of libraries to publish that kind of integration,
| or for us or even other users to provide it (thinking along
| similar lines to TypeScript type definition files)
| lyjackal wrote:
| Love what you're doing! Happy to hear you have component
| libraries in your plans. I'd love to see this integrated with
| storybook
| bschwindHN wrote:
| How hard would this be to get it working with preact instead of
| react? I always liked that preact has a very easy "no build
| tools" route for creating simple frontends that you can simply
| open and run in a browser.
| m12k wrote:
| I wonder if they've drawn inspiration from SwiftUI?
| rheeseyb wrote:
| Funny you should mention this, we were actually working on it
| for a while before SwiftUI was revealed, but taking a slightly
| different approach at the time (the original approach was more
| inline with Unity, meaning an engine would be required to run
| the apps). We had reached the conclusion that that approach was
| wrong (primarily because of the lock in and how much of an
| uphill battle it would be for us to move to away from it), and
| had just started working on the new code-first approach when
| Apple dropped that at WWDC. Our jaws hit the floor because we
| knew we were on the right tracks then.
| siralonso wrote:
| Yep, I was wondering the same - it reminds me a lot of the
| SwiftUI visual editor in Xcode. Very nicely done.
| ryukafalz wrote:
| This looks very cool. I'm very new to JS/webdev and I wonder if
| it could eventually be possible to use this with react-native (if
| you can't already).
| rvz wrote:
| Great work on this and looks interesting at first glance and very
| happy to see this open source.
|
| Doesn't really look ready or supported out of the box for M1
| Macbooks, unsurprisingly. Probably going to install this on my
| other machine to try it out instead.
| flixic wrote:
| It's a browser based tool. I'm not sure what you mean by
| "Doesn't really look ready or supported out of the box for M1
| Macbooks". JavaScript cannot target chip architectures, AFAIK.
| rvz wrote:
| So you didn't read the prerequisites and the troubleshooting
| sections first then? [0]
|
| [0] https://github.com/concrete-utopia/utopia#troubleshooting
| nkp57 wrote:
| Isn't that for development?
| rheeseyb wrote:
| There is indeed some messing around required, but some of
| our team are developing this using M1 macs
| mrkoreye wrote:
| Very cool! Using "follow me" mode is a neat way to see what you
| are editing in both the code and in the visual design.
|
| We are working on something similar at Builder.io that utilizes
| jsx-lite to allow visual editing right alongside code. Feel free
| to check it out here: https://jsx-
| lite.builder.io/?outputTab=react
| da39a3ee wrote:
| The page is completely broken for me with most links failing due
| to certificate errors: Failed to load resource:
| net::ERR_CERT_INVALID 4b99d2cfb81c64aed531.css:1 Failed to
| load resource: net::ERR_CERT_INVALID cdn.utopia.app/_next/static/
| chunks/webpack-50bee04d1dc61f8adf5b.js:1
|
| etc
|
| Same in Chrome and Safari
| rheeseyb wrote:
| Is this still the case for you? I don't believe we've seen this
| issue from anyone else, so I'm wondering if it was a blip or
| something more insidious
| warpech wrote:
| Gret work!
|
| I find it similar to Hadron App[0] that generates modern HTML and
| CSS. I was very excited about that tool. Unfortunately, the
| blog[1] and changelog[2] went silent last year.
|
| [0] https://hadron.app/
|
| [1] https://medium.com/@HadronApp
|
| [2] https://hadron.app/updates
| iddan wrote:
| I really hope the community will settle on one tool and invest in
| it. Something like that would make React development so much
| easier
| maltenuhn wrote:
| 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.
| cloudcalvin wrote:
| https://journeyapps.com/platform/oxide/
| gervwyk wrote:
| This looks promising! I've been waiting for something like this.
| Will give it a try.
|
| How would you hydrate the app with data while you dev? Feels like
| adding some storybook like features to test components could be
| useful.
| rheeseyb wrote:
| > How would you hydrate the app with data while you dev?
|
| This is precisely what the scenes are for in the storyboard.js
| file - it allows you to create multiple scenes that render your
| components with different data / props.
| codethief wrote:
| > How would you hydrate the app with data
|
| Never heard the word "hydrate" in this context before but it
| sounds very... appropriate :)
| maltenuhn wrote:
| (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.
| guyromm wrote:
| please consider adding support for svelte!
| sktrdie wrote:
| 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.
| 13daug wrote:
| 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 wrote:
| This is why I like Business Process Modelling Language as a
| better UML too
| rheeseyb wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| is this how Framer[1] works? They have a react<>UI
| interactions. How do you see it?
|
| [1]framer.com
| lstamour wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| imvetri wrote:
| Patience. nocode and this both are the same. Utopia will
| evolve.
| trhoad wrote:
| > 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 wrote:
| 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.
| leemcd56 wrote:
| So, say I were to attempt to swap out React for Vue 3, how
| difficult would it be? How tightly coupled is React?
| Jarwain wrote:
| I would love love love to contribute to a vue version of this
| codethief wrote:
| Piggy-backing on this question, is it possible to use React
| alternatives like Preact or my own DIY React clone?
| maltenuhn wrote:
| 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!
| leemcd56 wrote:
| I'm certainly interested! I've been looking through the
| source to see where it all ties in.
| pythonbase wrote:
| How does Utopia compare with Dreamweaver or FrontPage?
| FpUser wrote:
| I am curious if at any point functionality and power of these Web
| tools will ever come anywhere close to something like Delphi.
|
| Nice work anyways.
| ablekh wrote:
| You beat me to it. Good old Delphi ... I still consider UX in
| Delphi unparalleled.
| fwouts wrote:
| This is a really cool idea!
|
| A bit of self-promotion: I've been building something similar but
| without the visual editing, integrating directly in your VS Code
| editor (and soon IntelliJ/WebStorm too). See
| https://reactpreview.com for more info.
|
| Direct link to the latest beta for Visual Studio Code for HN
| friends: https://reactpreview.com/download/releases/reactpreview-
| vsco...
|
| (it's very early days, this beta isn't even a week old, so expect
| to find bugs)
| sgrove wrote:
| 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]
| codethief wrote:
| 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?
| sgrove wrote:
| 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).
| kaladin_1 wrote:
| Nice! I especially like that one can easily view and edit the
| code generated.
|
| How long did it take you to arrive at this version?
| maltenuhn wrote:
| 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 :)
| edulix wrote:
| First, congrats on the tool!
|
| Have you thought about supporting multiple use-cases for each
| component? So for example the component might be showing a list.
| I want to test (and visually design) the use-case when the list
| is empty, then I want to switch and visually design when the list
| has one element, then when the list has a lot of elements..
|
| Also it would be great that in those cases you could define not
| only the data but also the surrounding canvas and browser
| properties. Test&design for mobile, laptop, dark background, old
| browser, changed styles, etc.
| m12k wrote:
| It seems to already support that - see the section "Working
| with generated and conditional content"
| lolive wrote:
| Just wondering: how is it different from a live reload yarn run
| serve+IntelliJ +a browser?
| nicoburns wrote:
| It lets you edit things inline like the browser dev tools. And
| drag them around like Figma.
| flixic wrote:
| 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.
| voldemort1968 wrote:
| Well, It is an interactive GUI for one...
| tmp_anon_22 wrote:
| Wouldn't this be better as a VS code plugin versus a web-based
| tool?
| Mavvie wrote:
| I agree, but is it even possible to effectively monetize a VS
| code plugin?
| dzsodzso wrote:
| E. G. https://wallabyjs.com/ does pretty well
| Aeolun wrote:
| Or a full electron app. Not sure I like the idea of uploading
| my code to test.
| jimsmart wrote:
| It seems to be open source - one might imagine it can be run
| as a local instance?
| runeks wrote:
| > Wouldn't this be better as a VS code plugin [...]
|
| I think it is: https://github.com/concrete-utopia/utopia#build-
| editor-vscod...
| maltenuhn wrote:
| (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.
| abraxas wrote:
| After five minutes of playing with it and failing to find it...
| where is the panel of components to drag and drop into the tree?
| Seems like the most basic functionality in an editor like this.
| Something that VB had in 1993. This should be something that is
| obvious and visible on a first glance.
|
| Another issue I have with the UI is that a lot of elements are
| greyed out even though they remain interactive. The convention is
| that UI elements that are greyed out are not interactive due to
| the current state of the application (wrong mode, unmatched
| requisites etc). This application seems to violate that and I'm
| still baffled as to what greying out of UI elements means in in
| this app. If they aren't disabled why are they greyed out?
| dvt wrote:
| 25 years later, and we're back to FrontPage. _" Time is a flat
| circle."_
| rho4 wrote:
| I'm getting old, too *sigh.
|
| Technology stacks appear, and go right ahead reinventing
| dependency managers and repositories, IDEs with autocompletion,
| refactoring & WYSIWYG editors, a strong type system, comments
| and schema validation for configuration file formats (JSON)...
|
| Nice work though, looks really promising!
| jaggederest wrote:
| Something something smalltalk in the 80s something something.
| I'm old enough to remember Smalltalk systems running on Sun
| workstations being a thing. I still don't know if we've
| reached that level of development effectiveness with modern
| tools.
| speedbird wrote:
| Yup, worked with that, was great.
|
| Needed Envy VC for teams though.
| jaggederest wrote:
| Ah, haven't heard of that, I was just a wee lad at the
| University computing center before I got out of high
| school.
|
| This what you're referring to?
| https://paulhammant.com/2017/09/01/smalltalk-envy/
| e12e wrote:
| I can't recall front-page doing script/interactivity much? This
| is more like Dreamweaver?
|
| Ed: it's strange that the lively-kernel.org approach (the
| Self/Smalltalk approach) never did seem to gain any real
| traction. Rather we get these odd half-meassures like source-
| maps, bundled js and what-not.
|
| Well, any small progress towards the 80s in the 20s is good i
| guess...
| cutler wrote:
| Dreamweaver Ultradev, released in 2000, was the first version
| to introduce scripting with PHP and ASP.
| e12e wrote:
| Oh, I'd blocked out server side script support. As if the
| Javascript widgets weren't bad enough :D
| canada_dry wrote:
| > 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 wrote:
| 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).
| pjmlp wrote:
| Dreamweaver is still around actually.
|
| https://www.adobe.com/products/dreamweaver.html
| dvt wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Also: Visual Basic and Delphi.
| shpongled wrote:
| Visual Basic was my introduction to programming - I still
| have somewhat of a fondness for designing GUIs in Visual
| Studio
| maga wrote:
| 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 wrote:
| As a kid (and adult) you _need_ to see some immediate
| tangible result of your virtual labor.
| rheeseyb wrote:
| 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.
| [deleted]
| systemvoltage wrote:
| This is why it's important to evaluate tools without
| bandwagoning and believing the hype. Sometimes, the hype turns
| out good, but more often than not it doesn't.
| rattray wrote:
| 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?
| maltenuhn wrote:
| 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.
| deft wrote:
| This is cool, the UI and preview reminds me of BB10's IDE for
| qml... Still miss those days and I still don't understand why we
| don't have qml for the web.
| teryyy wrote:
| Awesome to see it's open source.
| rheeseyb wrote:
| Yeah we wanted to go the open source route from the beginning.
| The thinking was that it would help us build a community with
| meaningful relationships with our users (or at least the ones
| that get annoyed enough to log bugs or even contribute), but
| also most of our favourite tools are open source.
| raidicy wrote:
| As soon as I resize the code menu this[0] happens. Everything
| shifts up and I cannot scroll it down or get it back to normal
| without refreshing.
|
| [0]https://imgur.com/a/N82Zutz
| rheeseyb wrote:
| Hmmm that's incredibly frustrating. I'm trying to reproduce
| this but failing. Are you able to do this every time? If so is
| there any chance you could take a screen recording please to
| help us debug it?
| raidicy wrote:
| First I have to apologize. I hadn't upgraded chrome. After
| updating it did not happen again on chrome. It does happen on
| firefox[0], and I do realize that you've stated your app
| works best in chrome.
|
| Lastly, thanks for making this. It looks really cool.
|
| [0]https://streamable.com/jth0pn
| vittore wrote:
| So they invented react-aware FrontPage ? =)
| maltenuhn wrote:
| 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"
| systemvoltage wrote:
| Macromedia Dreamweaver :-) I have extremely fond memories of
| setting up an FTP access from cPanel (you all remember cPanel,
| right?), then syncing the website through Dreamweaver over FTP.
| It was awesome. Those days were the best I don't care what
| anyone says.
| imvetri wrote:
| this looks awesome! Great job and its a great team work.
| forkLding wrote:
| This looks amazing, cant wait to try it out
| tamersalama wrote:
| Why is CSS & HTML written in JS?
| jimsmart wrote:
| This ticks so many boxes for me - I've been wanting a code-based
| visual editor for React since like forever.
|
| Thanks! :)
| imvetri wrote:
| How does it detect source element when hovered on preview?
|
| Preview would have a dynamic ID that maps to the source JSX.
| rheeseyb wrote:
| 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.
| imvetri wrote:
| Thanks for the explanation
| wheybags wrote:
| Ctrl-f "winforms" - 0 results. Really?
| jarym wrote:
| When you see things side-by-side you realise the React devs
| foisted XML back onto the world :D
| trenchgun wrote:
| JSX is XML... but with blackjack and hookers?
| maltenuhn wrote:
| ...in fact, forget the XML :D
| AbolTabol wrote:
| Product Designer here. Is there a specific reason why
| tools/demos(Framer comes to mind) such as these are tied to
| React? Is it just because of the popularity of React these days
| or is there a technical reason for it that's lost on me?
| cdaringe wrote:
| React/JSX converts what was previously DSLs nested within DSLs
| into code. This is why dev tools like this oft use React, or
| more specifically JSX. It complements the HTML DSL, but in a
| coding context. Most other similar browser tools use templating
| mechanisms with DSLs for embedded logic. For this reason, React
| will have jQuery like longevity, and people will continue to
| design for it. It's easier to code for code than multi-layer
| DSLs (see Jinja, Vue, angular, swig, etc). Forgive me if that
| was a little meta or over simplifying.
| clemens_m_12 wrote:
| As someone who worked with React, Angular and Vue
| professionally the last 6 years I cannot agree.
|
| React will be around for a while because of its popularity.
| It has nothing to do with JSX. Acutally, Vue, especially Vue
| 3 with the compositiona API is much easier to work with than
| React. You could use JSX with Vue as well. React has quite
| some leaky abstractions, which makes it more hard to master
| than Vue or Svelte. React seems easy, but it is not.
| kyawzazaw wrote:
| React is very popular in the market.
| madrox wrote:
| We used to call this WYSIWYG editing, and it ushered in a whole
| generation of FE and flash devs. Editors like this went out of
| favor because, sadly, it can never quite keep up with the cutting
| edge.
| ablekh wrote:
| Pretty cool, congratulations. Any plans to support Vue in the
| future?
| maltenuhn wrote:
| 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!
| phreack wrote:
| Damn, I'd been meaning to build exactly this for ages but never
| got around to it. It's always felt like a key missing piece,
| particularly after working with tools like Android's preview tab.
| Major kudos to the team!
| maltenuhn wrote:
| 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!
| deanclatworthy wrote:
| Big no for me if styles are injected as inline styles. As a
| developer I don't want to work with that generated code. At the
| very least look at using styled components or generate
| accompanying css module file.
| trenchgun wrote:
| Yea, optimally it would give these three options as
| alternatives for user to choose.
| trenchgun wrote:
| See: https://news.ycombinator.com/item?id=27522714
| Kiro wrote:
| What's the problem with inline styles? Just curious. Trying to
| understand what the difference between styled components and
| inline styles actually is in this case.
| maltenuhn wrote:
| 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.
| clement75009 wrote:
| Very impressive!
| jzig wrote:
| Excellent, now do one for Angular! And Web Components!
| brighthero wrote:
| A tool I've experimenting with a lot recently is
| https://www.plasmic.app/
|
| It outputs React code as well. But the approach is more similar
| to Figma. You can create components with variants etc.
|
| It can automatically sync changes to your local repo or create a
| pull request on GitHub.
| krmmalik wrote:
| I am very interested in this. I am a low-coder you could say. I
| have to start coding a front-end in React soon (and I have yet to
| learn React) so with all the overhead of learning React as well
| as fiddling with html, css etc, it feels like a really big task.
| I saw some visual builders for React , downloaded/tried a couple
| but they had pretty big learning curves of their own so I didn't
| bother taking it any further.
|
| You guys seem to be addressing the right pain point in the right
| way.
|
| I will definitely give this a go soon
| 123jay7 wrote:
| If you are learning, you should stay far away from "visual
| builders". Unfortunately, these things will make you learn
| slower because they often prioritize visual design over sound,
| structural code. Learn the basics first. If you want to learn
| React, just download it, read the official docs and use
| `create-react-app`.
| bayjorix wrote:
| Thank you! I'm one of the developers working on Utopia.
|
| > I saw some visual builders for React , downloaded/tried a
| couple but they had pretty big learning curves of their own so
| I didn't bother taking it any further.
|
| This was our experience with existing low code or code
| generating design tools as well - you actually have to put a
| lot of time into learning how to use them, time you could spend
| on learning actual React.
|
| One of our guiding principles was that people who use Utopia
| should not need to learn anything that is proprietary to our
| platform.
| kyawzazaw wrote:
| I am student and I think my instructors who teach a Software
| Engineering class would be very very interested. We typically
| have non-CS majors in that class and it can be a bit of a
| learning curve.
| rheeseyb wrote:
| Helping people learn to code is something that we're very
| keen to achieve with Utopia.
| Jakobeha wrote:
| I always wanted a tool like this, and wondered why it didn't
| already exist. Many others have tried this before (code + visual
| editor, albeit not necessarily React). I'm interested in what
| challenges the developers faced to make this and how they
| overcame them.
|
| If this works well, it will be amazing and I'll almost definitely
| use it for my next webapp.
| hondhan wrote:
| Is Vue support in the works? Or maybe even react native?
| hondhan wrote:
| 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!
| mxstbr wrote:
| 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?
|
| [0]: https://blocks-ui.com/
| radiKal07 wrote:
| This is so cool. I built something similar for my startup
| https://panakit.com. It's a tool de create blogs and I have a UI
| builder where users can customise the blog. The code is hidden
| away since it is aimed at non-tech people. My UI builder is way
| limited in functionality and only works for blogs and it was
| still quite a bit of work to build, I can't even imagine the
| amount of work your tool required. How do you plan to make money
| out of it?
___________________________________________________________________
(page generated 2021-06-16 23:02 UTC)