-0088cc.svg){kind=icon}
Not long ago we have entered the era of single-page applications. Some people say that we no longer need a server. They say that JavaScript applications can connect to DBMS directly. Fat clients. We disagree with this. This project is an attempt to solve the problems of modern fat web.
Korolev runs a single-page application on the server side, keeping in the browser only a bridge to receive commands and send events. The page loads instantly and works fast, because it does a minimal amount of computation. It's important that Korolev provides a unified environment for full stack development. Client and server are now combined into a single app without any REST protocol or something else in the middle.
Our project supports static page rendering, so that search engines can index pages and view them immediately.
-
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.
-
Immutable and pure. Really, we don't need mutability even on the frontend. Especially on the frontend. The majority of modern JavaScript frameworks are trying to be functional. And so are we.
-
Rapid development. Efficiency is everything. We are trying to make Korolev bullshit- and boilerplate-free. Hope our words are no bullshit.
Add korolev-server to your build.sbt
libraryDependencies += "com.github.fomkin" %% "korolev-server-blaze" % "0.1.0"Look at examples. It updates very frequently, so we don't paste the code here, sorry guys.
Every session has a State. When an Event happens, you can modify the State with a Transition. Every state renders to pseudo-HTML. The browser receives only a list of changes via WebSocket.
Single source of truth as Redux guys say. The only source of data to render a page. If you have something you want to display, it should be stored in State. Usually it is a sealed trait with several case classes corresponding to rendered screens. State should be immutable.
A function that takes the current State and transforms it into a new State. This is the only way to modify a State.
You can subscribe to client-side DOM events. Event flow is similar to the W3 standard. Event handlers produce Transitions.
All features and changes are registered in the issues. Our first goal is to ship a ready-to-use version with a semi-stable API.