update some

Author: jonathanong

about/comparisons.md

@@ -1,61 +1,40 @@
 
-### Bundling vs. Browserify vs. Webpack
-
-`nlz build(1)` is pretty similar to Browserify.
-How does the bundling compare?
-Let's compare the created bundles for [dom-elements](https://github.com/barberboy/dom-elements).
-We'll do basic builds, minification, and compression.
-You can view the [Makefile](https://github.com/normalize/comparisons/blob/master/Makefile).
-
-| Build       | Normalize | Browserify | Webpack    |
-|-------------|-----------|------------|------------|
-| .js         | 9,663b    | 6,717b     | 7,939b     |
-| .min.js     | 4,632b    | 3,486b     | 2,585b     |
-| .min.js.gz  | 1,252b    | 1,346b     | 1,060b     |
-
-What you'll see is that Normalize's JS builds are larger than Browserify's.
-This is due to a couple of reasons:
-
-1. Normalize doesn't automatically minimize the `require()` implementation.
-  Doing so unnecessarily hides the magic from developers.
-2. Normalize doesn't wrap the build within a closure.
-  Developers can do that themselves.
-  This allows developers to `require('./index.js')` outside the build.
-3. Normalize dependency names are generally longer to keep them unique.
-4. Normalize adds comments to each file for debugging.
-
-But then you'll notice that Normalize's gzip build is actually smaller than browserify's.
-In the end, the gzip size is all that matters.
-This is primarily due to two reasons:
-
-1. Absolute URLs are mostly redundant and very compressible.
-2. The `require()` implementation is minimal and is basically just a hash lookup.
-
-But why is Webpack superior than both Normalize and Browserify?
-If you look at the Webpack bundle, you'll notice two things:
-
-1. Module IDs are rewritten into numbers (stored in an array)
-2. All modules are loaded in an array
-
-Normalize won't ever do 1) because this will make modules difficult to use outside the bundle
-as well as make the resulting bundle more difficult to read.
-`require()` is global by default so developers can `require()` outside the build.
-The bundle will be smaller if wrapped in a closure.
-
-Normalize may eventually do 2) only if supported by ES6 module loaders,
-but until then, it's easier if each module is disjoint from the other.
-
-### vs. jspm.io and family
-
-A similar project is [jspm.io](http://jspm.io).
-Some key differences are:
-
-- There are no required special syntaxes. URLs are just URLs.
-  Special syntaxes are optional and require the developer to create their own custom
-  ES6 module loader on the client.
-- Normalize is not client-side heavy and does not necessitate the use of polyfills.
-  Normalize bundling overhead is minimal.
-- Normalize treats non-js assets as first-class citizens.
-- Normalize does not have its own registry.
-- Normalize has the ability to proxy from arbitrary remotes.
-- Normalize treats dynamic imports as second class citizens.
+Normalize's philosophy drastically differs from most client-side tools today, both ES6 and pre-ES6.
+Perhaps the biggest difference is that Normalize aims to solve __almost everything__
+about frontend web development, whereas most tools aim to solve a particular aspect of frontend development.
+
+The two major ES6 client-side tools I know of are [jspm.io](http://jspm.io) and [stealjs](http://stealjs.com/docs/index.html).
+Normalize differs in that:
+
+- Unlike jspm.io, Normalize never advocates using `System` and instead only advocates using `import`s and `export`s.
+  Using `System`, which is async, is not much of an improvement over AMD.
+- Unlike both, Normalize avoids any client-side complexities and overhead with runtimes such as [ES6 module loader](https://github.com/ModuleLoader/es6-module-loader),
+  making it more suitable for production usage.
+- Normalize aims to rid the frontend development workflow from install and build steps.
+  StealJS requires you to download packages from Bower as well as setup your own Grunt build process.
+
+Normalize is more similar to Component except it automatically infers the manifest and dependency tree
+via static analysis. With CommonJS, this was more difficult as `require()`s are just functions and
+not precisely static. Also like both Component and Bower, Normalize supports CSS and HTML as first class citizens.
+
+Other bundlers such as Browserify and Webpack are focused on JS and require other assets
+to be loaded via JS. This is more suitable for JS-heavy sites such as games,
+but is not suitable for design-heavy apps.
+
+A feature of many bundlers such as browserify and webpack are the ability to create multiple bundles.
+However, Normalize does not and will not bother with such features as they are irrelevant with SPDY.
+If the client doesn't need a particular file, then it won't request it, or it will cancel the SPDY push stream.
+
+As Normalize aims to rid your workflow of custom build processes,
+there must be some cases where Normalize fails to meet your app's needs.
+In particular, anything that requires concatenation won't be suitable for Normalize.
+This includes:
+
+- Any build task that are many-to-one such as concatenation (CSS preprocessors) or combining (creating sprite sheets).
+  CSS preprocessors such as SASS and LESS that depend on "global" features such as variables, mixins, and inheritance,
+  which requires concatenation.
+  Variables can be replaced by CSS variables, but mixins and inheritance can not be replaced with vanilla CSS.
+  Instead, point Normalize to the "final" output instead of the source files.
+- AMD environments as Normalize will not attempt to support such modules.
+- Locale support, particularly translations and RTL. We intend to support these, but we're not
+  sure what the best course of action is, so if your company needs these now, you might want to wait on Normalize.

about/faq.md

@@ -1,36 +1,17 @@
 
-### How will you make money?
-
-Currently, Normalize.IO is being developed as a build process for my own app.
-Thus, only features I use will be actively developed by my own free will.
-
-For long term support, you should [gittip me](https://www.gittip.com/jonathanong/) as hosting costs are at least $100 a year,
-half of which is just the domain name.
-If tipped, I'll be inclined to work on features I don't use.
-
-For business and enterprise features,
-you'll probably want to set a bounties via [bountysource](https://www.bountysource.com/) or contact me directly for paid support.
-All my code is open source, so I personally don't have a need for these types of features, but I believe these are eventually necessary.
-
-If Normalize.IO takes off, I'd like to create a "proxy as a service" much like nodejitsu's private npm servers,
-but I wouldn't want to do it myself since I have no interest in dev ops.
-
-I'm particularly interested in corporate sponsorships,
-particularly the first CDN that could provide SPDY Push support.
-
 ### Will Normalize.IO support node.js?
 
-Hopefully, node.js will eventually support https://nlz.io without a client with ES6 modules.
-But supporting node.js with a command line interface is difficult as there are many obstacles to overcome.
-Basically, forking node would be required to make it work gracefully, which is in the realm of possibility.
+Normalize.IO is specifically tailored for frontend development.
+In particular, node modules are refactored to work for the browser,
+sacrificing node compatibility in the process.
 
-To keep yourself up to date with node.js support,
-follow the [node-normalize](https://github.com/normalize/node-normalize) repository.
+Instead, we weill most likely make a similar tool for node.js,
+but it may not be the same name or in the same utility.
 
-### Can I omit `https://` from the URLs?
+### Can I omit `http:` or `https://` from the URLs?
 
 If browsers support protocol-less URLs, then so will we.
 However, there are a couple potential issues with omitting protocols.
 
 1. It's more difficult to differentiate between URLs and local/relative assets.
-2. Some browsers plan to not support non-SSL SPDY, so this might even work in development.
+2. Some browsers plan to not support non-SSL SPDY, so this might not even work in development.

about/index.jade

@@ -14,10 +14,6 @@ block main
     h2(id='philosophy') Philosophy
     include:markdown philosophy.md
 
-  section: .container
-    h2(id='production-checklist') Production Checklist
-    include:markdown production.md
-
   section: .container
     h2(id='comparisons') Comparisons
     include:markdown comparisons.md