Why another boilerplate?

[stevemao]

Hi Guys, so I really enjoy using Yeoman and Treehouse brought me here. So my question is, why another boilerplate? In the readme it says this project is inspired by Mobile HTML5 Boilerplate and Yeoman's generator-gulp-webapp. So why not just improve the generators or add more options to them? Also in the FAQ, it says "it's hard to find a generator with a great mobile baseline.", and I thought generator-mobile is supposed to do the job? Btw this project looks really good and I appreciate your hard work. Thanks.

[moettinger]

Not really sure this counts as an "issue" - more of an observation or opinion.

That said, I would argue that there can never be too many boilerplates just as there can never be too many tools for web development. There are an infinite number of projects that devs create on a daily basis and they are all different in their own ways. There could be 100 boilerplates and I'm confident that there is a dev out there to could find a use for each.

[addyosmani]

Looking over the past two and a bit years, what we achieved with Yeoman was 1) defining a scaffolding tool for modern workflows and 2) an ecosystem that folks could build on for creating new projects. Yeoman works well for those used to tooling who more or less know what they want to use.

Unfortunately, one of the challenges with it is almost no-one is focused on two really important areas: the mobile experience and performance.

Problem 1: Mobile.

Most Yeoman generators don't prescribe sane mobile defaults for things like meta viewports and configurations specific to popular mobile devices today. This was because we were never able to bake in a way to 'propagate' a better mobile boilerplate to all the generators until very late on and even then, it wasn't very practical because each generator has a different index that gets scaffolded.

I spoke with the maintainers of Mobile HTML5Boilerplate before we started this project and they agreed that they were having a hard time maintaining it, and keeping it up to date with modern practices (including the addition of workflow tooling). Our boilerplate is constantly reviewed by folks at Google who are defining best practices for our engineers when it comes to mobile and we want to make sure the community has something similar.

Why not generator-mobile? Matt Gaunt and I started that project as a proof of concept. It was useful, but failed somewhat as we basically gave developers options for every possible path. Most people just find that confusing and want to be handed an opinionated solution that just makes the decisions for them. We're aiming at the 90% of folks here rather than the well informed 10%.

Problem 2: Performance

Few generators actually keep performance in mind. Some, like those we've authored (I and Sindre started generator-gulp-webapp, our team created generator-webapp, generator-angular etc) do have support for build-time optimization but they don't do nearly enough.

One example: most generators will give you Twitter Bootstrap off the bat with little to no concern for the fact that most people will use less than 90% of what is there. They won't use tools like UnCSS to get rid of that bloat in their pages, leaving them with something that's still fat and will slow their users down on mobile. Our boilerplate tackles that.

Not only that, but we define baseline styles and responsive boilerplate that doesn't require you to buy in to a CSS library. We actually encourage folks to customize our styles and style guide as in any agency you're more likely to be doing that anyway.

Most generators don't include performance reporting or benchmarking in there. We do. We give you PageSpeed Insights reporting setup so you can easily run a single command to see how well you're doing on mobile and we wrote a module just to help with that: https://github.com/addyosmani/psi.

Problem 3: Cross-device development

Most generators today will give you some form of live-reload support. It's expected at this point. We give you live-reload with cross-device syncronization through BrowserSync, meaning that you sync scrolls, slicks, navigation and so on. Some generators will include BrowserSync but our team actually actively work on seeing how we can make those integration points even smoother. We recently added TLS support to BrowserSync. We're going to keep seeing how we can improve it.

Other problems:

• Most generators and boilerplates don't include a style guide, we do.
• Most generators/boilerplates don't try to reflect the best practices Google's 'make the web faster' team suggest. We actively try to. We want our boilerplate to give you the best possible performance scores out of the box so that you're not starting off trying to figure out how to improve an already poor score.

So, I think we have a few good reasons to exist. At least, I hope :)

[Garbee]

@addyosmani Let's also not forget that most tools assume the developer already knows exactly how to use/implement them. Since this Starter Kit is tied directly into an introduction course for new developers. This means the course can be consistent and doesn't need to be updated due to another repo manager deciding to change something dramatic out of left field.

People should take what they learn from the starter kit and then apply that within their own yeoman generators (or project scaffolding of choice.)

Maybe from this issue we should make a wiki entry (since Addy just posted a fantastic document) and have that as a place to reference this question in the future. The FAQ page already answers it in direct relation to H5BP and Yeoman.

[addyosmani]

Thanks @Garbee. I'll get this added to the wiki and we can improve it as needed as time goes on :)

[tonyjessup]

WSK is very much needed imo. I am super interested to see how the opinions of these talented folks plays out. So far I love decisions like gulp, flexbox, sass, mobile first, modulars/components and the forth-coming material design integrations. I think Googles experience creating the best browser, most popular mobile platform and search engine will only contribute to moving the web forward with this contribution to open source.

There has been and will be many tools and frameworks which have created newcomer and veteran front-end fatigue and confusion. But that's why it's important to evolve and make something that is opinionated enough to inform new about best patterns and flexible enough for the experienced to build on.

I really respect Twitter/@mdo and Zurb but this project has the clout and talent to make it.

[Garbee]

I don't really see this taking on Bootstrap/Foundation directly. While it could include a lot of common things they do, it is also more involved in the amount of developer work required to get a full site up. Plus, other frameworks will always have a good place for just cranking stuff out quickly and improving the design later.

[tonyjessup]

I didn't mean to imply it would replace bootstrap/foundation anytime soon, but who knows what wsk will look like 9k commits later. I think it would be great to learn material design patterns feel at home using wsk, angular, android sdk, polymer etc.

[bluematter]

What's the point of baking in page speed when I can just go here http://developers.google.com/speed/pagespeed/insights/ I am liking this project very much, mainly for the performance.

[stevemao]

Thanks guys, really appreciate that.

[addyosmani]

Added to https://github.com/google/web-starter-kit/wiki/Why-another-boilerplate%3F