Brick is a library of re-usable UI components that enables developers to build performant, consistent, quality web application UI. Brick accomplishes this by using Web Components technology to expose components as DOM nodes, for ease of authorship, ambience of API, and interoperability with existing DOM-oriented web frameworks. To accomplish this, Brick will:
- Curate a list of quality components from a larger Web Components ecosystem to meet common web application authoring needs / UI patterns
- Author components when they are not more wide available
- Give them a consistent and simple visual appearance
- Ensure components are functional on a list of supported web environments
- Ensure they are performant on a list of supported web environments
- Offer components individually for advanced users, as well as in bundles through a simple web interface
- Have an active an supportive online community who help maintain the project and report issues
To meet those goals, we are taking the following steps:
- 2013
- Ship the current set of components in a 1.0-stable quality milestone release by the end of 2013
- Promote the project through an internal/external series of blog posts/ brownbags
- "Prove" Brick's viability by shipping Brick components in an Apps Engineering flagship application
- 2014
- Adding additional components in a backward-compatible series of early 2014 releases
- Offering additional appearance options, as well as an open-ended skinning functionality
- Ensure interoperability with other Mozilla Web Components use-cases, as well as the larger Web Components community
- Support developers using Brick in their projects to ensure a quality development experience.
- end-developer. noun. An end user of a product who will use said product in their role as a software developer.
One of the largest challenges facing the Apps Engineering team is one of laser-focused scope. When providing tools for developers to use (and when engineering solutions for one self) there is frequently the impulse to create a whole solution fresh from scratch. This tendency is usually known as Not Invented Here. It a knee-jerk (and sometimes accurate notion) that "I can do it better for myself". Indeed, in most cases the solution you build for yourself seems superior, because it's tailored to the precise way your mind operates. It's made for you, by you. The bespoke nature of such a solution and the emotional investment that went into it makes that solution the best one for the job.
This predeliction in developers is infectious, starting with one custom job for one particular part of the stack, and spreading. Why does it spread? Frequently because the custom job has a custom API that necessitates modifying the other portions of the project it interfaces with. This document is not to condemn NIH, but to show it is a dangerous notion. In the hands of inexperienced or arrogant developers it leads to a one-off software stack. When the inventors of such a solution depart (frequently to go re-write someone elses project 'better'), this custom solution is a liability. The new engineers who come in on the project have no familiarity with the code, no insight into its creator's mind, and have as much chance of success with the codebase as a man trying to find the perfect pre-owned bespoke suit.
The flipside? With the right team, feedback, design, and a bit of luck, you get a new, influential technology. Think Rails. Android. Node.
One of the major factors at play is how "opinionated" a technology is. Opinionated software can be a very good thing. "Opinion" in this matter is taken to mean what design decisions went into its creation. Opinionated software is as much defined by how it does the things it does as what things it intentionally does not do. There of course is the risk. Given other choices, a developer will tend to gravitate initially toward software with opinions matching their own. They may after a time "get" the new project, and then come to love it, but a clash of opinion can create an initial hostility. Such hostility can doom a project unless it is driven with clear purpose by a team which backs up its opinions with utility, quality, and novelty.
An end-developer is more likely to experiment with an opinionated or unfamiliar technology if it serves a particular part of the development stack with which they are not as comfortable as those in their primary area of work.
Why go into this Mythical-Man-Monthian exposition? It's important to establishing a pilosophy at play that I belive lies at the core of the challenges faced by the Apps Engineering team. One of the goals of the Apps Engineering team is to enable developers Open Web Apps more easily, more quickly, and to a higher standard of quality. One of the early efforts by the team was a set of Web Application templates and accompanying tools known as Mortar.
We tested Mortar templates in the wild at a series of developer events, and the collected feedback painted a peculiar picture. Some developers complained the project "did too much" for them, and did not operate well with their existing toolchain. Others said the project did not go far enough, and did not do enough to assist them.
How can the same project both do too much and too little for the same audience? The answer lies partially in opinionation. Mortar used a particular toolchain, environment, build process, etc. Few of these design and implementation decisions were poor decisions, but the aggregate of each selection produced an aggregate "fingerprint" that did not match our target developers. The developers at our events needed us to provide them with solutions for the following problems (this is a non-exhaustive list):
- Getting their Apps to work offline
- Authoring and Application Manifest
- Building an 'app-like' user interface.
- Integrating with existing HTML5 toolchains
- Properly handling touch-based input
Mortar took steps to address each of these concerns, but glued the solutions together with a module loader and command-line toolchain that experienced developers found in conflict with their current development style and novice users found impenetrable.
How do we provide solutions to the very real problems faced by the developers we are trying to assist? Instead of large-scale templates and full-stack solutions, I propose a series of compatible, opinionated, but very focused in scope software libraries. Mozilla historically has produced software for end-users and end-developers alike, but mostly in the form of complete solutions. The Web Development team from time to time extracts code into the form of libraries and shares them with the larger web development community, but it is a side effect of day-to-day operation. Contrast this with projects like Angular at Google, and Bootstrap at Twitter. These are products targeted at a developer audience whose artifact is offered in the form of code to be used in the creation of larger works. This is nothing radical, but is something curiously lacking at Mozilla, and something the nascent Open Web Apps ecosystem sorely needs.
As opposed to a large monolithic project that aims to solve every problem at once, we should identify each problem individually and produce a surgically-precise library that suits the need, taking care to ensure each library works well with the others, and more critically, works well with other existing solutions developed elsewhere.