Ez-build is a tool to enable web developers to easily implement a build workflow utilizing modern standard technologies, such as ES2015. To achieve this goal, ez-build codifies common processes and practices, by making some crucial choices for you.
As it stands, the current state of web development means that when you start a new project you're easily overwhelmed by choice – the choice of languages, frameworks, tooling, etc.
This problem is not specific to web developers either. In fact, American psychologist Barry Schwartz discusses this problem from a consumer standpoint, in his book The Paradox of Choice – Why More Is Less. It is argued that shopper anxiety can be greatly reduced by eliminating consumer choices.
This problem of overwhelming choice is especially obvious when it comes to build tooling for web development. The popular tool webpack has an entire section of its documentation dedicated to lists of loaders and plugins. Another popular tool, grunt, has thousands of plugins.
The web development community in particular has a problem with choices, in that there are too many. This often leads to questions like:
- How should I structure my project?
- What compiler should we use?
- Should we enable non-standard features?
- How do we deal with non-code assets?
- What kind of optimizations should we do?
- Where do we get dependencies from?
- How do we package our project for distribution?
And many, many more. It is very likely however, that none of these questions are actually relevant to you delivering whatever product you're building. In fact, at the end of the day, whoever is consuming your product probably doesn't care what language you wrote it in, or what compiler was used to create the deployed code.
This is where ez-build comes in. By making some important choices, ez-build becomes a build tool that does many things – compiles code, copies files, optimizes, generates metadata, etc. – according to certain conventions. This is common practice in many areas of software engineering, and in some ways ez-build can be compared with tools like gcc, or clang.
It is not one tool, it is a collection of many, with the explicit goal of turning sources into something distributable – based on a set of choices made for you. These choices include:
- What compilers to use
- What languages to target
- How to structure projects
- Where metadata goes
- How to define dependencies; both developer and runtime
This means ez-build is less flexible than simply stringing a collection of tools together; but on the other hand, this means all builds follow a certain convention and have predictable end results. We are eliminating choices, in favour of reducing anxiety and increasing focus and productivity.
While ez-build eliminates a lot of choices, it doesn't eliminate them all. Indeed, some flexibility must remain so developers can add functionality that may be crucial to their specific use case. For example, React is a popular user interface library these days, and it's often used with JSX – a non-standard ECMAScript extension. This is the kind of flexibility that ez-build allows, by providing ways to augment the defaults.
On the flip-side however, it is not possible to wholesale change the way ez-build operates. For instance, ez-build doesn't – and likely will never – support other languages than standard Javascript, CSS, etc. For instance, ez-build has no support for something like TypeScript, and there are no plans to include it. That's not to say Typescript is bad, or even the wrong choice for you – it just means you'll have to make different choices.
The choices made by ez-build are meant to reflect modern web development practices, and in particular practices that are compatible with the Zambezi platform. Ez-build by default targets the ES2015 language specification and modern CSS standards. As these standards progress, so will ez-builds defaults – all the while remaining backward compatible to the extent it is possible. This means that as the future arrives, you will largely benefit without having to change your build process. By eliminating choices, ez-build can make more specific determinations about your project, and build it with up-to-date practices.
By intentionally being a standalone CLI tool, not a plugin to task runners or the likes, ez-build has the benefit of fitting well into almost any environment. Crucially, learning how to use ez-build on typical projects doesn't require learning how to use additional tooling or spending time developing convoluted configurations.
Additionally, ez-build doesn't try to do everything. It doesn't really care about packaging, about deployment, about running tests, or any of the other countless things you may be interested in doing in the context of your project. It isn't a task runner, and doesn't intend to be. Rather, it's singular focus is to take the source code (and assets) of your project, and transform them into output that can be consumed in a run time environment.
Because ez-build makes certain choices and assumptions about the input, it naturally makes assumptions about the output and run time environments as well. These assumptions will change as the landscape of run time capabilities (i.e. browsers get updated and market share changes) changes, but ez-build will go to great lengths to deal with this complexity and focus solely on this purpose: transform source material into runnable output.
Ez-build isn't the build tool for all projects, and all situations. It isn't the tool for esoteric features and fun experiments. It never will be.
But it is the build tool for typical projects, where the requirements are to deliver well built products based on modern and standard web technologies. It is the build tool that codifies solid practices, by using a strong and stable foundation of tools.