Closed Vexcited closed 3 months ago
After a long reflexion process, and a lot of experiments on the Crowous library that got entirely rewrite in Rust, I realized that doing everything in a single language has a lot of cons.
Deploying a .dll or a .so (depending on the platform) would be very hard to maintain. We need to always have the .dll, .so or .dylib next to the binary output and this is pretty inconvenient for most people that want to use our libraries outside of the Literate scope.
Also setting up Literate with this would be a pain.
Providing a WASM build instead of a native JS/TS build is also a pain because React Native, for example, doesn't support WebAssembly out of the box and projects using Expo Go wouldn't be able to install a WASM runtime without prebuilding their app - and this is probably something they don't want to do, and I don't want to force them to.
Note that a static library should be built depending on the platform architecture also and that's very hard to support when coming to Android (or obscure Linux configurations)...
That's why, I'll close this issue as "won't fix" and I will keep the current configuration for all of our projects : one branch per language and each language have a native support written in the language itself.
I sadly got too hyped about these technologies and kinda wasted time. At least I learned about my error and that shouldn't happen in the future !
As the title says, we want to migrate the whole
js
branch codebase into a a single language codebase.Why ?
Since we want to support multiple languages (and we're a bit lazy to rewrite the whole implementation in different languages on each update) we need to have a "core" library. We thought about using a low level language to do it.
What will be the structure ?
This core library WON'T make HTTP requests by itself. It'll be the parser and the builder of every requests made in other languages.EDIT:
The library won't make HTTP requests for the WebAssembly build. It'll take a
fetcher
from JS to make the HTTP request and then return this value to the library.That's why for each API call we'll have three functions : the
base
function, a function ONLY for WASM and a more general function. Both of these two functions will have the same name, it'll just build depending on the target. They'll both call thebase
function (but with a different fetcher)How will we support multiple languages ?
Here's how we see it: we'll make a WebAssembly build for JS/TS and FFI for every other languages (such as C#, Kotlin, Swift, Python and more)
What about the
js
anddart
branches ?They'll be deleted once the rewrite is done with the bindings working for JS/TS.
Please understand that the work done in the
js
branch wasn't useless since the whole new implementation will be based on the hundred of hours spent on that branch.What about next releases ?
Once the rewrite is done with JS/TS bindings working and maybe FFI PoC working, we'll do the v1.0.0 release.
All past releases for the
js
branch will be moved to "pre-releases". They'll still be available on NPM, but might go deprecated after the release.Roadmap
I'll try to keep this roadmap updated with time.
Setup
cleanPronoteUrl
Requests (and async)
Authentication