Our great sponsors
-
-
automerge
A JSON-like data structure (a CRDT) that can be modified concurrently by different users, and merged again automatically.
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
(Disclosure: Work at Microsoft, but I work in Azure and some open source stuff, not on or directly with Fluid/Office/etc.)
That's just a trademark clause for Microsoft logos and brands. The Fluid Framework itself is [MIT licensed](https://github.com/microsoft/FluidFramework/blob/main/LICENS...) and doesn't require exposing any of those logos/brands when you use it, so the framework itself is fairly open for usage.
I think the main thing that would slow down adoption for Fluid is that the only "production" backend is an Azure service, which isn't part of the open source Fluid Framework. [Other open source backends](https://fluidframework.com/docs/deployment/service-options/) aren't recommended for productions. Until there are some open source ones, I'd assume adoption will be limited to folks in the Azure ecosystem.
I haven't used it, only read through documentation, but IMO it's not so much lock-in as an embrace of old-school columnar storage and handle-based object manipulation. An experienced Windows developer or game dev might feel entirely at home with the tradeoffs/footguns implied by https://fluidframework.com/docs/build/dds/#picking-the-right... ... but show that to a junior React developer and they're likely to be fundamentally confused, or worse assume that the only code example shown is a valid code example. (People writing documentation: please do not make one of the most prominent code examples in your Getting Started an example of what not to do!). And on the handle front, https://fluidframework.com/docs/build/data-modeling/#using-h... is similarly counterintuitive, to say the least.
Comparatively, I'm much more excited about Automerge https://github.com/automerge/automerge, which promises much friendlier developer ergonomics as simple as:
doc1 = Automerge.change(doc1, 'Mark card as done', doc => {