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?

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

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.

This is a common complaint, I'll be sure to take this off

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

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

Great recommendations. Thank you I will consider these!

Not atm, I have a barely working version for Sveltekit but I need to clean it up before releasing. I will post an update with the GitHub.