Replies: 1 comment
-
|
Hello @theopaolo |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Salut, l'équipe de docs !
I’m a front-end dev/designer working on accessible, neurodivergent-friendly digital tools, and I’ve been exploring the Docs project. Great work, very interesting capabilities and strong alignment with open-source and self-host-friendly values.
I’m curious about the project’s strategic decision to build a new collaborative editor rather than collaborate with or adapt existing open-source note/wiki tools (e.g. AppFlowy, Logseq, Affine, Anytype, etc.).
Questions
Technical stack & sovereignty
I also noticed that the current stack uses Next.js, Yjs, and BlockNote.js, all excellent technologies, but primarily U.S. led ecosystems.
Given that Docs is part of La Suite Numérique and aims to promote digital sovereignty, could you share the reasoning behind these choices (e.g. maturity, maintainability, accessibility, ecosystem support)?
For example, was a comparison made with lighter or more European alternatives such as Nuxt, SvelteKit, or even web-native options like Web Components, which might align more closely with goals of sustainability, simplicity, and autonomy?
Having a short “Technical Rationale” or “Architecture Decisions” section in the documentation could be very valuable, both for transparency and to inspire other public actors who wish to adopt or build on similar principles.
From a contributor/community perspective, understanding these choices helps newcomers decide whether to contribute directly, build adjacent tools, or explore interoperability.
Thanks for your work and openness, happy to contribute or help document these topics if useful.
Théo G.
Beta Was this translation helpful? Give feedback.
All reactions