-
Notifications
You must be signed in to change notification settings - Fork 21
If the library works differently in the browser and server (Marko, React, Svelte, etc)
then you will want to use a prebuilt Rill Middleware. These are relatively simple in most cases and actually consist of two Rill middleware. One of these is for the server implentation and the other for the browser.
Typically these are located in the server
and browser
folders respectively. Check out @rill/react for an example of how this is done.
If you are using an html only view engine such as Pug or Handlebars then you will want to use @rill/html which will perform a DOM diffing algorithm in the browser for optimum performance. Typically you will also want to bind event listeners in the browser specifically to the active page. A good tool for this is @rill/delegate which automatically clears any registered handlers when navigating.
The original plan for Rill was to work very similar to koa-client. In fact today there are some similar tools such as frontexpress and browser-server.
I ultimately decided that this was the wrong direction for a few reasons.
- It is unclear if a package or middleware would work in the browser.
- With Rill you are guaranteed that every official Rill middleware will operate in either context.
- Almost every popular middleware from express or koa has been ported to work this way. If you find one that's missing it is usually trivial to port yourself, or feel free to raise an issue.
- Many server api's substantially increase the browser bundle size.
- Modules like
mime-types
(19.9kb) and others quickly increase the size of your client side app. - With Rill you are free to use these server only tools, but you should ensure they do not get included in the browser by using a
process.browser
check or the package.json's browser field. - Every Rill module, and every dependency is optimized for file size in the browser.
- Modules like
- Rill is promise based instead of generator based.
- When Rill was created there was only talk of switching Koa to use promises.
- Although Rill and koa2 share a similar API now, Rill has actually had a promise based API since early 2015.
Ultimately the choice is yours and thankfully there are many options out there! However I personally recommend Rill for a few reasons:
- Single API. No need to learn multiple routers to get something done.
- Framework agnostic. Your routes aren't tied up in some
<RouteProviderAbstraction>
specific to a framework and it's easy(er) to switch out your view library entirely. - Server side actions. Rill handles both GET and POST requests isomorphically. This means you can have a much faster time to interactive since a user submitting a form will hit your server if the JS is still loading, has failed, or is otherwise not running on the page. This is great for supporting older browsers as the bulk of your functionality can be progressively enhanced.
The best way to get help with Rill is to ask in the gitter or raise an issue on GitHub.