jsunderland323

I walk into everything ready to be hyper critical, so thanks so much for saying that.

In my experience, I found the switching cost to be low for things like copy changes and css stuff (or lower than I expected). Obviously I am incentivized more than anyone else to use it but it’s actually painful to go to an IDE to make those small changes after you get used to it.

I don’t realistically expect anyone to use us as a full IDE yet. It’s got a ways to go but for simple things, it’s awesome. We’re going to keep chipping away though.

Aw thanks so much. I knew there had to be some folks whom this would resonate with.

I'm excited for you to try it out too! Please let me know how it goes

It does! I'm an avid vim user so I made sure it had ctrl-p, ctrl-w (for window switching), (slash space for search), a nerd tree equivalent file tree explorer. I build all features to be vim compliant first. Just toggle enable vim mode in the settings.

Me too. I know HN doesn't love YC companies but I was a little shocked.

I swear it isn't vaporware but there's only one way to find out.

There are definitely rough edges, we are after all a 2 man band but I don't ship things that don't work and it's admittedly not done great with older versions of React. You should try it though!

It's a bit of an aspirational name. For now it's just React, but we hope to get to support other frameworks that use JSX when we have more bandwidth!

Gotta respectfully disagree here but yeah, I definitely understand the remote workflow use case and why some folks want that.

I think if you're building something that is targeting designers that is the way to go.

Thanks for checking it out though!

> Are you saying you invented hot reload?

I'm not saying that, no. We are super dependent upon HMR servers from Vite/Next.

We made the ability to write back from your dev panel to your filesystem and made a JSX inspector. As far as I know these are not things supported by either Next or Vite.

> And browser CSS inspectors are really great

I couldn't agree more. I agree so much that we wanted to make one so that you could do the same to JSX as you can do to HTML.

> Can you explain the value add over all these free things we already have?

You should watch the demo video!

> How are you planning to acquire customers?

We haven't gotten much further than just launching and praying.

> Is this sponsored by yc?

I mean we're a YC portfolio company, so sort of I guess. I used to work at YC, so I suppose YC has been sponsoring me for a while now.

> Who are the target audience?

React developers

> Are the target audience companies or businesses or individuals?

Both, I hope. We definitely went more along the lines of supporting individual developers spiritually but there is no reason it shouldn't work if you have colleagues.

> Congratulations

<3 Thanks so much!

My UX feedback is that I had a natural inclination to click on one of the response comments to my query and expected to be redirected to that hn post and if possible scrolled to the comment. I know why you might not want that but as long as you’re using query Params and not doing anything weird with browser history I’d almost certainly toggle back.

I could definitely use this as an alternative to hn algolia for some things but it’s going to be hard for me to remember. I’d recommend doing this as a browser extension or something so it’s not 100% lost in the void.

This is great! Will try to give a try later

Yeah, I had a similar thought. If they just removed the ai or only focused on building a voice command to mobile app sdk there could be something viable there. Sadly that’s just not what they made at all.

Yup, this reeks of sock puppets

Well happy to share the edges I ran into if you want. Feel free to reach out (email in bio).

Hey Thanks!

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.

I love ink & switch! I think Martin, Geoffrey, and the whole team are crazy smart.

There's a whole bunch of approaches to universal versioning and I think floro is one of a few upcoming techniques in the ether.

From my limited understanding of their approach, it looks like they're going to be really focused on things like rich text diffing, which is not something I think floro is particularly well suited for. I think floro is really great for things that end up getting consumed as code rather than something like note-taking. e.g. static assets & i18n.

It's really exciting to see this space actually beginning to blossom though!

Thank you so much!

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'd be happy to hear about your project and share my learnings if you want to schedule a time to talk. I've put a tiny bit of thought into this problem and would love to pass on what I've learned.

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.

Oof, sounds ominous. I have not heard of them, so it's hard for me to know where they stumbled or draw comparisons to what we've made.

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.

> I shouldn't be expected to pull down changes and test locally (unless that part can be automated and made super easy to do without fuss).

It's super easy and there's no fuss. You literally just switch branches. It's really easy to think the experience is analogous to code but it's not really. There's not a complex IDE setup or any complex local environment setup -- so it really is like just pull the branch open your browser, navigate to your website and test the changes.

By page do you mean like your live website with the changes?

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.

Now we’re getting into the depths! This is a great question/point.

> so your production website loads whatever latest asset version from a floro api endpoint and my repo state is not a snapshot anymore of what what the page will look like on production?

Yes! But it’s your choice to decide which plugins to do this with. You can break your build environment without breaking your production environment, which is really important because you want CI to catch something like a missing icon or a bad invocation of a pluralized string but you also don’t want to block being able to update safe production changes like correcting a minor-typo. Breaking a build because an assets was deleted is easy to resolve for engineers.

> in that case why do the repo connection at all? isnt floro then much more a cms / custom database with versioning for translations/ assets/ colors than an extension of the repo side?

I think it would be very intellectually dishonest to say otherwise (with some minor caveats) but you could say the same about code too. Isn’t github just a CMS for code?

The thing about the snapshot that the code imports at compile time is it allows you to determine the structure of how the application consumes assets in static analysis. This is what allows you to determine what is safe to update live and what isn’t. Could you do this by snapshotting a database and performing static analysis on your imports? Yes, you certainly could but that’s not what CMSs do at all ...and SQL is really not good for merging things. Headless CMSs are built for really redundant data-structures because that’s what marketers need and they nearly all suffer from the same CI/CD issues for that reason. Why do we mostly check i18n string into git and not use CMSs for string content?

Ignoring all the other parts of version control we’re taking for granted here, branching, peer reviews, merging, etc. The big benefit of it all working offline is that you can let the non-engineers, who either lack access control to git or could not technically manage setting up the code base, test out content changes locally on your production site or app. CMSs can do with this with iframes but again, it’s really for blogging content/static content and not i18n. The other area where offline testing shines for people who aren’t engineers is being able to test out content changes on mobile devices over the local-network. That’s not really a thing CMS systems can do at all.

we do =D ... She's still getting her chops 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

HN isn't letting me nest further. I'll do my best to answer these in the order I saw them posted.

1) "i dont see how that solves the issue you describe..."

>the only consistency floro can enforce is if i use a color from a color set in an icon in floro and remove the color, it could complain i have to first change the color in the icon.

So it does do this actually, which is super helpful. You can also check for this in CI and choose to fail a build because of the inconsistency. It's also part of the REST api too so you can decide if you want to make a live update to something via webhook based on if inconsistencies are present. (see https://floro.io/docs/dev/api Invalidity Map Endpoint).

> if i delete an icon from the floro repo and my code in git imports this icon and renders it. floro cannot do anything to help there.

Actually, you kind of can. You have to do some static analysis that gets checked into git but you can use this to determine what is safe and unsafe to update in prod. I could delete the tagline of the webiste and modify some other piece of copy and it would not delete the tagline but would modify the other copy in production. This is really up to the codebase in how they want to handle live updates.

Here is an example of the webhook I do this in https://github.com/florophore/floro-mono/blob/main/packages/....

But I do not do this for icons because I don't really want to live update icons in production.

> but this sound like a really minor inconvencience vs not being able to do everything with git. or is there a concrete example where this would matter?

So the above point is where this really matters a lot and is not about minor convenience. Being able to make live updates to a site without having to worry about breaking the production app and going through a buid-pipeline is by far my favorite feature of the whole thing. Could you do this with a headless CMS? Yes/Kind of, it really depends how complicated the asset is and how much you think type-safety really benefits you. There's also a whole host of CI/CD problems you run into then.

> i dont see how that solves the issue you describe.

I don't know if I have much else to add aside from the above comments. If inconsistencies introduced to the repository prevent a translator or designer from using the tool until the inconsistency is resolved that's a really bad experience. I think if you can use plain-text for something, definitely do it. But it's a pretty unpleasant experience for people like translators and non-technical folks.

2) "another point is that enforcing invariancts..."

> another point is that enforcing invariancts is not the task of the repo but of the checks / review system. it is very simple to enforce your described cross file constraint with a ci check and prevent merging.

So yes and no. If we were to analogize this entirely to code I would 100% agree with you, but for simpler structured data types you can definitely describe cascading behaviors that could be anticipated and should be enforced by the version control system, which maybe gets at the heart of why I think it would not be useful to build this on top of git.

> and floro could also not automatically solve the conflict of inconsistency as concurrent deletion and modification of any data is fundamentally undecidable without knowledge of the application logic and business domain and sometimes even human user intent.

It does not use auto-merge, unlike CRDTs it does use user intent if a conflict occurs. It chooses between two sequences of potential acceptable merge results (yours and theirs). I do really describe this in depth in the page I posted above, I'm sorry if it's not clear.

You are correct that you don't get the granularity of picking some changes from yours vs theirs. You have to accept the entire state of either yours or theirs for a conflict before you can make revisions to resolve the conflict but you can manually resolve the consistency issues of the merge conflict in the plugin UIs, I actually show this very briefly at the end of our demo video.

> But can't you have a custom merge driver for 3 way merges too? So that when you try to merge the changes it does complain?

You kind of could, at least for diffing. This is what difftastic does https://difftastic.wilfred.me.uk/. Merging is really ambiguous in what the intended behavior of a removed reference is in AST. Do you delete or nullify or something else? How does that affect other upstream references? I'm not sure you'll ever find a satisfying answer there but floro is constrained to static assets, which are a bit more predictable.

> The advantage of building this on top of Git is fairly obvious: you get to use all the existing Git tooling, and you can use Git for other files in the repo that don't need special merge drivers.

So I think there is some confusion here in how this interfaces with code and I'm sorry I didn't think to explain this first. With floro you have a file in your git repository that points to a sha from floro to generate your assets from.

Here's an example https://github.com/florophore/floro-react-native-demo/blob/m...

I think of it sort of like having a package.json and a lockfile. You don't check your dependencies into git because odds are you don't want to deal with merge conflicts in third party dependencies, just the package.json and lockfile. Similarly you wouldn't want to deal with the conflicts of floro in a git repo. So you do still you get to use all the existing Git tooling with respect to your codebase.

The problem really is that git would allow for inconsistent states, which is fine for programmers but tough for anyone who doesn't know how to resolve the inconsistencies.

I'll try to contextualize it in the case of something like AST merging so it's more familiar.

Imagine you have file A and file B. In one change someone adds some code that imports something from file B into file A. In another change someone deletes file B without touching file A. That will result in a valid three-way merge. However, your compiler will complain and you will have to update file A to remove the references to file B. This is okay because you can edit the plain-text and fix the inconsistency. This doesn't work for things where you can't really hop in and manually fix the conflict.

You could definitely create a tool that understand the AST and knows how to remove stale references. If you add in the requirement that there cannot be inconsistent states at any commit you've essentially derived an entirely new merging system. Could you build this on top of git? Sure, it's a plain-text system, you could build anything on top it. Is there any gain if the point of the system is to disallow manual conflict resolution and enforce consistent state? I don't think so but maybe I'm not seeing something.

It's testing to see if the daemon is running from the electron app. It uses the connection to the browser for things like sign in and verification and for being able to redirect links into the electron app.

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.

It for sure is more complicated than adding files to a git repo. You are 100% right and I wouldn't dispute that for even a second. I'm not exactly advocating this for solo-projects unless you are already sure you want to do something like internationalize your project.

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.

Exactly! This was actually Linus' point when he was explaining git to companies still on cvs. "You're all already using branches anyway".

I think if you're in a low-trust enterprise environment, branches kind of make sense because you get the additional scrutiny of code-review and merges occur on a centralized server but if you're in a four person team where you trust everyone just use the main branch and resolve locally.

> Remember, git replaced tarballs

I would refine that to say 3-way-merging replaced tarballs but yes!

It does but it can't support cascading states. I kind of explain this at the bottom of this page https://floro.io/technical-overview-part-2

Thank you! I'll put my email in my bio if you want any help at all, It's a heavy installation (but straightforward once it's setup).