Start / Alpha Release

Alpha Release

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 nutshell, "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 examples.

Good

"Alpha" means "things kinda work". Here are things I'd recommend using Modulo for:

  • Trying it out & and giving feedback - The primary purpose of this alpha is to collect early feedback. Maybe you're a JavaScript head and just want to learn each new thing. Or maybe you're shopping for a new lightweight framework, or love experimenting with new ideas in terms of framework structure. I hope Modulo's unique approach might be interesting to you!
  • A "glue language" for building simple component libraries for primarily server-side web apps - Despite the bugs and potential API changes, the Modulo JS framework is already now useful for building JavaScript components to fill in gaps in your existing web apps. Once you develop a functional component library, you can export the JS and CSS file, and include it into other projects, without any of the other Modulo boilerplate. This allows for easing into frontend development on backend-focused apps. If you are only making a few components here and there, it's fast enough you might even be able to get away with never even building, but just running the development version.
  • Greenfielding simple SSG sites - Although the CLI-based SSG isn't fully documented, it's still usable, and easy to get going. In fact, npm init modulo is 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!

Bad

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~ ~March 2023~ May 2023:

  • Unknown Bugs - While developing the websites using Modulo, 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!
  • Nested components that use slots - #6 There are some bugs and unexpected behavior around nested components, nested components getting rendered to the wrong spot during rerendering after a build, and dataProps referencing the context of parent components in "slotted" DOM elements.
  • 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.
  • 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.
  • ~Unstable builds - #7 Builds are unpredictable and inconsistent. The same boilerplate sometimes generates different hashes.~
  • ~Poorly documented Library, namespace, and loading logic - #8 The <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 config logic and changing API - #9 Much like Library and loading, 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 (similar to Django's "settings.py"). The API for this is likely to change, and thus is mostly undocumented.~
  • Poor code quality - #10 While I try to keep it below 2000 lines, the framework is filled with commented out code, repeated code, hacked-together messes just to get tests running, and so on. As of updating (March 2023) this post, there are 55 instances of TODO and 11 instances of XXX in the Modulo.js file. The goal is to keep it to 2000 lines of cleanly written and documented code, free of TODO or XXX, so clearly some work to be done there!