After years of development as a side-project, I'm super excited to announce that Modulo is now ready to be shown as an "alpha" quality framework! The plan for this alpha release is to get early feedback before we finalize the external API, or spend time optimizing for DOM performance or the readability of source-code.
What to expect
Are you evaluating different frameworks for a project? I put together this
post so you have a better idea of what to expect, and whether or not Modulo
might be already useful, despite it's early stage of development. In a
"alpha" means: Modulo is ready for use, that is, if you
don't mind large bugs or incomplete docs if you stray too far beyond the
"Alpha" means "things kinda work". Here are things I'd recommend using Modulo for:
- Greenfielding simple SSG sites - Although the CLI-based
SSG isn't fully documented, it's still usable, and easy to get going.
npm init modulois all it takes to begin. The website you are using right now was built like this. Despite it's early stage of development, I think it's one of the simplest and most "KISS" SSR / SSG approaches out there!
Alpha may mean "things kinda work", but it also means "things kinda don't work". Here are known bugs & API changes as of September 2022:
- Unknown Bugs - While developing the Modulo website, I often encounter bugs and/or confusing or unclear behavior the further I stray from simple, well-tested components. If you are building anything that strays from the beaten path yourself, you might discover a few as well!
- Undocumented CPart API - #3 Most of the custom Component Part extension API is undocumented, and some of it is subject to change. This means that a big feature of Modulo (developing custom Component Parts) is still a bit in flux. However, as of this first alpha, it's unlikely to change too much from the API demonstrated in the "Experiments" examples in the Demo page, in case you wanted to jump the gun.
- Undocumented engine API - #3 Similarly, extending or substituting various "engine" classes in Modulo is undocumented (e.g. Reconcile, DOMCursor, AssetManager). The eventual goal is full customization of these as well, so that you can incorporate image-packing or transformations during the build-step, for example, or a more clever DOM resolver that better guesses element changes. The Templater has an example in the Experiments page.
- Undocumented CLI - #4 The CLI is mostly complete, but may undergo UI changes, and is mostly undocumented.
- Browser compatibility - #5 While it's tested on recent-ish versions of the most popular browsers (e.g. Chrom(ium), Firefox, etc), there is no automated browser compatibility testing or browser "matrix" or anything. The eventual goal is something like the (now legacy) Polymer system of shims: Clearly show which browsers are it's core target for compatibility (e.g. shim-free), which ones require shims, and which ones will not be targeted at all.
- Nested components - #6 There are some bugs and unexpected behavior around nested components and dataProps referencing the context of parent components in "slotted" DOM elements.
- Unstable builds - #7 Builds are unpredictable and inconsistent. The same boilerplate sometimes generates different hashes.
- Poorly documented Library, namespace, and loading logic -
<Library>CPart tag is intended to make it easier to keep your library files encapsulated and redistributable. Currently, the behavior is non-ideal and will likely be changed, especially around distinguishing "configuration" from "definition", "namespace" from the unique "definition names" that CParts get, and so on. The documentation will need updates on this as well.
- Undocumented and config logic and changing API - #9 Modulo has an undocumented configuration system, intended to be leveraged both internally and by CPart developers for a consistent way to configure third party middleware as it gets integrated. The API for this is likely to change, and thus is mostly undocumented.
- Poor code quality -
Not only has the code base (slightly!) exceeded 2000 lines of code,
which is pushing the envelope in terms of complexity and framework
"heaviness", but it is also filled with commented out code, repeated
code, hacked-together messes just to get tests running, and so on. As
of writing this post, there are 93 instances of
TODOand 19 instances of
XXXin the Modulo.js file, so clearly some work to be done there!