FAQ (w/ answers)
Ironically as frequent connectivity turns to ubiquitous connectivity, users are starting to prioritize offline experiences to avoid the ever increasing surveillance of a data hungry corporate enterprise. And as open web standards like WebAssembly, WebRTC, IndexedDB, and WebGPU are making the browser more native, we can now run applications “locally" in a web browser that typically were only possible in server backed applications.
While local-first might seem like a rebradining of the offline-first (or even zeroconf) ethos, there is a subtle difference. Local-first can be seen as a superset of offline-first with the difference being in its intention: local even in the presence of strong connectivity. And this shift highlights the fact that even if you have high bandwidth access, there are still ancillary privacy/security benefits to keeping computation and data local.
While Liminoid fills a similar niche (literate computational programming) and uses a similar interaction paradigm (embedded cell based REPLs), the intended use cases are somewhat different. You can use Liminoid documents for interactive data science, but Jupyter will likely be a much better tool if you need an IDE like experience. Probably more explicitly though, Jupyter is a much larger project, supports multiple languages, and has a rich and mature ecosystem of complimentary projects. In comparison, think of Liminoid as more similar to an interactive nbviewer. Once you have iterated on some analysis in Jupyter or you have some results that you want to share, then Liminoid really steps up to the plate and ✨shines✨.
Oh, gotcha! Like binder then?
binder comes from a use case of reproducible research and as such it prioritizes data/environment/code encapsulation in order to produce consistent results. With Liminoid, we ~sort of~ get this for free since WebAssembly provides a consistent virtual machine abstraction (and might even replace Docker 😱), but Liminoid was not exactly designed for this purpose and WebAssembly is not quite there yet.
Liminoid currently uses Pyodide for its WebAssembly Python interpreter and its scientific Python packages. As such, it is currently a bit difficult to use impure Python packages and even cumbersome to bundle pure Python packages for the interpreter (especially specific versions of specific packages). If you start your analysis with the latest Pyodide supported packages, everything will likely be gravy, but that may be a big if for certain projects.
For these packaging sacrifices, Liminoid provides locality, scalability, and sustainability. Locality in that no data or code needs to be sent to a server to execute (and even works without an internet connection). Since all code executes in the browser, Liminoid is "infinitely" scalable w.r.t. the number of concurrent users. And while
binder is fortunate to have the support of various (hopefully well intentioned) cloud service providers, this does make it dependent on the good will of those companies/institutions.
Wait... so this is just Pyodide??
While Liminoid internally uses Pyodide (for now), the use case and abstractions Liminoid targets are quite different. The Pyodide project really was born to serve Iodide and does a great job at that. The compromise it makes for this however, is something of a coupling to the Iodide environment. This results in Pyodide being a little cumbersome to integrate into other applications. If you want a zero configuation browser based scientific Python development environment, definitely use Pyodide over Liminoid.
If however, you are interested in building end-user applications that can leverage extensible in-browser Python interpreters, Liminoid might be a better fit. In this sense, you can think of Iodide as a higher level application that could be built with the lower level Liminoid packages (w/ the distinction being reminiscent of the framework vs. library dichotomy).