This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-22
Channels
- # arachne (8)
- # bangalore-clj (1)
- # beginners (72)
- # boot (95)
- # braveandtrue (5)
- # business (1)
- # capetown (1)
- # cider (180)
- # cljs-dev (8)
- # cljsrn (20)
- # clojure (104)
- # clojure-art (1)
- # clojure-brasil (8)
- # clojure-czech (1)
- # clojure-greece (15)
- # clojure-korea (13)
- # clojure-poland (2)
- # clojure-russia (53)
- # clojure-sg (5)
- # clojure-spec (60)
- # clojure-uk (35)
- # clojurescript (186)
- # community-development (3)
- # core-async (24)
- # cursive (18)
- # datascript (11)
- # datomic (39)
- # devcards (4)
- # emacs (2)
- # events (1)
- # funcool (23)
- # hoplon (148)
- # juxt (1)
- # ldnclj (2)
- # luminus (1)
- # off-topic (22)
- # om (27)
- # onyx (35)
- # overtone (2)
- # pedestal (7)
- # perun (8)
- # protorepl (2)
- # rdf (6)
- # re-frame (15)
- # reagent (2)
- # ring-swagger (10)
- # untangled (54)
FYI I started working on a CLJS port of some of the Buddy components, entitled “Pal”: https://github.com/leppert/pal-core https://github.com/leppert/pal-hashers At the moment it’s not entirely useful (though much of the hashers functionality is there) but the hope is that it might one day be robust enough to provide syntactic familiarity between Clojure Buddy projects and Node Pal projects.
I have started in the past something with nodejs target https://github.com/funcool/dost
After read a little bit the code, now I have the answer: yes seems like it target to nodejs
@leppert Will be welcome if I port some changes from dost to pal? I think that nodejs native hashes and hmac supports is better than the google closure library, just because they are native implementation. Also I have support for nodejs streams in dost that is useful for hash big files without blocking too much.
On the other hand, js and jvm environments are pretty different, so I don't recommend try to have the exact api with buddy
many things can be similar or equal but many other can't be and I don't recommend force to have a similar api.
@niwinz any help would be greatly appreciated. In terms of targeting node vs all js environments, I'd love for it to be generally portable so I'll put that in as a future goal, but node is my current use case and, as you said, node offers some specific speed and convenience that we couldn't get with browser restrictions.
With regards to keeping the APIs the same, I think you summed it up well. I'm going to shoot for them to be as close as possible but won't sacrifice sanity or usability at the expense of perfection.
apache2 if you are ok with permisiviness or MPL2.0 that is similar to EPL but better compatibility with gpl