There are a lot of Figma plugins to do that. Anima or Builder.io (not builder.ai) is one I've used before. I'd like to add a simple plugin for us to use if we ever have the capacity.
300 karma · joined August 24, 2018
It's actually attempting to scroll the inner web page in Preview mode. Perhaps this is not a great/obvious form factor since we've had others be confused about this. I think showing a scroll bar in design mode or animate when overscrolled in Preview mode to show it's attempting to scroll could help.
> Is there pricing information anywhere? I did not see any.
There's no rate limit or pricing for the web beta at the moment but for the desktop app the pricing is shown in-app. We have a WIP pricing page that you can find in code but needs some work before we release it.
> I can't seem to actually see any element's code; all I have is a basic layout.tsx file
This seems wrong, I will take a look. The code should be highlighted in the editor when you click on an element. It's possible that it put all the code in layout.tsx but there should be a page.tsx in there.
We still provide a guest login for dev mode in the database seed script to get around that.
> I personally loathe this trend of making us login after giving us a prompt box.
I do too, and am very aware of how HN/other engineers feel on this topic. It's mostly a way to get around abuse and access issues. We have a pattern moving forward for guest accounts, but couldn't prioritize it in time for this launch.
I think not needing to sign in is a good way to kick the tire which helps growth as well. So point taken to prioritize this higher. Thank you :)
n hindsight, it still would not have helped with the other desktop app based issue like friction of setting up so I think we made the right call.
A large percentage of the bundle comes with shipping Bun as a fallback runtime for users who didn't have node installed. This could've been done better as well but it would still be 300MB+ bundle size.
There is terminal access on the right of the bottom bar. It just has 1 CLI connection right now, along with the long runner server but you can run commands through there or through the AI.
Just merged a PR for that should be live in a few mins https://github.com/onlook-dev/onlook/pull/1963
I know it's a bad answer, but I don't want to keep promising a feature that doesn't seem likely at this point. Will update the issue to be a won't fix for the time being.
Onlook has less abstraction between code and the visual editor. It works with your existing React codebase with no migration. Everything is written into code in real-time so you wouldn't import or export the code from Onlook. You can use it anytime and stop anytime like an IDE.
Does this make sense? I'd love to hear Oleg's thoughts on this as well :)
Thought theoretically, you could write a parser to add the necessary information to the HTML tags at "build time"
We had to focus on React for various reasons [2] but I'd really like to support Svelte again
[1] https://github.com/onlook-dev/chrome-extension/tree/main/plu...
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.
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
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:...'