README.md in vitrine-0.0.21 vs README.md in vitrine-0.0.22

@@ -1,11 +1,23 @@
 A nimble web server one-liner for modern web-apps, a bit in the style of
 [lineman](https://github.com/testdouble/lineman), [middleman](https://github.com/middleman/middleman), [serve](https://github.com/visionmedia/serve), another [serve](https://github.com/jlong/serve) 
 and such. Will display your precious stuff on port 9292.
 
-It does some of what those other projects - only the stuff I need, with less.
+It does some of what those other projects - only the stuff I need, with less. And *with* the stuff that I
+consider essential that still isn't supported where it should be supported. You can see Vitrine as 
+reinventing the wheel for sure, but the reason I wrote it is that I found the other development servers
+giving me death by a thousand paper cuts. Just that really:
 
+For example, `serve` which I loved dearly compiles `.coffee` files to JS with their native extension and
+does not do source maps. It also depends on Compass, so you probably won't be able to put in the newer
+version of SASS required for source maps. Sprockets does not do source maps either. The CoffeeScript
+gem does not propagate the syntax error line to your browser console, so it's notoriously difficult
+to find out where the errors are - because someone refused to accept a PR to the CoffeeScript gem -
+and these small irritating things just go on and on and on. In the meantime, I wanted a comfortable
+dev environment, without resorting to filesystem watching and rebuilding all my assets every time I change
+a character. So there: Vitrine.
+
 ## Core idea of Vitrine
 
 You want a server that will automatically wrap your CoffeeScript and SASS assets, and allow
 some rudimentary templating. This is practically enough for putting together MVP prototypes,
 especially as far as single-page apps go. You want this server to not coerce you into a specific
@@ -16,29 +28,47 @@
 If most of the above is true, Vitrine is just what you need.
 
 ## All you need is some `public`
 
 Vitrine assumes that there are two directories under the current tree:
+
 * `public` - for the JS, for CSS and SCSS and in general all the static files served straight out
 * `views` - for the templates, in any Ruby templating format you have
 
+This structure fits my preferred stack (Sinatra + Passenger) perfectly and allows running sane
+defaults. It is also migratable to another stack with minimum effort, while still having things
+like asset passthrough via Passenger work out of the box.
+
 ## Automatic compilation
 
 Vitrine is for **development**. It takes runtime compilation to 11 and beyound. Running tasks
 is all fine and good when you build out the app for production, but when iterating on UI it's essential
-to be able to just yank the file in there and carry on. THe compilation perks include:
+to be able to just yank the file in there and carry on. Compilation perks include:
 
 * Any `.scss` file you shove into the `public` directory can be referenced as `.css` from your HTML.
   Ask for `foo.css` and `foo.scss` will be compiled on the fly.
 * Any `.coffee` file you shove into the `public` directory can be references as `.js` from your HTML.
   Ask for `bar.js` and `bar.coffee` will be compiled on the fly.
-* CoffeeScript files will have source-maps out of the box for pleasant browser debugging.
-* Decent error messages will be shown for both invalid SCSS and invalid CoffeeScript.
+* CoffeeScript and SCSS files will have sourcemaps out of the box for pleasant browser debugging 
+  (something Sprockets still cannot do properly)
+* Decent error messages will be shown for both invalid SCSS and invalid CoffeeScript, including
+proper line reference for syntax errors (something Sprockets still cannot do properly)
 
+Vitrine favors **runtime assembly** for JavaScript and CSS. That is: load many files into your page
+in development mode, and build them into one chunk using external tools on deployment only.
+
+This helps accelerating the roundtrip time because if you use asset compilation on every reload
+when designing the UI you can easily get into the compile-concat-minify roundtrip times of more
+than a few seconds. This is too much.
+
+You are totally free to use your own compile-concat-minify pipelines when building for production.
+Unlike Sprockets Vitrine does not force you to inject any specific preprocessor directives into
+your scripts or CSS - this also facilitates debugging a GREAT LOT.
+
 ## Asset caching
 
 Succesfully compiled assets will be ETagged based on their mtime. You should run an HTTP caching
-proxy on top of a Vitrine app in production.
+proxy on top of Vitrine if you use it in production.
 
 ## Automatic Ruby template pickup
 
 If you have the "views" directory available, Vitrine will try to pick up any usable file for any URL without extensions.
 From there on, it's going to try to render it with the automatically picked template engine using the