diff --git a/site/content/guide/14-module-context.md b/site/content/guide/14-module-context.md
new file mode 100644
index 0000000000..ec311af8e5
--- /dev/null
+++ b/site/content/guide/14-module-context.md
@@ -0,0 +1,66 @@
+---
+title: Module context
+---
+
+So far, our `<script>` tags have been running in the context of a component *instance*. In other words, if you have two components like this...
+
+```html
+<!-- { title: 'Counter' } -->
+<script>
+	import Counter from './Counter.html';
+</script>
+
+<Counter/>
+<Counter/>
+```
+
+```html
+<!--{ filename: 'Counter.html' }-->
+<script>
+	let count = 0;
+</script>
+
+<button on:click="{() => count += 1}">+1</button>
+```
+
+...each counter has its own `count` variable. The code runs once per instance.
+
+Occasionally, you want code to run once *per module* instead. For that, we use `context="module"`:
+
+```html
+<script context="module">
+	console.log(`this will run once`);
+	const answer = 42;
+</script>
+
+<script>
+	console.log(`this will run once per instance`);
+	console.log(`we can 'see' module-level variables like ${answer}`);
+</script>
+```
+
+> Don't worry about manually hoisting functions from instance context to module context to avoid creating multiple copies of them — Svelte will do that for you
+
+
+### Module exports
+
+Any named exports from a `context="module"` script become part of the module's static exports. For example, to define a `preload` function for use with [Sapper](https://sapper.svelte.technology):
+
+```html
+<!-- { title: 'Module exports', repl: false } -->
+<script context="module">
+	export async function preload({ params }) {
+		const res = await this.fetch(`/blog/${params.slug}.json`);
+
+		return {
+			post: await res.json()
+		};
+	}
+</script>
+```
+
+```js
+import BlogPost, { preload } from './BlogPost.html';
+```
+
+You can only have named exports — no `export default` — because the component *is* the default export.
\ No newline at end of file
diff --git a/site/content/guide/14-static-properties.md b/site/content/guide/14-static-properties.md
deleted file mode 100644
index 34a641c23b..0000000000
--- a/site/content/guide/14-static-properties.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title: Static properties
----
-
-
-### Setup
-
-In some situations, you might want to add static properties to your component constructor. For that, we use the `setup` property:
-
-```html
-<!-- { title: 'Component setup' } -->
-<p>check the console!</p>
-
-<script>
-	export default {
-		setup(MyComponent) {
-			// someone importing this component will be able
-			// to access any properties or methods defined here:
-			//
-			//   import MyComponent from './MyComponent.html';
-			//   console.log(MyComponent.ANSWER); // 42
-			MyComponent.ANSWER = 42;
-		},
-
-		oncreate() {
-			console.log('the answer is', this.constructor.ANSWER);
-			console.dir(this.constructor);
-		}
-	};
-</script>
-```
-
-### preload
-
-If your component definition includes a `preload` function, it will be attached to the component constructor as a static method. It doesn't change the behaviour of your component in any way — instead, it's a convention that allows systems like [Sapper](https://sapper.svelte.technology) to delay rendering of a component until its data is ready.
-
-See the section on [preloading](https://sapper.svelte.technology/guide#preloading) in the Sapper docs for more information.
diff --git a/site/content/guide/15-server-side-rendering.md b/site/content/guide/15-server-side-rendering.md
index 690611d385..5789843d2e 100644
--- a/site/content/guide/15-server-side-rendering.md
+++ b/site/content/guide/15-server-side-rendering.md
@@ -21,7 +21,7 @@ const { js } = svelte.compile(source, {
 Alternatively, an easy way to use the server-side renderer is to *register* it:
 
 ```js
-require('svelte/ssr/register');
+require('svelte/register.js');
 ```
 
 Now you can `require` your components:
@@ -33,7 +33,7 @@ const Thing = require('./components/Thing.html');
 If you prefer to use a different file extension, you can pass options like so:
 
 ```js
-require('svelte/ssr/register')({
+require('svelte/register.js')({
 	extensions: ['.svelte']
 });
 ```
@@ -41,39 +41,22 @@ require('svelte/ssr/register')({
 
 ### Server-side API
 
-Components have a different API in Node.js – rather than creating instances with `set(...)` and `get()` methods, a component is an object with a `render(data, options)` method:
+Components have a different API in Node.js – rather than being a constructor that you use with the `new` keyword, a component is an object with a `render(data, options)` method:
 
 ```js
-require('svelte/ssr/register');
+require('svelte/register.js');
 const Thing = require('./components/Thing.html');
 
-const data = { answer: 42 };
-const { html, css, head } = Thing.render(data);
+const props = { answer: 42 };
+const { html, css, head } = Thing.render(props);
 ```
 
-All your [default data](guide#default-data), [computed properties](guide#computed-properties), [helpers](guide#helpers) and [nested components](guide#nested-components) will work as expected.
-
-Any `oncreate` functions or component methods will *not* run — these only apply to client-side components.
+[Lifecycle hooks](guide#lifecycle-hooks) will *not* run, with the exception of `onDestroy`, because the component is never 'mounted'.
 
 > The SSR compiler will generate a CommonJS module for each of your components – meaning that `import` and `export` statements are converted into their `require` and `module.exports` equivalents. If your components have non-component dependencies, they must also work as CommonJS modules in Node. If you're using ES2015 modules, we recommend the [`esm`](https://github.com/standard-things/esm) module for automatically converting them to CommonJS.
 
 
 
-#### Using stores
-
-If your components use [stores](guide#state-management), use the second argument:
-
-```js
-const { Store } = require('svelte/store.umd.js');
-
-const { html } = Thing.render(data, {
-	store: new Store({
-		foo: 'bar'
-	})
-});
-```
-
-
 #### Rendering styles
 
 You can also extract any [scoped styles](guide#scoped-styles) that are used by the component or its children: