Show HN: Open-sourced Webflow for your own app

[hoakiet98]

Hi HN, I’m Kiet, one of the creators of Onlook studio. I made this app that allows you to visually edit your locally running React app and write the code back to it in real-time. The purpose is to allow you to develop UI while fully owning your code the whole time. There are other visual builders out there but they either require you to upload your code to the cloud or some lengthy setup process. Onlook runs locally, deterministically, and only requires adding a plugin for the compile step (2 lines of config change).

Technical details: This is technically a web browser that can point to your localhost, which injects some CSS into the page that allows you to select, drag, and drop DOM elements, then track and translate those changes back into React code. Theoretically, you could do this with any compiled framework but I wanted a reasonable scope for the launch (the first version was actually in Svelte).

Some interesting challenges: 1. There is a React parser that is used to parse, insert the style, and serialize it back to code 2. There is a React pre-processor that traces the DOM elements to the corresponding code 3. There's also CSS parsing, injection, and converting to Tailwind 4. This is also an Electron app so there’s a browser within a browser within a node app which makes message passing… interesting

What’s next? We’ve already built a proof-of-concept for inspecting and selecting layers, dragging to reorder, and inserting new DOM elements that I’m working on porting over from our private codebase. We’re also exploring opening more tabs in new frames in order to A/B test the changes before committing to code. There’s a long tail of exciting features we can do but I want to put this out there first and see what others would need.

Let me know what you think/feedback. It's been a blast working on this so far and I think it’s just neat :)

[ENGNR]

I think you're onto something. I'm not sure what you mean by 'components' on the roadmap, but if it's the ability to bring react components back into the editor, and have the designer WYSIWYG modify the props - that's the exact thing we've been saying "suuurely this must exist" for a long time (rant mode enabled).

The key pain for us that I think you're touching on is that "design/dev mode" isn't how teams actually work. Devs do far more design than we think. My experience is that designers do the pretty or complex pieces, while dev does the long tail "boring" designs. Often devs do the screen layouts since nav and routing can get a bit complex. Secondly, designers don't just hand off a design and that's it. The design system gets implemented as components, which have tweaks due to usability/issue reports/further design, and then the designers really want to be taking those components and recomposing them back into sections and screens. Ideally designers would be just setting props like images, text and ids faaaar up the abstraction layers, with dev components being automatically synced back in as they're built and updated.

So definitely think your setup is potentially hitting a sweet spot between dev/design. Just to validate it as as product - plus one for open source with a paid hosted tier for convenience. Devs get to tinker, and designers don't have to think about how to run it.

[tmcdos]

This is exactly what Delphi does for desktop Windows applications - arranging components on a "form", tweaking their properties (props) through the ObjectInspector, assigning event listeners and quickly navigating to their handler functions in the code. It is such a breeze compared to Web development ...

[hoakiet98]

> but if it's the ability to bring react components back into the editor, and have the designer WYSIWYG modify the props

Haha yeah this is the plan. I really like Storybook for this reason but I loath the setup you need to do to expose every single prop.

It seems straightforward for me to parse the React node and expose the inputs such that you get a Storybook experience that is also editable. I'm sure there are unknowns that will show at implementation time.

> Devs do far more design than we think.

I also think devs do more design than we should. I've never been handed a design where I don't run into edge cases at implementation time. At this point, I have to go back to the designer to clarify. The hope is that if designers are more involved in building front-end, they will hit these edge cases before handing them off.

> a paid hosted tier for convenience

This is a great idea, the goal is to get a point where designers just don't have to think about it

[rsp1984]

This looks pretty awesome but, speaking only for myself here, the thing I actually want is just Webflow but without the BS and predatory pricing.

A visual editor that produces plain old HTML, CSS, JS and that anyone in our company can use to make changes to pages or create new ones. That's it.

I don't think it exists (if so, pointers would be very welcome!), so here's my comment to incentivize someone to build it.

[freedomben]

I agree. What I personally would love is a WYSIWYG front end to a static site generator that uses eex or erb. If the tool is sufficiently open source and works well with some hand tweaking of generated HTML, then eex/erb isn't strictly necessary.

I'm optimistic about this though, because my suspicion is that since this tool just exports React, you could relatively easily achieve this using Next.js SSG building. As long as you aren't doing any build time or runtime dynamic data loading, by adding one more step you can use this for that, with the bonus that if complexity goes up to the point where you would want to componentize, your tool is ready for that.

[gargan]

"the thing I actually want is just Webflow but without the BS and predatory pricing" - checkout Webstudio, it's free and open source - https://webstudio.is/

[aabbcc1241]

You can try to use auto-cms [1], it works on plain HTML and light js-enabled interactions.

[1] https://github.com/beenotung/auto-cms

[localfirst]

but this is a tough problem with constant maintenance involved and you want it solved for free and handed to you on a silver platter

have you considered paying developers or supporting open source software? I doubt it.

[freedomben]

Thanks, this looks pretty neat! Definitely a project to keep an eye on :-)

I love the approach of having it show you the code (and diff) and control on writing it back. This seems like it may be very useful!

As an AOLPress user back in the day, it's both really surprising that in 2024 we don't have more WYSIWIYG tools, but also understandable because of how hard it is to design one.

Most tools end up trying to find a sweet spot between targeting a developer and targeting a designer, and as a result end up doing neither well. There's also the problem of what kind of code it generates, and how to generate good/maintainable code that doesn't tie you to the WYSIWYG tool for the rest of its life. I haven't had a chance to try this yet (though I plan to) so I'm not certain where it falls on each of these, but from the video I get the impression that you are well aware of these challenges.

Thanks for sharing, and thanks for making open source!

Edit: Adding a couple of question:

1. Are you planning to monetize? If so, what are some of your ideas?

2. What is the grand scope for Studio? It sounds like the immediate focus is on editing styles. Are you planning to keep the scope limited to that, or would this eventually become an everything-you-need-for-building-a-website type of tool?

[hoakiet98]

> 1. Are you planning to monetize? If so, what are some of your ideas?

Yes, though my plan is not concrete, yet. I plan to offer a hosted version for teams with fewer technical members to be able to contribute the same way a front-end engineer would without self-hosting.

This involves potentially hosting their app along-side the editor and creating friendlier abstractions on top of the git process such as creating branches, PR's, etc.

Secondarily, I want to explore collaboration as a feature. The overall theme is to bring less-technical folks into the front-end.

> 2. What is the grand scope for Studio?

Short-term, I want styling to be very good. Then text content for copy-writing. Then structural changes such as reordering, inserting, and removing DOM elements.

I want to keep it in the UI as much as possible since the surface area for logic is very large. I don't know if we can really be Webflow while letting users maintain full control of their code so if we have to compromise, I would lean more into giving control to the user instead of doing powerful features.

Please let me know your thoughts on this plan, it is still in development :)

[hoakiet98]

> Most tools end up trying to find a sweet spot between targeting a developer and targeting a designer, and as a result end up doing neither well.

Emphasizing this because this happened to us. The initial version was trying to cater to designers and it was very hard for them to get value out of the to-code part because they need to convince the engineer to set up the codebase. Then when we add more support for engineers, it alienates the designer.

> generate good/maintainable code that doesn't tie you to the WYSIWYG tool for the rest of its life

Personally, this keeps me off most WYSIWYG. We don't have a great answer to this yet besides having a very narrow scope that works for our internal setup without polluting the code.

[wiradikusuma]

If you use Bootstrap and are more towards "static" websites, I recommend Bootstrap Studio (https://bootstrapstudio.io/). I used it on and off. Last time, I used it to make one-off HTML, then edit the rest by hand (meaning, I can't return to the app again to make changes).

But recently, I used it to develop https://momenial.com/ with 100% editing in the app. Meaning I can use the app to make changes. I _do_ still need to make minor edits (that I think I can automate using a script).

It's not perfect (e.g. it can't import existing design, gosh I wish!), but it gets the job done for design-illiterate people like me.

[hoakiet98]

That's very good results and nice UI. I hope we catch up to this level of quality one day. Thanks for sharing!

[karaterobot]

This looks cool. I always thought that Webflow's model for how to snap together a UI was a good intersection of pick-up-and-play simplicity and just enough customizability under the hood. But they're a bit expensive, and I hated having my projects under their control. I hope this project continues to grow by leaps and bounds!

[fswd]

> Some interesting challenges: 1. There is a React parser that is used to parse, insert the style, and serialize it back to code 2.

here's another approach I used with dynamic react

https://github.com/mhsdesign/jit-browser-tailwindcss "dynamic tailwind"

[_fat_santa]

I think one challenge that you will face is that Webflow is a SaaS app while your app I have to host somewhere. If I'm a non-technical user then I have no idea how to host this thing myself and will just go to a competitor. On the other hand if I'm a developer then I have to weigh the time it would take to host and maintain the app versus just building a regular react app from scratch.

My suggestion is keep offering it as OSS, but offer a hosted version as well.

[hoakiet98]

> If I'm a non-technical user then I have no idea how to host this thing myself and will just go to a competitor.

This is a good suggestion.

My plan is: 1. We start with packaging the Electron app as a downloadable. You'll still have to run your localhost app with it.

2. Then we'll add some UI support for cloning and running your project directly from the app.

3. The last step is to provide hosting for your app but I don't think we have the resources to do that well at the moment.

What do you think about this plan?

[lukan]

"My suggestion is keep offering it as OSS, but offer a hosted version as well."

I would think, that is the obvious monetization plan?

[danielvaughn]

Looks interesting. One word of advice - the CTA "talk to a founder" makes me stop and think. I wondered to myself "why would I want to talk to a founder?" You don't want the user doing that, it should be obvious.

I'm pretty sure that button is for a demo, so you want to phrase it in terms of the value to the user, i.e. "schedule a demo" or some variant thereof.

[noorvir]

I would say the opposite. I much prefer the “Talk to founder” option. I regularly use this to ask the founder to clear up concerns I have before trying a new product. It also has a much more personal touch to it. I think this is especially important for an early stage compony.

“Schedule demo” sounds too enterprise-y and makes me feel like it isn’t self serve.

[hoakiet98]

Good catch, thank you. Changed it to schedule a demo.

[edweis]

Similar and also very neat: https://luna-park.app/

[hoakiet98]

How cool! There's a lot to learn from here. Thank you for sharing.

[meiraleal]

Is it open source?

[patrickaljord]

Looks great. Any plan to make it work in a browser instead of having to install an Electron app?

[hoakiet98]

No plans for now, this seems to be the best form to support the features we need.

It was initially a Chrome extension [1] but there were limitations with local file access and UX from jumping around to multiple pages. Very early on I developed this as a web app but it was also difficult to inject styles into iframe, especially for ones that we didn't own directly.

Electron ships Chromium by default so it was easy to leverage into an editable browser plus allowing us to do an infinite canvas style editor. If you know of ways around these limitations please let me know. I'm always trying to figure out a way to turn this into a web app instead.

[1] https://chromewebstore.google.com/detail/onlook/icbcddooibfg...

[freedomben]

Having it edit local files might be a difficulty of having it work in a browser instead of electron app. That said though, Electron apps I've worked with in the past usually have a "dev" mode already that just serves locally and you hit it with your browser (i.e npm run dev), and that browser allows using the APIs normally not allowed so long as it's being served from localhost. Might be a good solution.

[yakito]

I agree that this would be a great addition.

[ramesh31]

The main problem with these kind of tools is that they sit in a "dead zone" of being too in depth for non-technicals, yet too limiting and inefficient for engineers to bother with, as they end up injecting a huge bundle on the page just to render a form. How are you solving for that?

[hoakiet98]

This is very astute. We went too far in the non-technical route the first time. It was unrealistic to expect a non-technical person to clone or run code locally so it was hard to get to the value point for them.

Hence, we're focusing on this being more efficient for the engineer. We're limiting to just injecting clean styling for now which is where I personally spend too much time with UIs.

The initial goal is to shorten the loop between code, save, check the browser, adjust code, repeat... and just give engineers the ability to edit the page directly like you would a Figma prototype.

[DrewADesign]

While that might be true at the moment, this is a (well designed) electron instance (edit: exists? I only saw install instructions for NPM so maybe it just needs built executables? it says it uses electron) away from being a modern replacement for WYSIWYG editors like Dreamweaver. I could see an easy integration to push your page up to a CDN or GH Pages instance. Even without, there are tons of places for moderately technical people to host static websites, and “upload the code and pictures to a server in this folder” is within many more people’s technical grasp now than it was 20 years ago. Most people don’t need all of the scaffolding most modern dynamic websites have. Online SAAS WYSIWYG web authoring tools— wix, squarespace, Wordpress, et al— have been the only practical option for people without front-end dev skills; beyond that, you’re in SSG land which requires a big jump in knowledge for very little gain in utility until you really start getting some dev knowledge, and most people don’t want or need that knowledge. Being able to stand up a site and tweak the code here and there to do something a little different is a great spot to sit in. Hell it’s what got me started on web stuff with my geocities site nearly 30 years ago.

I think this is a great example of why we need more product people involved with FOSS. Having worked in dev for quite some time before I got into design, I’ve experienced the blind spots inherent to having a purely technical focus. From the dev perspective, user needs often seem straightforward or even intuitive, but that’s heavily skewed by a completely different approach to using and reasoning about software than end users have. Developers are often pessimistic about users that seemingly always fail to grasp something they consider trivial, but developers rarely have to confront the actual complexity of other people’s jobs. Lots of people are smart and can solve problems, even if they don't have a formidable mental model of software development. Tweaking basic HTML/CSS generated by something else is well within their problem-solving capability and doesn’t require much technical know-how.

[nobleach]

I consider that zone to be a new "sweet spot". A new generation of "web devs" can circle around a tool like this. Our current in-house tool is a drag and drop editor that allows slices of content to be stacked. Each of these slices has preprogrammed selectable options for things like colors, sizes, body copy, headlines, etc. We consider this far too limiting. Now I will agree that my use of Webflow had me beating my fist against my desk. I could do the same thing in straight HTML in 15 minutes, that took me an hour or so in Webflow. Much of that was the learning curve; figuring out "the Webflow way". I see a future where we have tons of people who are good at these low-code/no-code tools. Sure I can run circles around them by being able to write all the code by hand. But for most things they'll be "good enough".

[toddmorey]

This... isn't that. Changes made in the visual editor are translated into code and submitted to your project as a GH pull request for review. So from a project / software perspective, it looks and works like a FE engineer committed a code change.

[aneeqdhk]

Pretty cool! I recently came across WeWeb (weweb.io) which also allows for exporting code, and is quite feature rich in its visual editor

[hoakiet98]

Look awesome! Everyone has such nice sites, we need to catch up.

[bbourn]

This is amazing, thank you for building!!!

[hoakiet98]

Thank you for checking it out!

[kkyr]

Love your landing page! What did you build the animation at the top of your page with?

[coryvirok]

Why did you decide to rewrite this in react vs svelte?

As someone who loves svelte and whose been writing a fairly large svelte app but has been jealous of the react ecosystem, I'd love to hear your rationale.

[hoakiet98]

It pained me to do this. Everyone I talked to used React instead of Svelte. At some point, we realized we were spending half the time supporting Svelte just for ourselves for <10% of the return.

I still love Svelte and will continue using it for side projects but right now I think the tech needs to get out of the way of the better user experience.

[blacktechnology]

This is THE tool I'm looking for years!

[nm769]

super cool! very very similar to Utopia: https://utopia.app/ maybe you can work together on this :)

https://news.ycombinator.com/item?id=27516212

[hoakiet98]

Utopia is super cool. Thanks for sharing :) I believe someone from the team reached out

[sexy_seedbox]

I would pay top dollars for this if you can integrate it with Microsoft PCF along with their build tools.

[denkmoon]

Damn this looks like even I could make decent web applications in it. Pretty cool.

[autorun]

also reminds me about https://puckeditor.com