Show HN: Open-sourced Webflow for your own app (github.com)
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 :)
100 comments
[ 2.1 ms ] story [ 177 ms ] threadThis is exactly the goal :)
To ramesh31 point, we're trying to be cognizant about not putting bloat into the code as we support things like inserting new components since that is where these types of tools typically converge.
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.
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.
Sorry for the confusion, this is an Electron app. I just didn't ship an executable with it at the moment.
> I could see an easy integration to push your page up to a CDN or GH Pages instance.
That is certainly in the cards. Though, in my opinion, it becomes more useful to edit complex web application since there are many tools supporting static sites but not many for production web apps.
> 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
I am guilty of this. My long-long term hope is to be able to collaborate better with my product folks where they are able to enact their own intuition in the product instead of having to go through me for every change needed.
While this is easy for a marketing page, it's much more difficult to do in a complex application context.
> there are many tools supporting static sites but not many for production web apps.
The funny thing is that the only true WYSIWYG tool I can find that isn't part of a paid SaaS ecosystem or complete inflexible garbage is Adobe Dreamweaver, which has been dying a slow death for decades. It has a few positive traits-- it makes responsive designs, works with bootstrap 4 and a few CSS libraries which make relatively clean code rather than spinning up the inscrutable spaghetti monsters it did in the aughts, and has a really solid built-in code editor (which I assume is Brackets on the back end) but there are bits of primary functionality that have just been broken for years and clearly not on the docket for an update. I looked at it for a few hours last week and decided it probably wasn't long for this world.
Of course you can't spit without hitting an SSG with hot reloading, and in-editor previews are de rigueur, but none of those offer a visual-first workflow for page design, which is what a professional designer really needs. You can have document-style WYSIWYG editing a la TinyMCE, which is fine for a blog post, but if you want to put together the structure of a page from the ground up, you're still context switching between an editor and a browser window which is an ineffective way for designers to work, even if they have the knowhow.
> While this is easy for a marketing page, it's much more difficult to do in a complex application context.
Sure, and this would have saved me some time in the various complex web apps I've made. But for the technically simpler use cases like my portfolio page, unless you're going to use Squarespace, Wix, Artstation, Webflow, etc etc etc and buy into their ecosystem, there really is no option for people that need reasonable control over the site's design without a code-first approach. Aside from Dreamweaver, I think the only one I could actually locate and install was part of Sea Monkey, and it seems to be an... uh... let's say under-loved part of an already under-loved suite of tools. And while my portfolio or a marketing landing page are technically simpler, the quality of the layout is often significantly more important than it is in a web app. Web apps usually convey factual information, figures, maybe provide tools for modifying things, etc. In a marketing page or a portfolio, what you're trying to communicate-- vibe, flow, visual movement, and other intangibles-- takes much more nuance.
(In fact, when developers see a software interface they think was 'ruined by a designer', it was usually ruined by a project manager or a developer trying to make something 'look designed' by mimicking some simple, elegant design they saw that was totally inappropriate for the application. Then they call someone like me. :-)
Someone above suggested https://bootstrapstudio.io/ which seems to fit the static page use case very well.
> it was usually ruined by a project manager or a developer trying to make something 'look designed' by mimicking some simple, elegant design they saw that was totally inappropriate for the application.
This hits home for me as someone who ruins design to ship faster. I think dev being the gatekeeper for UI can turn out badly when we start cutting corners or inserting our own opinions into the implementation.
I hope giving designers the ability to contribute on the UI side can alleviate this issue.
The problem there (and this is from experience building and supporting such a tool for non-technical users) is that people learn. Anyone who spends enough time in one of these tools will quickly pick up the fundamentals enough to become frustrated with the limitations. Or their engineering team will see the inneficient code being created and take it upon themselves to just implement these things quickly and simply. So you can start leaking the abstraction and allowing custom CSS/HTML, but then you very quickly arrive at a place that is useless for both teams.
There is a place for both. You don’t need to spend much time on here, reddit, or many other forums to find people complaining about the lack of decent middle ground tooling to get started with front end dev.
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...
What does `UX from jumping around to multiple pages` mean?
There's also the platform risk with Chrome Web Store being poorly supported. I've had important updates take up to a week to come out for no transparent reason.
It might just be a UX we have not cracked but it was easy to onboard, hard to stick. It is also unceremoniously open-sourced so if you want to take up the code I'm happy to support that.
https://youtu.be/pUzCOpIE1zQ?feature=shared
https://chromewebstore.google.com/detail/onlook/icbcddooibfg...
https://github.com/onlook-dev/monorepo
This is an interesting take. My interpretation: You can host this on a server, then expose a port remotely which will have all the access of the electron app, making it a pseudo SAAS?
I will need to test this out but this has some cool implications. The other worry is multiple client support but you can just provision a personal instance.
https://www.cohnlg.com/the-nuances-of-trademark-use-in-adver...
It looks like you've got a really nice product idea here! And Webflow has raised hundreds of millions, so they have a war chest for this kind of thing. I just don't want to see you run over later.
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.
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.
At the core, we generate pure HTML and CSS, then serialize those into React and Tailwind. It would be one less step to expose the HTML and CSS instead. I wanted a narrow scope to this so that's the focus but I imagine there's a plugin setup we can do to swap in what framework (or non-framework) you would need.
have you considered paying developers or supporting open source software? I doubt it.
Once you build the pipeline, it's not that hard to maintain CDN releases.
GP was just voicing a wish that a certain piece of software or service as described without predatory pricing exists.
They never said they wanted it for free, you did.
If Webflow had a competitor with same functionality and reasonable pricing I'd gladly pay for that.
[1] https://github.com/beenotung/auto-cms
My suggestion is keep offering it as OSS, but offer a hosted version as well.
I would think, that is the obvious monetization plan?
I know Supabase has a similar and successful monetization plan but I know some take issue with the way they offer their hosting.
I agree. Do you have any tips here besides being good with answering questions, documentation, and otherwise continuing to work on the project?
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?
Sorry for off-loading the research to you but how does it compare to SingleFile (Chrome extension based)? I can't tell what the output would be.
https://github.com/gildas-lormeau/SingleFile
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?
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.
https://github.com/beenotung/auto-cms
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 :)
Yeah monetization is always tough, especially with something like this. My thoughts (were I in your position) would be to offer a full/unrestricted and open source single-player mode (open core model, with core licensed AGPLv3) that just modifies files on disk and is otherwise completely ignorant of git or anything else. Then for paid/hosted version, on top of it being hosted, you get full integration with github so PRs and diffs and things can be sent directly from the tool (which is great for designers). That also wouldn't require devs to do anything to buy in since the interface for them is just standard PR workflow.
If it were me personally, I'd probably make the whole thing ("enterprise" features and all) open sourced under AGPLed with monetization being a hosted version available for paid stuff. Make sure you own the copyright so you can relicense in the future should that become necessary. I think you still get the vast majority of users that would be willing to pay that way, but you also get that crucial group of people who want the option of ejecting from you as a vendor should you go a directin they don't like (enshittification, etc). It's also IMHO a very ethical way to do business. Register trademarks on your app's name and stuff, and defend them proactively. Worst case scenario if someone forks and tries to compete with you, at that point you exercise that copyright to relicense the different parts to the "open core" model. It isn't likely to ever be an issue, but if it did you have a move.
For targeting devs vs designers, IIWM I'd probably make the UI modal. I.e. design mode vs developer mode. Design mode can cater to designers, dev mode to devs. That way you can make UX decisions for one group that would irk the other group.
That's my impression too. Designers I know do not want to deal with the command line or git directly. I can't think of any products where that abstraction is done well (unless it's so good that I didn't notice).
Thank you for the very in-depth take. We're figuring out monetization so this is very actionable + relevant.
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.
“Schedule demo” sounds too enterprise-y and makes me feel like it isn’t self serve.
here's another approach I used with dynamic react
https://github.com/mhsdesign/jit-browser-tailwindcss "dynamic tailwind"
With Builder.io, you have to set up a component to inject their UI into your app. It's more difficult to set up and maintain the components. We're opting to give full control of the code. You can develop with Onlook locally without internet for example.
This is my biggest objection as well. Along with not having my code locally.
> I hope this project continues to grow by leaps and bounds!
Thank you for the kind words!
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.
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
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.
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.
I'm always happy to talk about Svelte! Though, I'm starting to enjoy the flexibility of jsx now that I'm back to using React.
https://github.com/onlook-dev/monorepo
https://x.com/D_R_Farrell/status/1795940373883220429
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.
https://news.ycombinator.com/item?id=27516212