Comment by freedomben | Hacker News Reader

Comment by freedomben | Hacker News Reader

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?

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

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

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

https://github.com/beenotung/auto-cms

Very cool!

Reply on news.ycombinator.com