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?
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.
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.
I get where you're coming from. FWIW, at many points I considered just paying for Webflow but their pricing is just nuts. I'm simply not going to pay ~ $1k per year for them to host my static site with a couple 1000 visitors per month.
If Webflow had a competitor with same functionality and reasonable pricing I'd gladly pay for that.
you are missing the point: if you don't have a business case for spending $1k/year then your problem is not worth solving
There's really not much maintenance for maintaining simple static assets.
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.
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.
Pinegrow Web Editor and Bootstrap Studio could fit the bill. No subscription, no cloud, one-time purchase. Exported HTML is fully readable and editable outside the app.
because my suspicion is that since this tool just exports React, you could relatively easily achieve this using Next.js SSG building
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.
You can try to use auto-cms [1], it works on plain HTML and light js-enabled interactions.
Watch out for trademarks. Your slogan “The power of WebFlow for your React app” is going to attract attention from Webflow’s legal department if your project is successful.
Agreed. I was worried that it's derivative while trying to communicate what we do succinctly. I know Supabase does the same thing with Firebase but our wording might be more problematic.
Honestly I would change that wording immediately. Even being pretty savvy with this stuff, I thought this was an open-sourced webflow when I skimmed it and I assure you, if they even vaguely consider this a future threat to any of their business at all, their counsel will use it as a legal cudgel to bludgeon you.
I agree "the power of webflow" implies a connection. "inspired by webflow" would be probably better, but even there I am not sure if it is safe enough.
Absolutely. If I came out with a project that said "Get the power of Oracle with a simple javascript API" people would think I had a new Oracle API for javascript, not that I had a JS-friendly database I thought was as good as Oracle. But before I even mentioned webflow at all, I'd first want to make sure they didn't have any related patents I'd be bumping up against without being able to clearly show prior art. Only after that might I consider saying "webflow-style workflow" or something along those lines. It's sad, but you have to assume their lawyers will use every legal tool at their disposal to protect their client's bottom line whether its reasonable or not.
Point taken, we'd do better without the headache for now until further legal counseling. Changing the tagline now. Thank you all for the suggestion!
Best of luck! Great project.
I'm not a lawyer, but here's some high-level general suggestions from a specialist which could be helpful:
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.
Looks great. Any plan to make it work in a browser instead of having to install an Electron app?
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.
that just serves locally and you hit it with your browser
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.
Depending on which APIs you use, that could work. I tried it with Logseq because I really want to have my knowledge base on a VPS which I can access from anywhere via browser, and because of the APIs they use the browser will only allow it if the remote is localhost. You could maybe trick it with a hosts file hack or something, but that would break a lot of (other) stuff that expect localhost to resolve to 127.0.0.1.
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...
I'm curious about the chrome extension issues as I'm wondering about creating a project using it, with all the problems it brings with marketing.
What does `UX from jumping around to multiple pages` mean?
I agree that this would be a great addition.
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.
"My suggestion is keep offering it as OSS, but offer a hosted version as well."
I would think, that is the obvious monetization plan?
Yes, that is the most obvious plan. I want to find a community-friendly way to do this.
I know Supabase has a similar and successful monetization plan but I know some take issue with the way they offer their hosting.
There is nothing to take issue, open source projects are allowed to monetize the same way as closed source projects. Your first thought needs to be how to create a sustainable project otherwise you won't have a community.
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?
Since you mentioned cloning, feel free to hack on this https://github.com/beenotung/web-clone
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?
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.
I made a WYSIWYG tool to edit HTML file without polluting the code. It works well for landing pages but it doesn't work well with js-generated webapp.
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 :)
Nice, thank you!
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.
A bit off-topic, but this landing page "steals" my cursor, presumably for that special hero effect, which makes it dizzingly laggy and unresponsive.
Though stealing the cursor is okay, having 2 cursors in the page without my own cursor was confusing.Also the lag is very apparent.
This is a common complaint, I'll be sure to take this off
Same 4 me, every web dev now owns a 3k MacBook and it shows
Similar and also very neat: https://luna-park.app/
Is it open source?
How cool! There's a lot to learn from here. Thank you for sharing.
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.
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.
Ya, that seems about right for my project as well. Although mine won't be OSS so I'm more concerned with finding good ppl with Svelte skills vs React skills. I may need to bite the bullet once I'm closer to hiring. Thanks.
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!
They’re more than just a little bit expensive when it comes to small builds and trying things out. It’s impractical to pick up as a part time hack.
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.
Good catch, thank you. Changed it to schedule a demo.
How's it different from something like reka.js or builder.io?
To my understanding, Reka is more of a core no-code builder library while we're an implementation of it. Now I'm considering if we should use Reka to build out the rest of the editor.
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 amazing, thank you for building!!!
Thank you for checking it out!
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.
I would pay top dollars for this if you can integrate it with Microsoft PCF along with their build tools.
Any plans to add Vue support?
super cool! very very similar to Utopia: https://utopia.app/ maybe you can work together on this :)
Love your landing page! What did you build the animation at the top of your page with?
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"
Damn this looks like even I could make decent web applications in it. Pretty cool.
This is THE tool I'm looking for years!
Pretty cool! I recently came across WeWeb (weweb.io) which also allows for exporting code, and is quite feature rich in its visual editor
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.
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".
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.
This argument is akin to saying we shouldn’t have hammers because tradespeople will move on to use nail guns once they have experience.
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.
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.
Sorry for the confusion, this is an Electron app. I just didn't ship an executable with it at the moment.
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.
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.
I'm in a rather odd demographic: I've got about a decade of experience as a developer (as a paid full-time dev working on some FOSS projects) but recently switched careers to design. The design and dev mindsets are definitely different. I obviously prefer tweaking things in code, but designing a layout is fundamentally a visual communication task, so working visually is preferable. I've just started working on a new portfolio site and was wondering if I could skip the Figma/whatever wireframe phase and just use a local WYSIWYG tool for a static page.
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.
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. :-)
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.
This 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.
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.