Added ez-build rationale, explaining why it exists

[mstade]

Some of the topics we try to tackle in this:

• What is it? What is it not?
• Why another build tool?
• Why not a task runner?
• Compare to GCC, clang; other compiler collections
• Lean on sensible defaults
• Reasonable flexibility; why some things are configurable, and some things aren't
• Enable modern technology with little effort
• Codifying processes and practices
• Standalone; not a grunt/gulp/whatever random plugin
• Future compatible; e.g. hides away module loader dependency
• Responsibility: turn source into runnable stuff

The key values we're touching on here are:

• Eliminating choice
• Increasing focus and productivity
• Reducing anxiety

[mstade]

Relevant/inspirational links:

Javascript Fatigue. In particular this quote is resonant with ez-build:

The Javascript pendulum has swung from restrictive, monolithic frameworks to modular, boilerplate-hindered libraries. Soon enough, I’m confident it will settle in the middle between rapid development and customization.

[FabienDeshayes]

Great narrative as usual Marcus. I will have to read again to get into the details but overall it really highlights the key points:

• set of codified standards / practices
• reasonable flexibility
• build for the future

I think it might be worth emphasizing more on 2 things:

• It is "easy" to use. Out of the box it does cover a large number of use cases for projects out there, and give enough flexibility to cover the rest of the use cases (or most of them)
• Do something small, do it well. It doesn't care about packaging, testing, etc. Just the transformation of code from source to an output that can be consumed in a production environment.

[FabienDeshayes]

Second read: this is definitely good stuff. Nothing to add.

[mstade]

@FabienDeshayes wrote:

• Do something small, do it well. It doesn't care about packaging, testing, etc. Just the transformation of code from source to an output that can be consumed in a production environment.

This really resonates with me and I think you're absolute right – we should emphasize this in the doc because it's an important point that people will undoubtedly miss otherwise. Just yesterday I was asked how to use ez-build to run tests, and it just misses the mark of ez-build's scope so profoundly that I think it is definitely worth pulling in a section about this.

[FabienDeshayes]

On that note - we should think about an ez-test tool as well? This will be trickier I feel.

[mstade]

What would such a tool do, that tape or others don't already?

[FabienDeshayes]

well that's why I say it's trickier. People will want to use so many different things that are not always compatible that it will be hard to figure out a set of best practices for them. But i was thinking something more in the line of a tool that provides you a runner, an assertion lib, coverage tool, and two modes to run (watch and ci). You can then potentially swap in/out the assertion lib, in fact do whatever you want.

But even if we recommend the "do i yourself" approach, it should be documented as we're going to be asked that question a lot.

[mstade]

I fear we'd be running into creating a standard to compete with standards if we tried that, and to little gain to be honest. The main issue with testing in an ES2015 world, to be honest, is how to compile your tests on the fly – this is why I implemented preloading modules in tape, so you could do JIT compilation, add source map support etc. The test target should always be whatever is in your lib, because you'll want to test the actual deployed output, not the source.

The tool that you want may be such a preloading module, that you could then use with mocha, tape, whatever runner that could preload a module before running any tests, to hook into node's require function etc. Browser tests are a different beast altogether.. I dunno, I think we'd do better in focusing on educating people on how to test resources and such, rather than giving them another tool.

[FabienDeshayes]

Happy to get this merged.

[mstade]

@zambezi/ui I'll merge this today unless anyone has any issues with it.

[FabienDeshayes]

Merging it now.