anchor.diff:  
   === Stateful components
   
  -In the world of front-end development people often name every thing that has HTML-like markup a "component". Until version 0.6, Korolev didn't have components support (except WebComponents on a client side). When we say "component" we mean something that has its own state. In Korolev case, components also dispatch events to other components up in the hierarchy or to the application on the top.
  +In the world of front-end development people often call every thing that has HTML-like markup a "component". Until version 0.6, Korolev didn't have components support (except WebComponents on client side). When we say "component" we mean something that has its own state. In Korolev case, components also dispatch events to other components up in the hierarchy or to the application on the top.
   
   Worth to note that application is a component too, so you can consider Korolev's components system as a system composed of applications. Korolev components are not lightweight, so if you can implement a feature without components, do it so. Use components only when they are really necessary.
   
  
positive.code: 
  === Principles
  
  1. Thin client. Let's be honest, modern JavaScript applications are too greedy. Every JavaScript developer thinks that his page is special. But the user has a different opinion. He opens dozens of tabs. Each tab contains a ton of code, and this works very slowly. So we make our JavaScript bridge as lightweight as possible.
  
  2. Immutable and pure. Really, we don't need mutability even on the frontend. Especially on the frontend. The majority of modern JavaScript frameworks try to be functional. So we do.
  
  3. Lack of dependencies. Korolev does not impose to use cats, scalaz, Akka, or futures from the standard library. Use what you want. Korolev tries to give a way to integrate itself into any environment.
  
  === Quick start
  
  
negative.code: re-start --- -Dkorolev.dev=true
  -------------------------------------------------------------------------------
  
  Make a change to your app source code and save the file. Switch to the browser and wait for changes to deliver.
  
  Notice that developer mode does not work with custom `StateStorage`.
  
  [NOTE]
  ============
  Ensure that everything is stateless except Korolev part of the application. For example, if you keep some state outside of Korolev state, it won't be saved and will lead to inconsistency.
  ============
  
  === Serve files from resource directory
  
  Everything placed in directory named `static` (in the classpath of the application) will be served from the root of the application endpoint. It may be useful when you want to distribute some small images or CSS with the app.
  
  [WARNING]
  ============
  Korolev is not some sort of CDN node. Avoid serving lots of large files using this feature.
  ============
  
  == Integrations
  
  === JCache
  
  For large applications, when one node can't serve all clients, you need a way to scale application to multiple nodes. Although Korolev usually use persistent connections, a case when a client connects to a wrong node is possible. First, it may happen after reconnect. Secondly, it may happen when the client downgrades his connection from WebSocket to long polling for some reason. It means that every node in a cluster should have access to all user states (sessions).
  
  To fix this, you can apply any in-memory storage compatible with https://github.com/jsr107/jsr107spec[JCache]. Just add a dependency to your SBT configuration.
  
  