3 ms·
There are a couple of choices in the framework which need to be tested at a larger scale, but I felt the linkshui[0] application had reached a point that it was
by pfraze 14y ago
There are a couple of choices in the framework which need to be tested at a larger scale, but I felt the linkshui[0] application had reached a point that it was worth sharing.
The unified interface is meant to allow code to hide behind codified intentions: the requests. If a module makes a request to a configured URI, it encodes enough information in the request that any piece of code could step in to fulfill it.
This is the case in the *nix command line as well; you can compose command sequences which could be handled by whatever program is referred to.
The browser, however, doesn't really have an exchange system like that. It's up to the applications to specify how things are corralled, and that's why we have stuff like Backbone.js. Link is trying a different approach that focuses more on the operations level, abstracting the exchange between code so they can live independently.
[0] https://github.com/pfraze/linkshui https://github.com/pfraze/linkshui
- blibble 14y agothere's already a method for abstracting exchange between code: the function. unix uses pipes to pass data between processes in different address spaces, your JS runs in the same address space as the calling JS. if the processes exist in the same address space you use a library, which is an implementation of a defined set of functions (which is itself an interface); this is flat out better as it requires no tedious, error prone serialisation.
- pfraze 14y agoFunctions are very simple maps to functionality; they only act as name-tags. Link's requests share an API for functional descriptions which are mostly "name," "verb," and "content-type." That enforces a structure that's recognizable and specific. So LinkJS is dependency injection. It makes it possible to configure code into the application.