-
Notifications
You must be signed in to change notification settings - Fork 11
Calmm evolution discussion
This page is for discussing ideas for future evolution of Calmm.
Calmm and all the libraries was and were born and have largely been developed in the context of actual client projects. Given that Calmm has now been used in several projects, it would make sense to try to develop Calmm further into a polished framework on its own.
Feel free to add your own thoughts on what you'd like to see in Calmm or where you'd like to see Calmm in the future! Just start a section with your GitHub id.
I'd like to see a new small FRP library developed to support Calmm.
Both Bacon and Kefir are designed to support method chaining and have most of their combinators in the prototype chains of observables. This means that neither library is amenable to dead-code elimination using current bundlers (WebPack, Rollup). It would be better to have only free functions, which can be dead-code eliminated by current bundlers.
Both Bacon and Kefir are quite slow. Bacon also tends to take a lot of memory. Kefir is 5x-10x faster and leaner than Bacon, but it should not be difficult to implement Kefir style semantics to run much faster and leaner.
Most.js is the performance leader, but its design does not seem optimal for Calmm. Most.js is about streams of events rather than time-varying properties. In Calmm we mostly deal with time-varying properties where we can and want to always have a current value, skip duplicates, and possibly share the properties with multiple observers. Calmm style is to use stateless and applicative properties rather than monadic and stateful streams of events like in Most.js.
Ideally I'd like to have semantics similar to Bacon with glitch avoidance. My current thinking, however, is to start with something simpler, like basically largely copying the semantics of Kefir and implementing those semantics from scratch while paying attention to avoiding performance pitfalls in Kefir such as the creation and copying of event objects and quadratic manipulation of subscriber lists. I would estimate that it would be possible to get something useful from such a simple premise within a couple of weekends of work.
Karet Util should be split into a number of libraries. In particular, it would be better to have separate libraries for lifted Ramda and Math modules. This way the separate lifted Ramda (and possibly other lifted libs) would be easy to maintain and there would be no name collisions. Also, given a new FRP library, there should be no need for a curried version of Kefir.
Karet should be parameterized to support different VDOM implementations such as React, Preact, Inferno, and possibly others. It is not clear to me what is the best way to go about such parameterization.
The core of Calmm is quite powerful on its own, but it could be useful to provide somewhat more functionality out of the box.
- Validation library
- Routing library
- Undo-Redo library — the current Undo atom is not as flexible as it could be.
- Development tools (visualization of dependency graphs, time travel debugging, ...)
It would be nice to have a polished homepage for Calmm.
- I have had some people tell me that it's quite confusing that Calmm comes with so many libraries. I think writing own FRP implementation for Calmm is a good idea, and with that done I would say it'd be beneficial to split Calmm into packages such as:
- Main Calmm package which comes with all the various smaller utility libraries (with dead code elimination). It would probably be a good idea to make Calmm FRP implementation compatible with EcmaScript observable spec.
- Package which allows you to use Calmm with various VDOM implementations, ie. calmm-react. Another thing to consider is simply to make the VDOM library so generic that it simply works with any observable library which satisfies EcmaScript observable interface obs[Symbol.observable]. I'm not sure how much overhead that would be but that would also be useful when upgrading from existing Calmm to future Calmm as embedded Kefir observables would still work.
- It'd make sense to keep partial.lenses as separate library.
- Site for documentation with more concise info and quickstart so it's easier to get started with Calmm. I'd also put all the smaller utility library documentation under this one place.
- It would be nice that with Calmm's own FRP implementation everything would be treated as property, and combinators shouldn't convert properties into streams. It might make sense for U.bus to be the only way to create streams and then combinators and other operations would keep these as streams.
- At the moment some karet.util functions return observables despite dealing with plain values. In future to avoid unnecessary listeners this could be improved upon. This will probably be easy enough to do once karet.util no longer naively uses Kefir's methods.
- If it's possible to get rid of placeholder variables (U.__) when using curried functions, it would be huge for making the library easier for newcomers to use and understand. U functions synchronously doing wrong things can be very confusing and hard to track.
- Maybe Calmm could be positioned marketing wise (e.g. on the coming Calmm-website) as a solution to building complex editors for Redux-content. A bit like Redux-sagas.
- It would be great to have a documented workflow and helpers to gradually introduce calmm into a redux project
- Here is a typical non solvable issue with redux