Rather than saying that CSP is more general, I'd say CSP is more provides you a more low level constructs. In FRP signals are the key concept that represent value that changes over time. Signals have a pushed based…
Statement that firefox Add-ons inside the broweser don't have a sandboxing is false. All the add-on SDK built add-ons load in sandboxed in a less privileged JS sandbox, although it is true that there is an escape hatch…
I don't think the goal is to replace code entirely, goal is to have a high level tool for high level problem that today is solved with a code but could be lifted. People that love low level stuff will still do it by…
I believe the whole point of the kick-starter campaign is to raise a money to actually build a visualization tool / engineering environment. You can also find demo in it's current state here:…
> Of course this means that some of Clojure's features (protocols and lazy sequences, atoms, etc.) are not available. On the other hand there are not so many opaque layers between your code and the target code. As a…
They have being added recently and more clojure compatibility is planned for the future.
In clojurescript strings are just sequences of characters where characters are expressed as \a and strings as "foo". In JS single char string is an equivalent of a character, as a side effect \a and "a" compiles to a…
Adding source maps support to wisp is my no 1st priority for wisp.
Note that most functions exposed by wisp do not mutate existing data structures and match clojure in behavior, it's just they use array's instead of vectors and dictionaries instead of maps. My hope is that it will…
I've tried to elaborate my reasoning in the readme actually: > Unlike clojurescript, wisp does not depends on JVM and is completely self-hosted. It compromises clojure's awesome data structures and embraces native…
Yeah I had this comment there // Assuming Mustache.render = promised(Mustache.render) But my hope is that more libraries will be accepting promises in a future so one won't have to do the wrapping of a world around.
Just to be clear this library implements just a subset of Q with exact same API, with only addition of `promised` wrapper. I'm convinced that this wrapper is a better way to deal with promises than dozens of utility…
First of all I implement abstraction using language features and there for I take advantage of it. - I favor maintainability over performance, also keep in mind that promised function take promises as arguments and…
What I'm suggesting is that promises don't need any special treatment. If you have a function that you want to feed a promise just wrap it: promised(Mustache.render). That's all it takes.
You're absolutely right! My English is far from being perfect and in addition I was rushing to get this post out making bunch of mistakes. I tried to fix all the "than" "then" issues, thanks for pointing that out ;)
I have already fixed that, it was a typo, I meant following instead: var deferred = defer() // make promise var a = deferred.promise var b = sum(a, 1) var c = sum(b, 5) console.log(c) // eventually prints => 17…
You just have to write function per operation that is it: var auth = promised(function(user, data) { var isAdmin = user.role === admin return isAdmin ? render(open("yay.xml"), db.send(data.request)) :…
I mainly was referring to JS where we don't have coroutines and there is no plans to have them either.
Sorry for confusion, I meant indeed a sync / async APIs. You could easily wrap sync function to give it an async API in order to chain with functions that had async APIs, but it's not really possible other way round…
Rather than saying that CSP is more general, I'd say CSP is more provides you a more low level constructs. In FRP signals are the key concept that represent value that changes over time. Signals have a pushed based…
Statement that firefox Add-ons inside the broweser don't have a sandboxing is false. All the add-on SDK built add-ons load in sandboxed in a less privileged JS sandbox, although it is true that there is an escape hatch…
I don't think the goal is to replace code entirely, goal is to have a high level tool for high level problem that today is solved with a code but could be lifted. People that love low level stuff will still do it by…
I believe the whole point of the kick-starter campaign is to raise a money to actually build a visualization tool / engineering environment. You can also find demo in it's current state here:…
> Of course this means that some of Clojure's features (protocols and lazy sequences, atoms, etc.) are not available. On the other hand there are not so many opaque layers between your code and the target code. As a…
They have being added recently and more clojure compatibility is planned for the future.
In clojurescript strings are just sequences of characters where characters are expressed as \a and strings as "foo". In JS single char string is an equivalent of a character, as a side effect \a and "a" compiles to a…
Adding source maps support to wisp is my no 1st priority for wisp.
Note that most functions exposed by wisp do not mutate existing data structures and match clojure in behavior, it's just they use array's instead of vectors and dictionaries instead of maps. My hope is that it will…
I've tried to elaborate my reasoning in the readme actually: > Unlike clojurescript, wisp does not depends on JVM and is completely self-hosted. It compromises clojure's awesome data structures and embraces native…
Yeah I had this comment there // Assuming Mustache.render = promised(Mustache.render) But my hope is that more libraries will be accepting promises in a future so one won't have to do the wrapping of a world around.
Just to be clear this library implements just a subset of Q with exact same API, with only addition of `promised` wrapper. I'm convinced that this wrapper is a better way to deal with promises than dozens of utility…
First of all I implement abstraction using language features and there for I take advantage of it. - I favor maintainability over performance, also keep in mind that promised function take promises as arguments and…
What I'm suggesting is that promises don't need any special treatment. If you have a function that you want to feed a promise just wrap it: promised(Mustache.render). That's all it takes.
You're absolutely right! My English is far from being perfect and in addition I was rushing to get this post out making bunch of mistakes. I tried to fix all the "than" "then" issues, thanks for pointing that out ;)
I have already fixed that, it was a typo, I meant following instead: var deferred = defer() // make promise var a = deferred.promise var b = sum(a, 1) var c = sum(b, 5) console.log(c) // eventually prints => 17…
You just have to write function per operation that is it: var auth = promised(function(user, data) { var isAdmin = user.role === admin return isAdmin ? render(open("yay.xml"), db.send(data.request)) :…
I mainly was referring to JS where we don't have coroutines and there is no plans to have them either.
Sorry for confusion, I meant indeed a sync / async APIs. You could easily wrap sync function to give it an async API in order to chain with functions that had async APIs, but it's not really possible other way round…