The way I originally conceptualized floro was a way to version anything without requiring plain-text (ie. higher order versioning). I've strayed quite a bit from that belief and I think there's a lot of complex trade-offs involved in version control and what makes sense for specific use-cases. Floro would be trash for game development but that is an industry that sorely faces tough versioning problems involving graphical data.

Please feel free to reach out to me if you do want to chat. The discord for floro is listed on the website but you can also just check my HN bio for my email.

The real focus of the system is for things that are better managed by people who aren't engineers but end up interfacing with code very tightly. The idea was to focus on the peripheral functions that come up in UI engineering and enable e.g. translators, copy editors, and designers to essentially commit to a codebase without having to understand git or know how to handle plaint text merge conflicts.

> I suspect that many of the people who influence the adoption of VCS are likely deeply technical and will likely actively avoid products that are opinionated on the target output when using the VCS.

I totally agree. You can modify the output to your hearts desire. This was a big part of our design.

I actually do think (and have personal evidence now to believe) that most functions adjacent to engineering can learn distributed version control. Once you start using it, you really don't want to go back.

We've internally adopted trunk based development for our assets and it gets rid of 99% of the confusing parts of version control to not use branches (I know blasphemy). My designer just pulls and pushes on the main branch and I do the same -- we've had very very few merge conflicts and none that couldn't be resolved in 30 seconds.

I feel silly now having spent so much time on branching as a feature. It makes a lot of sense for plain text and code but it probably doesn't matter that much (for small teams) for visual things. Merging has proven to be invaluable to us though.

We'll probably end up using webflow to market to designers. We were going for hackerish today.

We actually didn't use any component library. We designed all of our own components in-house

I put so much effort into that and you are probably the only person on earth who has actually read that thing in its entirety (aside from my poor, ex-midwife, mother who has no idea what I'm talking about).

> but am wondering if you're planning to apply the same techniques to traditional designer working files.

I would love to. When I discovered the JSON trick I felt really confident that this was the inevitable direction of the project but after writing a few plugins I'm not exactly sure how practical I really think that is now. It's great for primitives but I'm apprehensive about anything that starts to get into the no-code territory. I think it's possible but there's some mathematical and UI challenges I've got to overcome.

To make something more complex than a TMS system I really need to make the schema language a bit more robust in a way that is probably beyond my engineering skills. I need to find someone who actually knows how to write compilers and understands category theory (not me haha). I think this could be applied to something more general like figma/sketch though and I hope it's a first step for someone smarter than me to fill that gap.

I've thought about this too and I think down the line the plan is to be able to attach screenshots to merge requests. However, as a reviewer you can also pull down the changes and test them against your production site locally. So you can alter between the main branch and the feature branch and compare the differences like that. The benefit of this over a screenshot is it lets you actually get to see something like the hover effect in action.

To their point though, I largely agree with this, "The only thing I’ve found to be effective at dealing with competitors in early stage companies is to ignore them."

Did you ever get a chance to use their product?

This is something that really motivates me about offline first/OSS stuff though. It will be inconvenient for those who adopt if we have to shutdown but it's still possible to use floro without needing our servers. You will end up having to host your own though.

There are many problems where plain-text falls apart for even engineers though or there's some benefit to editing something through a UI or WYSIWYG rather than plain-text. If you're cool with markdown and editing SVG files manually -- do it.

The problem being addressed is when you have team members who need to do things that requires some level of type-safety but they either don't have the technical background to work with something like git or it would be non-sensical to resolve the conflicts in plain-text. The idea here is for designers to basically take control of things like icons and theming and for translators to take control of i18n. Their work is state that can be used to generate a type-safe API for engineers to consume those assets.

https://github.com/florophore/floro-mono/blob/main/packages/...

The reason it's happening on the landing page is because we use floro for editing the site and testing our changes offline first before pushing.

Just electron & vite. I might actually migrate off electron, Tauri (https://tauri.app/) seems to be getting more stable and it's gotten great reviews.

I think this is the boilerplate I used though https://github.com/cawa-93/vite-electron-builder.