config.noProductionJS to turn off bundle.js build, readme updates

[scottnonnenberg]

A bit of a refactor to utils/build.js to better enable this change - each step was split out into its own, separate function.

Note that this change also ensures that Done callback is always called. Without a user-provided post-build, the callback was never called. Realized that I was never getting that 'Done' console log after my
builds.

Also some readme updates to capture what I've learned from inspecting the source. And match the latest API. :0)

[KyleAMathews]

Woah nice! A documentation PR!! :D this looks great on my phone. I'll review it more throughly later and probably cut a new release.

[KyleAMathews]

Can you tell me more about your use case for not wanting to include a bundle.js?

I can see there's valid reasons for not wanting a bundle.js but it does have downsides e.g. lose no-refresh page transitions + it breaks expectations of react.js devs as their components aren't going to work as expected upon building.

[scottnonnenberg]

For my blog, here are the numbers:

• 218kb bundle.js, gzipped
• 8-14kb per-page, gzipped
• a little over two page views per user session, per analytics

So the average user has to download about 230kb (not including images) to view two pages on my blog. Without the SPA, they would have had to download only 30kb. So I turned bundle.js off. It's still great for development, hot-reloading, all that. But for production it's not so great. Especially since bundle.js will only get bigger as I add more posts.

This will also be useful for people trying to use gatsby for really big sites. Until code-splitting is in place, this will be their release valve. Your experiment with 5000 articles and a 2.2mb gzipped bundle.js was a great test, but that size javascript file is totally unreasonable.

Note that the way it's implemented it will default to generating bundle.js, if the spa option is unspecified.

What do you mean by "components aren't going to work as expected upon building?"

[KyleAMathews]

I agree this is an interesting/valuable option as it basically let's you treat React.js solely as the templating language.

re "components aren't going to work as expected" — I mean if someone creates a page that's a react.js component or adds any sort of JS driven interactivity to a markdown page, it won't work w/o the bundle.js.

How's this sound? Instead of the option being spa, make it noJavascript to make it clearer that by setting that true, there'll be no Javascript loaded when the site is deployed?

[scottnonnenberg]

Yep, that's definitely more clear. Maybe even noProductionJavascript since we shouldn't be afraid of long names? :0)

[KyleAMathews]

I like it :) (and hearted it and +1ed it!)

[KyleAMathews]

Oh btw, I already cherry-picked your first commit here to fix the README js code :-)

[scottnonnenberg]

Rename complete - lemme know if you'd like any more tweaks!

Yep, noticed the cherry-pick. :0)

[KyleAMathews]

Awesome!