Slinky helps you write rich web applications using compiled web languages like SASS, HAML and CoffeeScript. The slinky server transparently compiles resources as they're requested, leaving you to worry about your code, not how to compile it. It will even proxy AJAX requests to a backend server so you can easily develop against REST APIs.
$ gem install slinky $ cd ~/my/awesome/project $ slinky start [hardcore web development action] $ slinky build $ scp -r build/ myserver.com/var/www/project
Slinky currently supports three languages for compilation, SASS/SCSS, HAML and CoffeeScript, but it's simple to add support for others (and please submit a pull request when you do!). Slinky also has a few tricks of its own for managing the complexity of modern web development.
to, serving them up individually during development and concatenating
and minifying them for production. To support this, Slinky recognizes
slinky_scripts in your HTML/Haml files. For example, when Slinky
!!!5 %html %head slinky_scripts slinky_styles %body %h1 Hello, world!
it will compile the HAML to HTML and replace slinky_styles with the appropriate HTML.
But what if your scripts or styles depend on being included in the
page in a particular order? For this, we need the
For example, consider the case of two coffeescript files, A.coffee and
B.coffee. A includes a class definition that B depends upon, so we
want to make sure that A comes before B in the concatenation order. We
can solve this simply using
class A hello: (thing) -> "Hello, " + thing
slinky_require("A.coffee") alert (new A).hello("world")
We can also do this in CSS/SASS/SCSS:
/* slinky_require("reset.css") a color: red
Slinky can optionally be configured using a yaml file. By default, it
looks for a file called
slinky.yaml in the source directory, but you
can also supply a file name on the command line using
There are currently two directives supported:
Slinky has a built-in proxy server which lets you test ajax requests with your actual backend servers. To set it up, your slinky.yaml file will look something like this:
proxy: "/login": "http://127.0.0.1:4567/login" "/search": to: "http://127.0.0.1:4567/search" lag: 2000
What does this mean? We introduce the list of proxy rules using the
proxy key. Each rule is a key value pair. The key is a url prefix to
match against. The first rule is equivalent to the regular expression
/\/login.*/, and will match paths like
/login/path/to/file.html. The value is either a url to pass the
request on to or a hash containing configuration (one of which must be
to field). Currently a
lag field is also supported. This delays
the request by the specified number of milliseconds in order to
simulate the latency associated with remote servers.
/search/widgets?q=foo. When slinky gets the request it
will see that it has a matching proxy rule, rewrite the request
appropriately (changing paths and hosts) and send it on to the backend
server (in this case, 127.0.0.1:4567). Once it gets a response it will
wait until 2 seconds has elapsed since slinky itself received the
request and then send on the response back to the browser.
This is very convenient for developing rich web clients locally. For example, you may have some code that shows a loading indicator while an AJAX request is outstanding. However, when run locally the request returns so quickly that you can't even see the loading indicator. By adding in a lag this problem is remedied.
ignore: - script/vendor - css/reset.css
This will causes everything in the script/vendor directory to be ignored by slinky, as well as the reset.css file.