Intent, not syntax

One way Sapling achieves its high speed of development is by focusing on accepting intent, not syntax.

Purpose

A common showstopper in developing with any framework or stack you're not 100% familiar with (and this will fluctuate as new versions and features come out), is going away from your IDE to read the documentation or StackOverflow.

Of course, some degree of a learning curve cannot be avoided. But sometimes something that feels like it should work just doesn't because syntax is a bit off. This leads to rabbit holes of endless browser tabs, not to learn how to understand the software, but to figure out how to make the software understand you.

With Sapling, once you've learnt the basic concepts, you should be able to go away and use it without stopping to search for commands or docs. Sapling should "just work", based on what it can infer your intent was; not on whether your syntax was 100% correct.

In practice

There are a number of ways in practice to minimise the number of documentation-induced interruptions for the user. Here's a non-exhaustive list of a few approaches to keep in mind;

1. Case insensitivity - just about everything from routes to methods to variables should be treated case insensitively (unless specifically instructed to be case sensitive).
2. Aliases - the CLI specifically has as many aliases as possible; the user shouldn't have to go find out whether it's sapling create or sapling new - both clearly show the intent of wanting to create a new project, so both should work.
3. Accept anything - Sapling's methods and class constructors should strive to accept whatever input is given to them, and infer what to do with it from the type and number of parameters.