Speed of development

The number one priority of Sapling is speed of development.

Purpose

Sapling was born out of frustration with incumbent frameworks requiring huge amounts of setup and boilerplate code to do even the simplest things. Even if there are good reasons for these frameworks to work that way, spending huge amounts of time doing things The Right Way isn't always the sensible thing to focus on in every project.

Importantly, Sapling doesn't have to be the best framework for every purpose. You would be very right to pick something else for your team of 150 devs to work on your monolithic military grade banking platform.

But by focusing on minimising the setup errands, complex concepts and verbose syntax, Sapling instead shines for projects where just getting it out there is the most sensible priority:

• MVPs
• Prototypes
• Proofs of concept
• Hackathons
• Challenges
• Side projects
• Weekend hacks
• Test environments

In practice

To this end, any proposed changes or features that improve the speed of development are given high priority. Speed of development will (almost) always win over considerations like performance, scalability, security in non-production environments, or number of dependencies.

Similarly, changes or features that make the end user's development slower or more complicated will basically have to be absolute magic to be even considered.

Speed of development can come from many places; big improvements come from reducing boilerplate, but there are many smaller and more subtle ways too, such as accepting intent.

Of course, there's not much point in developing something as fast as possible if the end result is unusable, so in production mode, Sapling must still have decent performance, and be secure. It's a balancing act to be sure, as even when writing in production or strict mode (and thus many time-saving features disabled), Sapling should be more rapid than alternatives.