Live data from Hacker News

Show HN: Open-sourced Webflow for your own app

github.com

41–50 of 101 posts

Re: Show HN: Open-sourced Webflow for your own app

#41

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…

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

Re: Show HN: Open-sourced Webflow for your own app

#42

Earlier quoted context omitted.

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.

Re: Show HN: Open-sourced Webflow for your own app

#43
post #26

Earlier quoted context omitted.

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

Re: Show HN: Open-sourced Webflow for your own app

#44

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

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…

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?

Re: Show HN: Open-sourced Webflow for your own app

#45
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.

Re: Show HN: Open-sourced Webflow for your own app

#47

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…

> 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 br…

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.

Re: Show HN: Open-sourced Webflow for your own app

#48

Earlier quoted context omitted.

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…

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.

Re: Show HN: Open-sourced Webflow for your own app

#50

Earlier quoted context omitted.

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…

> I only saw install instructions for NPM so maybe it just needs built executables 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 supporti…

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.

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

Post reply on HN