HTML-first
Modulo was developed with several goals in mind. Here are a few of them, in no particular order, with a brief explanation of each:
- HTML-first (Modulo is a HTML framework, first and foremost)
- Complexity layers (Complexity should be out-of-sight for simple things)
- Declarative (Coding should feel like configuration)
- Isomorphic (DOM determines behavior, behavior determines DOM)
- Explicit (Middleware is included and referenced explicitly)
- Simple (KISS - Keep it simple, silly!)
- Educational (Using Modulo should make you better at other frameworks)
How Modulo aims to be HTML-first
Modulo aims to be much more HTML-oriented compared to other web framework. In some ways, it's could be thought of as more of an HTML framework written in JavaScript than a JavaScript framework written in JavaScript.
HTML-first syntax
Modulo is HTML-first in that it piggy-backs off of HTML syntax. Component Parts are declared using HTML tags, within other HTML tags, as opposed to within JavaScript. It follows HTML syntax and semantics,1 and does not include a custom parser, so it can be compatible with the browser's parser. Script tags embed JS into HTML, instead of the other way around (e.g. JSX in React).
HTML-first workflow
Secondly, it is HTML-first in terms of development workflow. A greenfield Modulo-powered website starts as a static site of HTML and CSS files, created and edited by hand. As the requirements become more demanding, the vanilla HTML tags are gradually swapped for Modulo web-components, with templated HTML and bundled CSS. Only as requirements grow beyond the common use-cases offered by "canned" CParts does JavaScript come into play.
HTML-first integration
Finally it is HTML-first in terms of interoperability. Modulo exposes itself as a extension to vanilla HTML via the Web Components standard. The boilerplate is as lightweight possible: Typically just ~4 lines (Modulo tag, possibly including a Library), and you can now integrate your Modulo HTML components throughout the rest of the HTML. This means it will comfortably integrate with anything that deals with HTML, e.g. PHP, Django, Rails, and even other frontend frameworks.
HTML-first and Web 1.0 trends
For a slight digression, the rest of this article will be to compare / contrast this "HTML-first" mentality with the growingly popular so-called "Web 1.0" trends.
I've been noticing more and more developers online, especially the 90s web old-heads out there, reminiscing over the simpler times of Web 1.0. This trend is seen in a wide range, from minimalist bare-HTML to the GIF-laden retro-aesthetic. Both extremes are related to an increasingly dominant design trend, somewhat ostentatiously described as Web Neau Brutalism. This trend isn't just aesthetic, however. It is also a reaction to how Internet users increasingly use centralized platforms (social media, mobile apps, etc), and how the Internet, a tool once presented as an open, scientific platform for information and communication seems mostly just a tool for tech companies to churn out new ad platforms, in some cases adding little substantial innovation beyond creating marketing and GUIs to libraries developed at public universities. Web 1.0 is thus representing an “actually decentralized and user-controlled space for storing knowledge and communication”.2
I admit, as a web developer who started in the 90s, I'm squarely in the right demographic, and not surprisingly I generally agree with the aims of this "trend", if it could be said to have aims. However, I wouldn't even really say that Modulo is part of the "Web 1.0 trend", as it's built on top of the extremely complex execution environments that the modern web standards for web-browsers specify. That makes it quite the opposite of the simple elegance of, for example, the Gopher protocol, the failed alternative that could have saved us from the mess of HTTP (or so say its advocates) 3. That said, there's a clear similarity, as I took a pretty different approach for Modulo than most other JS frameworks. I wanted something that you can ignore until you need to use it, so you can focus on plain, static HTML and CSS and only think about framework aspects when you need to refactor. Despite the complex execution environment, I hope the Modulo component development workflow itself will feel like a similar return to fundamentals for other developers as well!
In this way, I hope that Modulo might fill the need for a bit of a compromise: A JS framework that the ascetic "90s-web" nerds tolerate, while also being appealing to everyone else, e.g. provide those "creature-comforts" to lure in developers in the various JSX or TypeScript ecosystems. Thus, the goal of Modulo is to accommodate ~75% of actual day-to-day web dev use-cases, and give sufficient documentation so the remaining 25% can get filled in without too much pain.
Thanks for reading my post!
- 1: Despite leveraging HTML's tolerance of things like capitalization (e.g.
<Template>), using capitalization like this ultimately just a different suggestion for coding style, other than the more common style for HTML of all-lowercase, or the less common ALL-UPPERCASE, for tags and attributes. - 2: When I say "actually decentralized", I mean as opposed to what I see as a simultaneous trend of recent vaporware projects — and, in some cases, actual scams — that dishonestly use computer science buzzwords like "decentralized", while marketing what are clearly extremely centralized, proprietary platforms.
- 3: The Gopher Protocol is a menu-based, intentionally limited protocol. It is seeing a bit of a renaissance among web developers who subscribe to the trends described here, and argue that it would never have gotten "bloated" like the HTML/CSS/JS execution environment served with the HTTP protocol. Pessimistically, I think that HTTP's bloat would have just happened to Gopher, since the bad stuff happened due to "corporate" and "money" reasons, not because we're still waiting on "the final ultimate solution to the protocol problem" (much like the mythical FUSSP).