[HN Gopher] Show HN: Open-sourced Webflow for your own app
___________________________________________________________________
Show HN: Open-sourced Webflow for your own app
Hi HN, I'm Kiet, one of the creators of Onlook studio. I made this
app that allows you to visually edit your locally running React app
and write the code back to it in real-time. The purpose is to allow
you to develop UI while fully owning your code the whole time.
There are other visual builders out there but they either require
you to upload your code to the cloud or some lengthy setup process.
Onlook runs locally, deterministically, and only requires adding a
plugin for the compile step (2 lines of config change). Technical
details: This is technically a web browser that can point to your
localhost, which injects some CSS into the page that allows you to
select, drag, and drop DOM elements, then track and translate those
changes back into React code. Theoretically, you could do this with
any compiled framework but I wanted a reasonable scope for the
launch (the first version was actually in Svelte). Some
interesting challenges: 1. There is a React parser that is used to
parse, insert the style, and serialize it back to code 2. There is
a React pre-processor that traces the DOM elements to the
corresponding code 3. There's also CSS parsing, injection, and
converting to Tailwind 4. This is also an Electron app so there's a
browser within a browser within a node app which makes message
passing... interesting What's next? We've already built a proof-
of-concept for inspecting and selecting layers, dragging to
reorder, and inserting new DOM elements that I'm working on porting
over from our private codebase. We're also exploring opening more
tabs in new frames in order to A/B test the changes before
committing to code. There's a long tail of exciting features we can
do but I want to put this out there first and see what others would
need. Let me know what you think/feedback. It's been a blast
working on this so far and I think it's just neat :)
Author : hoakiet98
Score : 260 points
Date : 2024-07-08 12:36 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ramesh31 wrote:
| The main problem with these kind of tools is that they sit in a
| "dead zone" of being too in depth for non-technicals, yet too
| limiting and inefficient for engineers to bother with, as they
| end up injecting a huge bundle on the page just to render a form.
| How are you solving for that?
| toddmorey wrote:
| This... isn't that. Changes made in the visual editor are
| translated into code and submitted to your project as a GH pull
| request for review. So from a project / software perspective,
| it looks and works like a FE engineer committed a code change.
| hoakiet98 wrote:
| > 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.
| hoakiet98 wrote:
| 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.
| DrewADesign wrote:
| While that might be true at the moment, this is a (well
| designed) electron instance _(edit: exists? I only saw install
| instructions for NPM so maybe it just needs built executables?
| it says it uses electron)_ away from being a modern replacement
| for WYSIWYG editors like Dreamweaver. I could see an easy
| integration to push your page up to a CDN or GH Pages instance.
| Even without, there are tons of places for moderately technical
| people to host static websites, and "upload the code and
| pictures to a server in this folder" is within many more
| people's technical grasp now than it was 20 years ago. Most
| people don't need all of the scaffolding most modern dynamic
| websites have. Online SAAS WYSIWYG web authoring tools-- wix,
| squarespace, Wordpress, et al-- have been the only practical
| option for people without front-end dev skills; beyond that,
| you're in SSG land which requires a big jump in knowledge for
| very little gain in utility until you really start getting some
| dev knowledge, and most people don't want or need that
| knowledge. Being able to stand up a site and tweak the code
| here and there to do something a little different is a great
| spot to sit in. Hell it's what got me started on web stuff with
| my geocities site nearly 30 years ago.
|
| I think this is a great example of why we need more product
| people involved with FOSS. Having worked in dev for quite some
| time before I got into design, I've experienced the blind spots
| inherent to having a purely technical focus. From the dev
| perspective, user needs often seem straightforward or even
| intuitive, but that's heavily skewed by a completely different
| approach to using and reasoning about software than end users
| have. Developers are often pessimistic about users that
| seemingly always fail to grasp something they consider trivial,
| but developers rarely have to confront the actual complexity of
| other people's jobs. Lots of people are smart and can solve
| problems, even if they don't have a formidable mental model of
| software development. Tweaking basic HTML/CSS generated by
| something else is well within their problem-solving capability
| and doesn't require much technical know-how.
| hoakiet98 wrote:
| > I only saw install instructions for NPM so maybe it just
| needs built executables
|
| Sorry for the confusion, this is an Electron app. I just
| didn't ship an executable with it at the moment.
|
| > I could see an easy integration to push your page up to a
| CDN or GH Pages instance.
|
| That is certainly in the cards. Though, in my opinion, it
| becomes more useful to edit complex web application since
| there are many tools supporting static sites but not many for
| production web apps.
|
| > user needs often seem straightforward or even intuitive,
| but that's heavily skewed by a completely different approach
| to using and reasoning about software than end users have
|
| I am guilty of this. My long-long term hope is to be able to
| collaborate better with my product folks where they are able
| to enact their own intuition in the product instead of having
| to go through me for every change needed.
|
| While this is easy for a marketing page, it's much more
| difficult to do in a complex application context.
| DrewADesign wrote:
| I'm in a rather odd demographic: I've got about a decade of
| experience as a developer (as a paid full-time dev working
| on some FOSS projects) but recently switched careers to
| design. The design and dev mindsets are definitely
| different. I obviously prefer tweaking things in code, but
| designing a layout is fundamentally a visual communication
| task, so working visually is preferable. I've just started
| working on a new portfolio site and was wondering if I
| could skip the Figma/whatever wireframe phase and just use
| a local WYSIWYG tool for a static page.
|
| > there are many tools supporting static sites but not many
| for production web apps.
|
| The funny thing is that the only true WYSIWYG tool I can
| find that isn't part of a paid SaaS ecosystem or complete
| inflexible garbage is Adobe Dreamweaver, which has been
| dying a slow death for decades. It has a few positive
| traits-- it makes responsive designs, works with bootstrap
| 4 and a few CSS libraries which make relatively clean code
| rather than spinning up the inscrutable spaghetti monsters
| it did in the aughts, and has a really solid built-in code
| editor (which I assume is Brackets on the back end) but
| there are bits of primary functionality that have just been
| broken for years and clearly not on the docket for an
| update. I looked at it for a few hours last week and
| decided it probably wasn't long for this world.
|
| Of course you can't spit without hitting an SSG with hot
| reloading, and in-editor previews are de rigueur, but none
| of those offer a visual-first workflow for _page design,_
| which is what a professional designer really needs. You can
| have document-style WYSIWYG editing a la TinyMCE, which is
| fine for a blog post, but if you want to put together the
| structure of a page from the ground up, you 're still
| context switching between an editor and a browser window
| which is an ineffective way for designers to work, even if
| they have the knowhow.
|
| > While this is easy for a marketing page, it's much more
| difficult to do in a complex application context.
|
| Sure, and this would have saved me some time in the various
| complex web apps I've made. But for the technically simpler
| use cases like my portfolio page, unless you're going to
| use Squarespace, Wix, Artstation, Webflow, etc etc etc and
| buy into their ecosystem, there really is no option for
| people that need reasonable control over the site's design
| without a code-first approach. Aside from Dreamweaver, I
| think the only one I could actually locate and install was
| part of Sea Monkey, and it seems to be an... uh... let's
| say under-loved part of an already under-loved suite of
| tools. And while my portfolio or a marketing landing page
| are technically simpler, the quality of the layout is often
| significantly more important than it is in a web app. Web
| apps usually convey factual information, figures, maybe
| provide tools for modifying things, etc. In a marketing
| page or a portfolio, what you're trying to communicate--
| vibe, flow, visual movement, and other intangibles-- takes
| much more nuance.
|
| _(In fact, when developers see a software interface they
| think was 'ruined by a designer', it was usually ruined by
| a project manager or a developer trying to make something
| 'look designed' by mimicking some simple, elegant design
| they saw that was totally inappropriate for the
| application. Then they call someone like me. :-)_
| nobleach wrote:
| I consider that zone to be a new "sweet spot". A new generation
| of "web devs" can circle around a tool like this. Our current
| in-house tool is a drag and drop editor that allows slices of
| content to be stacked. Each of these slices has preprogrammed
| selectable options for things like colors, sizes, body copy,
| headlines, etc. We consider this far too limiting. Now I will
| agree that my use of Webflow had me beating my fist against my
| desk. I could do the same thing in straight HTML in 15 minutes,
| that took me an hour or so in Webflow. Much of that was the
| learning curve; figuring out "the Webflow way". I see a future
| where we have tons of people who are good at these low-code/no-
| code tools. Sure I can run circles around them by being able to
| write all the code by hand. But for most things they'll be
| "good enough".
| ramesh31 wrote:
| >I consider that zone to be a new "sweet spot". A new
| generation of "web devs" can circle around a tool like this.
|
| The problem there (and this is from experience building and
| supporting such a tool for non-technical users) is that
| people learn. Anyone who spends enough time in one of these
| tools will quickly pick up the fundamentals enough to become
| frustrated with the limitations. Or their engineering team
| will see the inneficient code being created and take it upon
| themselves to just implement these things quickly and simply.
| So you can start leaking the abstraction and allowing custom
| CSS/HTML, but then you very quickly arrive at a place that is
| useless for both teams.
| anakaine wrote:
| This argument is akin to saying we shouldn't have hammers
| because tradespeople will move on to use nail guns once
| they have experience.
|
| There is a place for both. You don't need to spend much
| time on here, reddit, or many other forums to find people
| complaining about the lack of decent middle ground tooling
| to get started with front end dev.
| minajevs wrote:
| A bit off-topic, but this landing page "steals" my cursor,
| presumably for that special hero effect, which makes it dizzingly
| laggy and unresponsive.
| biosboiii wrote:
| Same 4 me, every web dev now owns a 3k MacBook and it shows
| hoakiet98 wrote:
| This is a common complaint, I'll be sure to take this off
| nalinidash wrote:
| Though stealing the cursor is okay, having 2 cursors in the
| page without my own cursor was confusing.Also the lag is very
| apparent.
| patrickaljord wrote:
| Looks great. Any plan to make it work in a browser instead of
| having to install an Electron app?
| hoakiet98 wrote:
| 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...
| meiraleal wrote:
| I'm curious about the chrome extension issues as I'm
| wondering about creating a project using it, with all the
| problems it brings with marketing.
|
| What does `UX from jumping around to multiple pages` mean?
| freedomben wrote:
| Having it edit local files might be a difficulty of having it
| work in a browser instead of electron app. That said though,
| Electron apps I've worked with in the past usually have a "dev"
| mode already that just serves locally and you hit it with your
| browser (i.e npm run dev), and that browser allows using the
| APIs normally not allowed so long as it's being served from
| localhost. Might be a good solution.
| hoakiet98 wrote:
| > that just serves locally and you hit it with your browser
|
| This is an interesting take. My interpretation: You can host
| this on a server, then expose a port remotely which will have
| all the access of the electron app, making it a pseudo SAAS?
|
| I will need to test this out but this has some cool
| implications. The other worry is multiple client support but
| you can just provision a personal instance.
| freedomben wrote:
| Depending on which APIs you use, that could work. I tried
| it with Logseq because I really want to have my knowledge
| base on a VPS which I can access from anywhere via browser,
| and because of the APIs they use the browser will only
| allow it if the remote is localhost. You could maybe trick
| it with a hosts file hack or something, but that would
| break a lot of (other) stuff that expect localhost to
| resolve to 127.0.0.1.
| yakito wrote:
| I agree that this would be a great addition.
| pavlov wrote:
| Watch out for trademarks. Your slogan "The power of WebFlow for
| your React app" is going to attract attention from Webflow's
| legal department if your project is successful.
| hoakiet98 wrote:
| 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.
| DrewADesign wrote:
| Honestly I would change that wording immediately. Even being
| pretty savvy with this stuff, I thought this was an open-
| sourced webflow when I skimmed it and I assure you, if they
| even vaguely consider this a future threat to any of their
| business at all, their counsel will use it as a legal cudgel
| to bludgeon you.
| lukan wrote:
| I agree "the power of webflow" implies a connection.
| "inspired by webflow" would be probably better, but even
| there I am not sure if it is safe enough.
| DrewADesign wrote:
| Absolutely. If I came out with a project that said "Get
| the power of Oracle with a simple javascript API" people
| would think I had a new Oracle API for javascript, not
| that I had a JS-friendly database I thought was as good
| as Oracle. But before I even mentioned webflow at all,
| I'd first want to make sure they didn't have any related
| patents I'd be bumping up against without being able to
| clearly show prior art. Only after that might I consider
| saying "webflow-style workflow" or something along those
| lines. It's sad, but you have to assume their lawyers
| will use every legal tool at their disposal to protect
| their client's bottom line whether its reasonable or not.
| hoakiet98 wrote:
| Point taken, we'd do better without the headache for now
| until further legal counseling. Changing the tagline now.
| Thank you all for the suggestion!
| DrewADesign wrote:
| Best of luck! Great project.
| pavlov wrote:
| I'm not a lawyer, but here's some high-level general
| suggestions from a specialist which could be helpful:
|
| https://www.cohnlg.com/the-nuances-of-trademark-use-in-
| adver...
|
| It looks like you've got a really nice product idea here! And
| Webflow has raised hundreds of millions, so they have a war
| chest for this kind of thing. I just don't want to see you
| run over later.
| rsp1984 wrote:
| This looks pretty awesome but, speaking only for myself here, the
| thing I actually want is just Webflow but without the BS and
| predatory pricing.
|
| A visual editor that produces plain old HTML, CSS, JS and that
| anyone in our company can use to make changes to pages or create
| new ones. That's it.
|
| I don't think it exists (if so, pointers would be very welcome!),
| so here's my comment to incentivize someone to build it.
| freedomben wrote:
| I agree. What I personally would love is a WYSIWYG front end to
| a static site generator that uses eex or erb. If the tool is
| sufficiently open source and works well with some hand tweaking
| of generated HTML, then eex/erb isn't strictly necessary.
|
| I'm optimistic about this though, because my suspicion is that
| since this tool just exports React, you could relatively easily
| achieve this using Next.js SSG building. As long as you aren't
| doing any build time or runtime dynamic data loading, by adding
| one more step you can use this for that, with the bonus that if
| complexity goes up to the point where you would want to
| componentize, your tool is ready for that.
| rchaud wrote:
| Pinegrow Web Editor and Bootstrap Studio could fit the bill.
| No subscription, no cloud, one-time purchase. Exported HTML
| is fully readable and editable outside the app.
| hoakiet98 wrote:
| > because my suspicion is that since this tool just exports
| React, you could relatively easily achieve this using Next.js
| SSG building
|
| At the core, we generate pure HTML and CSS, then serialize
| those into React and Tailwind. It would be one less step to
| expose the HTML and CSS instead. I wanted a narrow scope to
| this so that's the focus but I imagine there's a plugin setup
| we can do to swap in what framework (or non-framework) you
| would need.
| localfirst wrote:
| but this is a tough problem with constant maintenance involved
| and you want it solved for free and handed to you on a silver
| platter
|
| have you considered paying developers or supporting open source
| software? I doubt it.
| _fat_santa wrote:
| I think one challenge that you will face is that Webflow is a
| SaaS app while your app I have to host somewhere. 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. On the other hand if I'm a
| developer then I have to weigh the time it would take to host and
| maintain the app versus just building a regular react app from
| scratch.
|
| My suggestion is keep offering it as OSS, but offer a hosted
| version as well.
| lukan wrote:
| "My suggestion is keep offering it as OSS, but offer a hosted
| version as well."
|
| I would think, that is the obvious monetization plan?
| hoakiet98 wrote:
| Yes, that is the most obvious plan. I want to find a
| community-friendly way to do this.
|
| I know Supabase has a similar and successful monetization
| plan but I know some take issue with the way they offer their
| hosting.
| meiraleal wrote:
| There is nothing to take issue, open source projects are
| allowed to monetize the same way as closed source projects.
| Your first thought needs to be how to create a sustainable
| project otherwise you won't have a community.
| hoakiet98 wrote:
| > 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?
| freedomben wrote:
| Thanks, this looks pretty neat! Definitely a project to keep an
| eye on :-)
|
| I love the approach of having it show you the code (and diff) and
| control on writing it back. This seems like it may be very
| useful!
|
| As an AOLPress user back in the day, it's both really surprising
| that in 2024 we don't have more WYSIWIYG tools, but also
| understandable because of how hard it is to design one.
|
| 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. There's also the problem of what kind of code it
| generates, and how to generate good/maintainable code that
| doesn't tie you to the WYSIWYG tool for the rest of its life. I
| haven't had a chance to try this yet (though I plan to) so I'm
| not certain where it falls on each of these, but from the video I
| get the impression that you are well aware of these challenges.
|
| Thanks for sharing, and thanks for making open source!
|
| Edit: Adding a couple of question:
|
| 1. Are you planning to monetize? If so, what are some of your
| ideas?
|
| 2. What is the grand scope for Studio? It sounds like the
| immediate focus is on editing styles. Are you planning to keep
| the scope limited to that, or would this eventually become an
| everything-you-need-for-building-a-website type of tool?
| hoakiet98 wrote:
| > 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.
| hoakiet98 wrote:
| > 1. Are you planning to monetize? If so, what are some of your
| ideas?
|
| Yes, though my plan is not concrete, yet. I plan to offer a
| hosted version for teams with fewer technical members to be
| able to contribute the same way a front-end engineer would
| without self-hosting.
|
| This involves potentially hosting their app along-side the
| editor and creating friendlier abstractions on top of the git
| process such as creating branches, PR's, etc.
|
| Secondarily, I want to explore collaboration as a feature. The
| overall theme is to bring less-technical folks into the front-
| end.
|
| > 2. What is the grand scope for Studio?
|
| Short-term, I want styling to be very good. Then text content
| for copy-writing. Then structural changes such as reordering,
| inserting, and removing DOM elements.
|
| I want to keep it in the UI as much as possible since the
| surface area for logic is very large. I don't know if we can
| really be Webflow while letting users maintain full control of
| their code so if we have to compromise, I would lean more into
| giving control to the user instead of doing powerful features.
|
| Please let me know your thoughts on this plan, it is still in
| development :)
| freedomben wrote:
| Nice, thank you!
|
| Yeah monetization is always tough, especially with something
| like this. My thoughts (were I in your position) would be to
| offer a full/unrestricted and open source single-player mode
| (open core model, with core licensed AGPLv3) that just
| modifies files on disk and is otherwise completely ignorant
| of git or anything else. Then for paid/hosted version, on top
| of it being hosted, you get full integration with github so
| PRs and diffs and things can be sent directly from the tool
| (which is great for designers). That also wouldn't require
| devs to do anything to buy in since the interface for them is
| just standard PR workflow.
|
| If it were me personally, I'd probably make the whole thing
| ("enterprise" features and all) open sourced under AGPLed
| with monetization being a hosted version available for paid
| stuff. Make sure you own the copyright so you can relicense
| in the future should that become necessary. I think you still
| get the vast majority of users that would be willing to pay
| that way, but you also get that crucial group of people who
| want the _option_ of ejecting from you as a vendor should you
| go a directin they don 't like (enshittification, etc). It's
| also IMHO a very ethical way to do business. Register
| trademarks on your app's name and stuff, and defend them
| proactively. Worst case scenario if someone forks and tries
| to compete with you, at that point you exercise that
| copyright to relicense the different parts to the "open core"
| model. It isn't likely to ever be an issue, but if it did you
| have a move.
|
| For targeting devs vs designers, IIWM I'd probably make the
| UI modal. I.e. design mode vs developer mode. Design mode can
| cater to designers, dev mode to devs. That way you can make
| UX decisions for one group that would irk the other group.
| bbourn wrote:
| This is amazing, thank you for building!!!
| hoakiet98 wrote:
| Thank you for checking it out!
| edweis wrote:
| Similar and also very neat: https://luna-park.app/
| hoakiet98 wrote:
| How cool! There's a lot to learn from here. Thank you for
| sharing.
| meiraleal wrote:
| Is it open source?
| danielvaughn wrote:
| Looks interesting. One word of advice - the CTA "talk to a
| founder" makes me stop and think. I wondered to myself "why would
| I want to talk to a founder?" You don't want the user doing that,
| it should be obvious.
|
| I'm pretty sure that button is for a demo, so you want to phrase
| it in terms of the value to the user, i.e. "schedule a demo" or
| some variant thereof.
| hoakiet98 wrote:
| Good catch, thank you. Changed it to schedule a demo.
| fswd wrote:
| > Some interesting challenges: 1. There is a React parser that is
| used to parse, insert the style, and serialize it back to code 2.
|
| here's another approach I used with dynamic react
|
| https://github.com/mhsdesign/jit-browser-tailwindcss "dynamic
| tailwind"
| da4id wrote:
| How's it different from something like reka.js or builder.io?
| hoakiet98 wrote:
| To my understanding, Reka is more of a core no-code builder
| library while we're an implementation of it. Now I'm
| considering if we should use Reka to build out the rest of the
| editor.
|
| With Builder.io, you have to set up a component to inject their
| UI into your app. It's more difficult to set up and maintain
| the components. We're opting to give full control of the code.
| You can develop with Onlook locally without internet for
| example.
| karaterobot wrote:
| This looks cool. I always thought that Webflow's model for how to
| snap together a UI was a good intersection of pick-up-and-play
| simplicity and _just enough_ customizability under the hood. But
| they 're a bit expensive, and I hated having my projects under
| their control. I hope this project continues to grow by leaps and
| bounds!
| anakaine wrote:
| They're more than just a little bit expensive when it comes to
| small builds and trying things out. It's impractical to pick up
| as a part time hack.
| ENGNR wrote:
| I think you're onto something. I'm not sure what you mean by
| 'components' on the roadmap, but if it's the ability to bring
| react components back into the editor, and have the designer
| WYSIWYG modify the props - that's the exact thing we've been
| saying "suuurely this must exist" for a long time (rant mode
| enabled).
|
| The key pain for us that I think you're touching on is that
| "design/dev mode" isn't how teams actually work. Devs do far more
| design than we think. My experience is that designers do the
| pretty or complex pieces, while dev does the long tail "boring"
| designs. Often devs do the screen layouts since nav and routing
| can get a bit complex. Secondly, designers don't just hand off a
| design and that's it. The design system gets implemented as
| components, which have tweaks due to usability/issue
| reports/further design, and then the designers really want to be
| taking those components and recomposing them back into sections
| and screens. Ideally designers would be just setting props like
| images, text and ids faaaar up the abstraction layers, with dev
| components being automatically synced back in as they're built
| and updated.
|
| So definitely think your setup is potentially hitting a sweet
| spot between dev/design. Just to validate it as as product - plus
| one for open source with a paid hosted tier for convenience. Devs
| get to tinker, and designers don't have to think about how to run
| it.
| coryvirok wrote:
| Why did you decide to rewrite this in react vs svelte?
|
| As someone who loves svelte and whose been writing a fairly large
| svelte app but has been jealous of the react ecosystem, I'd love
| to hear your rationale.
| hoakiet98 wrote:
| It pained me to do this. Everyone I talked to used React
| instead of Svelte. At some point, we realized we were spending
| half the time supporting Svelte just for ourselves for <10% of
| the return.
|
| I still love Svelte and will continue using it for side
| projects but right now I think the tech needs to get out of the
| way of the better user experience.
___________________________________________________________________
(page generated 2024-07-08 23:00 UTC)