onlook

at will let you go beyond ideation to actual implementation on real codebases. Some known bugs: – Sometimes generations don't "apply" after they're loaded: Kiet is working on a fix for this, but try clicking on the blank-template and re-prompting your change. - It can take a long time to load the AI chat: We're working on making this faster (or at least a little more entertaining). - Sometimes nothing shows up in the chat: Try going back to the homepage and re-prompting. This is something we want to make smoother. – Sometimes styles don't apply: Let us know! We're trying to catch the edge cases. Thank you all for your help and patience as we work through this early preview. Please join us on our Discord [https://discord.gg/ZZzadNQtns] and report any bugs or issues on GitHub repo: https://github.com/onlook-dev/onlook

gs from the whole migration: 1. While most of the React UI code can be reused, mapping from Electron’s SPA experience to a Next.js app with routes is non-trivial on the state management side. 2. We were storing most of the data locally as large JSON objects. Moving that to a remote database required major refactoring into tables and more loading states. We didn’t have to think as hard about querying and load time before. 3. Iframes in the browser enforce many more restrictions than Electron webview. Working around this required us to inject code directly into the user project in order to do cross-iframe communication. 4. Keeping API keys secure is much easier on a web application than an Electron app. In Electron, every key we leave on the client can be statically accessed. Hence, we had to proxy any SDK we used that required an API key into a server call. In the web app, we can just keep the keys on the server. 5. Pushing a release bundle in Electron can take 1+ hours. And some users may never update. If we had a bug in the autoupdater itself, certain users could be “stranded” in an old version forever, and we’d have to email them to update. Though this is still better than mobile apps that go through an app store, it’s still very poor DX. How does Onlook for web work? We start by connecting to a remote “sandbox” [4]. The visual editing component happens through an iframe. We map the HTML element in the iframe to the location in code. Then, when an edit is made, we simulate the change on the iframe and edit the code at the same time. This way, visual changes always feel instant. While we’re still ironing out the experience, you can already: - Select elements and prompt changes - Update TailwindCSS classes via the styling UI - Draw in new divs and elements - Preview on multiple screen sizes - Edit your code through an in-browser IDE We want to make it trivial for anyone to create, style, and edit codebases. We’re still porting over functionalities from the desktop app — layers, fonts, hosting, git, etc. Once that is done, we plan on adding support for back-end functionalities such as auth, database, and API calls. Special thank you to the 70+ contributors who have helped create the Onlook experience! I think there’s still a lot to be solved for in the design and dev workflow, and I think the tech is almost there. You can clone the project and run it from our repo (linked to this post) or try it out at https://beta.onlook.com where we’re letting people try it out for free. I’d love to hear what you think and where we should take it next :) [1] https://news.ycombinator.com/item?id=41390449 [2] https://news.ycombinator.com/item?id=40904862 [3] https://docs.onlook.com/docs/developer/electron-to-web-migra... [4] Currently, the sandbox is through CodeSandbox, but we plan to add support for connecting to a locally running server as well

be sure they are selecting the right colors in the right scopes. That's something we still have yet to tackle, but have an open issue for: https://github.com/onlook-dev/onlook/issues/49

the DOM like a Chrome Devtool, and all these changes are injected into the page through a CSS stylesheet or DOM manipulation. The changes are non-persistent until written to code. Write to code - To translate the changes to code, we inject an attribute into the DOM elements at build-time that points back to the code like a source map. The attribute gives us the location of the code block, and the component scope [3]. We then find the code, parse it into an AST, inject the styles, and write it back. Framework support - This technique is framework agnostic as we can swap in a different compiler for another framework [4]. It can work for any codebase as we’re just using open standards that don’t require any custom code. The code generated is written directly into your codebase, locally, so you can always take the output without being locked-in to the tool. Actions - All the changes made are stored as actions. This allows them to be serialized, stored, and reproduced. We did it this way so eventually, we can introduce online collaboration or let an agent generate actions. To do this, we’d just need to serve the locally running page and resolve incoming actions. What’s next? It’s still a bit bare-bones but the support and suggestions from the HN and open-source communities have helped us a lot with our direction. Now that we’ve built the core engine, we can start doing some cooler visual builder features, fulfilling the “Webflow” part of our mission such as [5]: • Detecting CSS variables in the page and letting you use them as “design tokens” in the UI. • Duplicating a page and A/B testing designs before committing to code. • Creating new components directly in the canvas. • Creating a front-end project from scratch using Onlook. Some things we’re considering, but aren’t sure about yet: • Offer hosting directly from the app. • Collaboration such as real-time edits, comments, and share page as a prototype. I’d love to hear your thoughts/feedback. This project continues to be a blast to work on and the community response has been awesome. Thank you to everyone who has tried out and contributed to the repo :) _________ [1] https://news.ycombinator.com/item?id=40904862 [2] https://github.com/onlook-dev/onlook/wiki/Architecture [3] The attribute looks something like this: data-onlook-id="eJxNjUEKwzAMBP+ic6gOKT3k2i+kDzC2aEwcKVgyDQT/vU5pS067sMvMDl6WVZjYYIC7y2GMlgg6IA6je8LAJaUOVmdTO+BDKSvOkWwSfEme1+Q8oXASmVGthCgYaBFFps3wT1csEX3jX0y3hldz2T6C/VAd4SWVhWG4dpAiUyt9/R7Pc/+b+1ut9Q33rUM5" 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}}} [4] We’re only supporting a few versions of React at the moment for early focus: https://github.com/onlook-dev/onlook/tree/main/demos [5] https://github.com/onlook-dev/onlook/wiki/Roadmap