[HN Gopher] Show HN: An open-source, local-first Webflow for you...
___________________________________________________________________
Show HN: An open-source, local-first Webflow for your own app
Hey HN, I'm Kiet, and I'm one of the co-founders of Onlook - an
open-sourced desktop app that lets you visually edit your locally
running React app, then write your changes back to code in real
time. I posted the repo a few months ago [1] when it was just 2
weeks old. Since then, we've made some big changes/improvements. I
wanted to share some of the updates we've made and add more
technical details. Here are the three big ones: * Inserting new
elements - Draw elements in the live page like a design tool and
write them back to code. * Component detection - Detect when an
element is a re-used component and find its usages. * DOM tree
representation - A layers panel similar to the Chrome devtool or
Figma. Technical details [2]: Visual editing - Onlook is
technically a browser that points to your localhost running the
app. It can manipulate 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/vU5pS067sMvMDl6WVZjYY
IC7y2GMlgg6IA6je8LAJaUOVmdTO+BDKSvOkWwSfEme1+Q8oXASmVGthCgYaBFFps3w
T1csEX3jX0y3hldz2T6C/VAd4SWVhWG4dpAiUyt9/R7Pc/+b+1ut9Q33rUM5"
And decodes to this: {"component":"Dashboard","endT
ag":{"end":{"column":10,"line":620},"start":{"column":5,"line":620}
},"path":"/Users/kietho/workplace/onlook/studio/demos/next/componen
ts/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
Author : hoakiet98
Score : 154 points
Date : 2024-08-29 13:11 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| D_R_Farrell wrote:
| Hey HN! I'm Daniel, the designer on Onlook.
|
| Kiet and I started working together in January to try to solve
| the design / dev handoff, and we think that this is a great first
| step to getting more people into code. People have mentioned that
| Onlook is a great complement to building frontends with Cursor,
| so if you're just learning to code with Cursor, try running your
| projects locally with Onlook.
|
| One thing I'd like to do is open-source our design system and
| make it easier for designers to contribute. If you have any
| suggestions or examples of projects that have done this well, let
| me know!
|
| I'm hopeful that with the help of so many great contributors, we
| can make an editor experience that doesn't compromise on the
| design / code experience!
| robzhu wrote:
| This is really cool! Definitely going to check it out
| hoakiet98 wrote:
| Thanks for checking it out robzhu. Let me know of any
| feedback/issues :)
| mkreis wrote:
| Love it. Just the other day I have been looking for something
| like this. What preconditions must be met to use this with an
| existing app? What tech stack is supported (e.g. only Typescript
| and React and ...)?
| hoakiet98 wrote:
| We work best for React (js/ts) and TailwindCSS. In-code UI libs
| like ShadCN also customizes better. Thanks for checking it out
| :)
| danielvaughn wrote:
| 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 dom elements in your javascript.
| mkreis wrote:
| yes, indeed, that's is also what I am curious about
| hoakiet98 wrote:
| Hey mkreis, I answered this here:
| https://news.ycombinator.com/item?id=41390449#41390695
| hoakiet98 wrote:
| > I assume then that the editor would only be used for
| editing css, not html
|
| It does edit html. Inserting html elements in this case.
|
| > I'm also curious how they determine where in source the
| code needs to change
|
| Right now we're editing inline-tailwind because it's the
| easiest option. It only edits the existing tailwind styles so
| there could be some interaction with existing styles that
| have higher-priotity.
|
| The plan later is to have users configure how they want their
| styles written. We have full code access to be able to edit
| css stylesheets or inject our own.
| danielvaughn wrote:
| 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.
| hoakiet98 wrote:
| 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 great work the Chrome devtool have already put in.
| danielvaughn wrote:
| 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.
| hoakiet98 wrote:
| > 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
| danielvaughn wrote:
| I hadn't heard of Mitosis, that's super interesting.
| Thanks for sharing!
| hoakiet98 wrote:
| np!
| chrisaeberli wrote:
| exciting stuff
| hoakiet98 wrote:
| thank you for checking it out :)
| au-arms wrote:
| so cool - always feel a little pain when i have to suggest
| webflow nowadays. Glad to see other options cropping up - love
| the vision :)
| hoakiet98 wrote:
| Thanks au-arms! Webflow is definitely the best option out
| there. But for devs, we're hoping to address the lock-in and
| get back some of the flexibility of owning the code
| tmolovinsky wrote:
| Exciting update, Kiet and Daniel! Even as a non-technical person,
| I can see how Onlook could really bridge the gap between design
| and development. The ability to visually edit a React app and see
| those changes in the code in real-time is a game-changer. I'm
| looking forward to seeing how you bring those A/B testing and
| component creation features to life. Keep up the great work!
| hoakiet98 wrote:
| Thanks tmolovinsky, we're already actively working on component
| creation so hoping to introduce that soon :)
| kartik-raj7 wrote:
| Happy to contribute to this amazing product...
| hoakiet98 wrote:
| Thanks for the continued support and the contributions so far,
| kartik-raj7!
| mdaniel wrote:
| > And decodes to this: {"component":"Dashboard"
| ,"endTag":{"end":{"column":10,"line":620},"start":{"column":5,"li
| ne":620}},"path":"/Users/kietho/workplace/onlook/studio/demos/nex
| t/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 thought JS had access to gzip (or zlib) which would
| similarly help, doubly so if the gzip dictionary were
| externalized (e.g. <meta content="sOmEgZiPsTuFfHeRe">) since it
| seems the object keys repeat a lot
| hoakiet98 wrote:
| > 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:...'
| aswerty wrote:
| 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?
| hoakiet98 wrote:
| 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.
| Fire-Dragon-DoL wrote:
| Ouch, the thread is unreadable on the phone
| hoakiet98 wrote:
| Reader mode could help if you're on iPhone
| johnsutor wrote:
| Would love to have something like this for Svelte.
| hoakiet98 wrote:
| The POC for this was actually done in Svelte so it can be done
| again in the future [1].
|
| 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...
|
| [2] https://news.ycombinator.com/item?id=40904862
| cchance wrote:
| Would be awesome! Would love to see something like this in
| svelte done well.
| edrenova wrote:
| cool to see this launch, actually came across this a few weeks
| ago and tried it out, really nice for local dev :)
| hoakiet98 wrote:
| Thanks for trying it out edrenova!
| prageeths wrote:
| Very cool. We've had some limitations with Webflow, especially
| setting '.well-known' files, and it has been ignored by WF even
| though the community keeps asking for it. Hope your solution can
| solve these issues easily.
| burpee wrote:
| Great idea and good execution. Any idea on monetization?
|
| The video needs work; the main risk perceived will be to have bad
| design applied and not be caught. The video is basically a demo
| of that scenario.
| D_R_Farrell wrote:
| Thanks!
|
| For monetization we'd like to keep the editor free for people
| to use and may monetize through add-on services like hosting.
| The way I like to think about it is that we may monetize on
| convenience points but keep things open-source so if you wanted
| to do things custom, then you can if you'd like.
|
| On the video - thanks for the note there! We can certainly show
| it to do something more detailed as well than just a background
| color change. The good thing is that any designs done with
| Onlook still go through the usual code review process for any
| project, so hopefully people won't accept non-compliant design
| changes. In the event that they do, it'll be easier to fix
| things with Onlook.
|
| On the lines of keeping things compliant with design systems,
| I'm excited about our ability to surface design tokens from a
| codebase, so users can always 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
| gbourant wrote:
| Can it support raw HTML + CSS (or tailwind) ?
| hoakiet98 wrote:
| Without a framework? Unfortunately, no since there's a
| necessary compile step to instrument the code.
|
| Thought theoretically, you could write a parser to add the
| necessary information to the HTML tags at "build time"
| bbourn wrote:
| This is the kind of software that makes me excited, the future is
| going to be so much less wasted resources and so much more time
| spent building!
| D_R_Farrell wrote:
| You know it! Haha thanks for the support!
| mxstbr wrote:
| Love seeing more innovation in this space! I know Oleg (former
| Webflow eng) has been working on https://webstudio.is for a
| while; also open-source and visual editing for React apps. How
| does Onlook compare?
| hoakiet98 wrote:
| Webstudio is very good! I didn't know it produces React.
|
| 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 :)
___________________________________________________________________
(page generated 2024-08-29 23:00 UTC)