Out of the box, be useful without any tooling.

[addyosmani]

For 0.6.0, I feel users should be able to get started within 30s of downloading us. This means:

• The boilerplate will work for basic use-cases without needing any tools at all
• We'll ship pre-minified CSS and JS for our new component library. The boilerplate will reference them and you won't need to use tools to generate em.
• We'll offer a new browser-based customisation tool letting you theme the components without needing tools at all.
• If you absolutely do not want to use tooling, we'll give you an easy way to optimise your assets online using PageSpeed's new images/CSS/JS online optimiser tool.
• Sass will be available, but as with other tooling, you'll need to npm install to get it working. However, this won't gate you on building a site with WSK.

In short, I think we need to shift our priority to the non-tooling use case (Bootstrap does this exceptionally well) and nail the first-run experience for everyone :)

More context

The typical life-cycle for new users is that they must install and use the tooling before they can get started with WSK. This was a decision we intentionally made around 0.5.0, but imo it was a poor call given we're targeting the long tail.

Based on experience in the field, requiring tooling installation is resulting in a large number of users getting stuck debugging issues with npm dependencies for ~60m before getting it right (literally getting emails everyday about this).

I wish I could say this was just beginners, but several users who are comfortable using npm for JS-only projects have also been reporting issues w/setup including:

• node-sass exceptions on their platform of choice (some tackled by the V3 alpha). This means they can't even 'serve' to get started.
• Can't build/serve as imageoptim fails them on Linux. They end up having to switch to older binaries and lots of getting in the weeds.
• npm versioning - I've had to tell many to use npm@next rather than stable for reasons too long to go into here.

[addyosmani]

cc @google/web-starter-kit in case I'm way off base here.

[PaulKinlan]

This. Thank you!

On Sat, 21 Mar 2015 17:24 Addy Osmani [email protected] wrote:

The typical life-cycle for new users is that they must install and use the
tooling before they can get started with WSK. This was a decision we
intentionally made around 0.5.0, but imo it was a poor call given we're
targeting the long tail.

Based on experience in the field, requiring tooling installation is
resulting in a large number of users getting stuck debugging issues with
npm dependencies for ~60m before getting it right (literally getting emails
everyday about this).

I wish I could say this was just beginners, but several users who are
comfortable using npm for JS-only projects have also been reporting issues
w/setup including:

• node-sass exceptions on their platform of choice (some tackled by
  the V3 alpha). This means they can't even 'serve' to get started.
• Can't build/serve as imageoptim fails them on Linux. They end up
  having to switch to older binaries and lots of getting in the weeds.
• npm versioning - I've had to tell many to use npm@next rather than
  stable for reasons too long to go into here.

For 0.6.0, WSK users should be able to get started within 30s of
downloading the kit. This means:

• The boilerplate will work for basic use-cases without needing any
  tools at all
• We'll ship pre-minified CSS and JS for our new component library.
  The boilerplate will reference them and you won't need to use tools to
  generate em.
• We'll offer a new browser-based customisation tool letting you theme
  the components without needing tools at all.
• If you absolutely do not want to use tooling, we'll give you an easy
  way to optimise your assets online using PageSpeed's new images/CSS/JS
  online optimiser tool.
• Sass will be available, but as with other tooling, you'll need to npm
  install to get it working. However, this won't gate you on building a
  site with WSK.

In short, I think we need to shift our priority to the non-tooling use
case (Bootstrap does this exceptionally well) and nail the first-run
experience for everyone.

—
Reply to this email directly or view it on GitHub
#660.

[edwardbeckett]

+1 for OOB Support ... Having a default build is a great way to support those who want to get up and running with a vanilla WSK install. Moreover, after installing and downloading all the node_modules a vanilla project is over 135MB. That's enormously high just for build dependencies.

Though off-topic, in comparison, the Spring Team launched Spring Boot to address this very concern and realized a huge increase at the entry-level adoption rate...

[robdodson]

+1

[awayken]

👍

[paulirish]

I'm on board but I also think you can end up overcorrecting.

We don't want to lose these users to the old ways completely, so lets be mindful of how we can slowly and iteratively evolve their setup to introduce tools when possible. Using the online PSI optimizer tool is a good example, and I wonder where else we can have lure users with this sorta feeling: "Getting tired doing ____ each and every time? Try out ___".

I'm not sure how that manifests but we should consider how to onramp them after they've already missed the exit. :)

[sindresorhus]

I wish I could 👎 this, but it's very true.

The main problem is broken tools and broken systems. npm has been unstable as long as I can remember and with all the promise of the new versions I still keep getting more and more issues on my repos about npm install problems. Node-sass breaks a lot, both for being a native dependency (so if prebuilt binaries aren't available it requires compiling and the required tools for doing so), and for being buggy. When new Node/io versions comes out there's a good chance they'll need to create new pre-built node-sass binaries for all the platforms, this takes time, which makes it break for early adopters. Imagemin also requires compiling if the pre-built binaries doesn't work, which happens a lot on Linux where it's close to impossible to make an universally usable pre-compiled binary. That's the main reason for it failing. But the biggest problem tbh is user systems. Most users never upgrade anything, leaving them with old and buggy npm (and node) versions which constantly corrupts the cache and the installed modules. There's also the fact that a lot of users have broken their systems by having screwed up their permissions.

This creates a bad experience for both the developer and the users. No clear path to resolve this though...

[stevemao]

👍 Maybe we could split this one into two. One is vanilla and the other is with tooling and using the vanilla as template.

[erwinmombay]

👍 especially for people "testing" wsk. better first impression overall

[addyosmani]

As of master, you can now just cd into the app directory and run any server to preview the local version of WSK without any tooling.