Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: An open-source, local-first Webflow for your own app

github.com

Post reply on HN
Print view View original

21–30 of 53 posts

Re: Show HN: An open-source, local-first Webflow for your own app

#21

Post by danielvaughn »

hoakiet98 wrote: post #12
danielvaughn wrote: post #8

I love the idea. I'm working on something in the same general category, but a very different approach and I love seeing how others are tackling this problem. Over time I suspect we'll see more tools that attempt to bridge design tools with dev tools - every time I crack open Chrome's inspector, all I can think about is how amazing it could be if it was intended to be used by design teams.

Feel free to share your tool if it's open source. I'd love to see how you approach this problem. Happy to share more technical details if it helps your product. Chrome inspector does so much more like clip support and media queries that I didn't even know about. It also writes directly to inline styles so propagating those changes as code is definitely possible. I was thinking if there's a way we can leverage the gre…

The inspector does write to inline styles, though if you try to listen for those changes with a mutation observer, it won't fire. I think they disable event propagation for inspector-driven DOM changes, which limits your ability to make use of it at the application layer. I've briefly considered just forking chromium, but I don't know C++ and not sure it makes sense to invest in that level of effort.

I don't want to step on your toes by linking my own project, but essentially my idea is: the editor creates an object representation of the html/css which can then be transpiled into any framework the user wants (so long as there is an existing transpiler for it). Then the output could be hosted on npm or some other remote repository for the application repo to install.

Re: Show HN: An open-source, local-first Webflow for your own app

#22

Post by hoakiet98 »

mdaniel wrote: post #20

> And decodes to this: {"component":"Dashboard","endTag":{"end":{"column":10,"line":620},"start":{"column":5,"line":620}},"path":"/Users/kietho/workplace/onlook/studio/demos/next/components/dashboard.tsx","startTag":{"end":{"column":67,"line":69},"start":{"column":5,"line":69}}} Up to you, but you'll save a ton of space in that b64, and arguably some user privacy, by trying to use workspace relative paths. I also tho…

> you'll save a ton of space in that b64, and arguably some user privacy, by trying to use workspace relative paths

That was a pattern we initially went with but it adds some complexity:

The React compiler gives absolute paths, which we can adjust to relative paths by passing in the current process' running location into our plugin. This makes the plugin API more complex. We'd also have to track the project's relative path at runtime and concat it back.

We decided the extra characters were worth it to eliminate the extra complexity. I do realize that the character number scales with the path + complexity of the project.

> JS had access to gzip (or zlib)

I haven't looked at this but will give it a try. We're doing some compression here but there's also a performance hit for compressing too much at build time.

I do think we can save space by using a different format than JSON. Even just a raw string. Something like: 'path/to/file:startTag:start:line:col:...'

Re: Show HN: An open-source, local-first Webflow for your own app

#23

Post by hoakiet98 »

danielvaughn wrote: post #21
hoakiet98 wrote: post #12

Earlier quoted context omitted.

Feel free to share your tool if it's open source. I'd love to see how you approach this problem. Happy to share more technical details if it helps your product. Chrome inspector does so much more like clip support and media queries that I didn't even know about. It also writes directly to inline styles so propagating those changes as code is definitely possible. I was thinking if there's a way we can leverage the gre…

The inspector does write to inline styles, though if you try to listen for those changes with a mutation observer, it won't fire. I think they disable event propagation for inspector-driven DOM changes, which limits your ability to make use of it at the application layer. I've briefly considered just forking chromium, but I don't know C++ and not sure it makes sense to invest in that level of effort. I don't want to…

> I don't want to step on your toes by linking my own project

Not at all, it's in good spirit! Happy to talk through any technical details from my side :)

> though if you try to listen for those changes with a mutation observer, it won't fire

It doesn't have to fire an immediate mutation imo. When you click on an element to edit, you could inject a data-attribute into it (not sure if the Chrome Devtool let you do this but an extension might). At write-time, you can query the elements that were marked, get the delta and write it to code.

You might've thought of this longer than I have so I think that might be a naive solution.

> can then be transpiled into any framework the user wants

You might be interested in Mitosis https://github.com/BuilderIO/mitosis

Re: Show HN: An open-source, local-first Webflow for your own app

#24

Post by danielvaughn »

hoakiet98 wrote: post #23
danielvaughn wrote: post #21

Earlier quoted context omitted.

The inspector does write to inline styles, though if you try to listen for those changes with a mutation observer, it won't fire. I think they disable event propagation for inspector-driven DOM changes, which limits your ability to make use of it at the application layer. I've briefly considered just forking chromium, but I don't know C++ and not sure it makes sense to invest in that level of effort. I don't want to…

> I don't want to step on your toes by linking my own project Not at all, it's in good spirit! Happy to talk through any technical details from my side :) > though if you try to listen for those changes with a mutation observer, it won't fire It doesn't have to fire an immediate mutation imo. When you click on an element to edit, you could inject a data-attribute into it (not sure if the Chrome Devtool let you do thi…

I hadn't heard of Mitosis, that's super interesting. Thanks for sharing!

Re: Show HN: An open-source, local-first Webflow for your own app

#25

Post by hoakiet98 »

danielvaughn wrote: post #24
hoakiet98 wrote: post #23

Earlier quoted context omitted.

> I don't want to step on your toes by linking my own project Not at all, it's in good spirit! Happy to talk through any technical details from my side :) > though if you try to listen for those changes with a mutation observer, it won't fire It doesn't have to fire an immediate mutation imo. When you click on an element to edit, you could inject a data-attribute into it (not sure if the Chrome Devtool let you do thi…

I hadn't heard of Mitosis, that's super interesting. Thanks for sharing!

np!

Re: Show HN: An open-source, local-first Webflow for your own app

#26

Post by hoakiet98 »

mkreis wrote: post #9
danielvaughn wrote: post #7

Earlier quoted context omitted.

The docs say it's framework-agnostic. I assume then that the editor would only be used for editing css, not html, but I'm sure the founder can correct me if I'm wrong. I'm also curious how they determine where in source the code needs to change, because you could have (a) external stylesheets, (b) a stylesheet in the html head, (c) tailwind classes, (d) some css-in-js variant, or even (e) direct style application of…

yes, indeed, that's is also what I am curious about

Hey mkreis, I answered this here: https://news.ycombinator.com/item?id=41390449#41390695

Re: Show HN: An open-source, local-first Webflow for your own app

#27

Post by aswerty »

Onlook sounds interesting as someone who had lined up using https://webflow.com/devlink as a solution for allowing our web dev to continue doing static content development in our new web app.

If I were to ask: why use Onlook over Devlink what would your answer be?

Re: Show HN: An open-source, local-first Webflow for your own app

#30

Post by hoakiet98 »

aswerty wrote: post #27

Onlook sounds interesting as someone who had lined up using https://webflow.com/devlink as a solution for allowing our web dev to continue doing static content development in our new web app. If I were to ask: why use Onlook over Devlink what would your answer be?

I think DevLink is great and it's a step in the right direction.

However, you're still locking into a WebFlow project. You can export a DevLink component out and then migrate it back in. You also have to instrument the weblink component.

With Onlook, there's no new environment. Your code is just running in localhost in your project. No import export and no extra code just to develop a new component.

Post reply on HN