Christopher Chedeau posted an interesting challenge yesterday. A few insightul follow-ups have since made the rounds. The crux of the discussion is that for all of the increasing sophistication and modularity of web app tooling these days, it's become increasingly cumbersome to get started with a simple prototyping project.
I've personally felt this pain on more than one occasion. Excited to try out a new idea, I bring up my text editor only to realize that I can't remember how to configure webpack. Or Babel 6 changed a bunch of things that I haven't learned yet, but a library I want to use depends on it. And on and on. These tooling-related roadblocks can quickly kill the enthusiasm for an idea.
The discussion around this issue started by considering the experience of beginners, but soon many more experienced developers voiced their frustrations with the current state of webapp tooling. Clearly, both groups of developers are struggling with this, but their needs are dramatically different.
Beginners
For those new to web development, we really need to keep the number of suggested tools and technologies to a minimum. That means no Babel, no JSX, no Webpack, no Flux/Redux. Before you use these tools you need to understand them. And before you can understand them, you have to experience the pain points they exist to solve.
A single html file with inline CSS and JS is a great starting point for a beginner. They can save it locally, instantly use any text editor or environment that they are comfortable with, and easily publish with something like Surge.
Of course, using a single html file goes against several web development best practices, but that is completely irrelevant for a beginner. The emphasis should be on facilitating learning, not conforming to every best practice out of the gate.
Advanced
For more seasoned developers, part of the problem is the tooling we use (webpack, babel, etc), once experienced, provide ergonomics that are hard to do without. I never want to start a project without hot reloading again. It's also increasingly annoying to eschew ES6 features or write CSS without a preprocessor. If you use JSX, there's another thing that imposes a build step on your project. These luxuries trap us in increasingly intricate tooling setups, yet for all but the most trivial prototypes, I think they provide a net benefit over the lifetime of a project.
It seems people often suggest boilerplates as a solution to the problem. If someone has already gone to the trouble of setting up all these components together, why not just pull that in and build on top? Indeed, boilerplates seem to be growing in popularity and (even more so) in number. However, once you need to deviate from the boilerplate's built-in conventions, you need to descend into its constituent tools, sometimes learning them from scratch.
If you're a web developer by trade, I think a build-your-own-boilerplate approach makes the most sense. Instead of cargo-culting someone else's boilerplate project, take the time to learn your tools thoroughly, set up a boilerplate that you can quickly clone and extend, and use that for your projects.
With one command your boilerplate should ideally:
- Create a git/hg/whatever repository with an initial commit
- Create a Readme with your project name
- Setup a
package.json(or the equivalent for your ecosystem of choice) - Install all of your dependencies
- Start a development server, if applicable
- Open the browser so you can see some
Hello worldoutput right away
In theory, setting this up should be a one-time cost, paying interest every time you start a new project. In practice, however, our tools change rapidly and there will always be temptations to add new libraries and upgrade to the latest and greatest. Resist! You should really only need to update your boilerplate a few times a year.