It strikes me that this developer chooses to write an abstraction on top of JS for solving his recurring problems, over simply using language features readily available.
Promises are as much a pattern or mechanic as callbacks, but the latter feels far more natural in JS. The `promised` decorator is interesting, but it has problems:
- The application I work on, and have in mind with this, would need just about every function decorated.
- It doesn't account for methods, unless you're default decorating the method, ie.: `Foo.prototype.myMethod = promised(function(/* ... /) { / ... */ });`
- Every decorated function takes a noticable performance hit, because things like `Function#apply` and concatenating `arguments` are relatively slow.
- It doesn't sit well with me that the example rewrites a method on a prototype declared elsewhere: `console.log = promised(console.log)`
Further, the article and library don't even scratch the surface of complicated async flows. Think async versions of common functional-style methods like `map`, `reduce`, etc.
For example, a basic scenario from our own build process is: Scan a directory for template files, read them, compile them, then concatenate the result and write it out.
We used to have a promise library to do all of this, from handling a build process to performing database queries. I discovered Async.js at some point and haven't look back since: https://github.com/caolan/async
I wonder why the HN account name field is optional, for getting in the shared circle.
Currently, it looks like anyone can add themselves just by having an email and G+ account. Someone already mentioned OAuth, and it'd be great if proper auth against both G+ and HN was required to be added to the circle.
On the other hand, it's also not that hard to selectively toss someone out of your copy of the circle, even right from the stream page.
Well, Google wouldn't replace their login process because they are the BrowserID primary. If you have a gmail account, BrowserID expects you to be logged in with it, which essentially means you're logged in to Google. (They could add it for non-gmail Google accounts, I guess.)
But Facebook could benefit from this. Maybe not at this early stage, but the way you log into Facebook is using your email account. That's exactly the step BrowserID wants to make easier.
I think the intention is for the primary to be your email provider. So if they become compromised to that extent, then I wouldn't feel very safe about my email account in the first place. Pretty much all of my credentials everywhere depend on that.
Until secondaries go away, Mozilla seems like a very competent and trustworthy organization to have in charge of browserid.org, IMHO. Much better than even Google. It's great to see that even the branding on browserid.org is minimal.
My guess is that, concerning nonces and revocation, they didn't consider the current situation (OpenID, OAuth for login, etc.) any better. BrowserID doesn't seem to do away with the strong advice to run HTTPS for such sites.
As a Dutch citizen, I am ashamed our own government's CA was compromised. And I'm a bit angry, because this hardly concerns just us but the entire secure web.
Frankly, I'm hoping for a lot more than just damages.
I'm not sure what people like about Personas (or the equivalent in other browsers). It always stands out, distracts, and for me even messes up the great website I may be viewing at the time.
I'd be much more interested in a CSS extension that lets websites 'bleed' their background into the browser chrome.
I can attest to that, both from reading and writing code with Docco documentation.
It's also great IMHO for getting an uncluttered view of code. In many cases, no matter how well written, the documentation is not enough. And while Docco is all about documentation, it shines even then.
Really? I'm normally as paranoid as the next guy, but this only requests read access. Stuff that anyone can find out about you any way if you already have a (public) Twitter account.
The frontpage is rather mysterious, though, I agree.
Promises are as much a pattern or mechanic as callbacks, but the latter feels far more natural in JS. The `promised` decorator is interesting, but it has problems:
- The application I work on, and have in mind with this, would need just about every function decorated.
- It doesn't account for methods, unless you're default decorating the method, ie.: `Foo.prototype.myMethod = promised(function(/* ... /) { / ... */ });`
- Every decorated function takes a noticable performance hit, because things like `Function#apply` and concatenating `arguments` are relatively slow.
- It doesn't sit well with me that the example rewrites a method on a prototype declared elsewhere: `console.log = promised(console.log)`
Further, the article and library don't even scratch the surface of complicated async flows. Think async versions of common functional-style methods like `map`, `reduce`, etc.
For example, a basic scenario from our own build process is: Scan a directory for template files, read them, compile them, then concatenate the result and write it out.
We used to have a promise library to do all of this, from handling a build process to performing database queries. I discovered Async.js at some point and haven't look back since: https://github.com/caolan/async