Hacker News Reader

Comment by FraaJad | Hacker News Reader

You know you can host the code behind persona.org your self on say https://auth.myservice.com. IIRC, it is node.js code.

View on HN

The Persona code suffered from pretty serious feature creep. It's F/OSS, but I'd strongly suggest learning from Persona's design rather than directly re-hosting the code.

Heck, some of the code still dates back to when Node.js was only on version 0.4.5. :)

Maybe the persona team had better things to do than updating the codebase to each and every node.js release. It looks like node.js will become the new state of the art for crap web platform after PHP over some CGI. It's design changes a lot on a quick cadence, the community is based on coolness and fashion, its users and developers are mostly non-professional, inexperienced persons, and its use of the IO model is obsessive and single-minded.

Node has come a long way, and now has a responsible release cadence, including annual LTS releases, each with 30 months of security / critical patch support. The ecosystem is still crazy (especially with the ES6 features showing up in the Node 4.2 LTS), but Node itself seems to have matured nicely.

Persona may have been a bit premature in choosing Node, but we expected to share much of our code between the backend, frontend, and Firefox itself. Node offered a great opportunity to attempt that. Plus, the whole thing started as a side project between two engineers, so why not try out something crazy and new?

    annual LTS releases, each with 30 months of security

Am I alone in that 30 months feels like a "normal" release? I'm usually thinking LTS in terms of CentOS's definition.

Comparing node to PHP is a little unfair. PHP works!

Comparing node to PHP is a little unfair. Node has a great package system, JavaScript is an evolving language that run almost everywhere: in all browsers, server side, in devices. PHP started as a simplified Perl, is a web page preprocessor that works well in that context: it can be used server side but almost nobody do it.

> Node has a great package system

Having used both, Node's package system is horrific compared to PHP's Composer. Composer's built-in composer.lock system is something NPM sorely needs by default.

It exists (npm shrinkwrap [1]), but it's not enabled by default, and it has some warts, such as non-deterministic sorting of entries.

There's a third-party tool [2] that is supposed to solve many of the issues, but I haven't tried it.

Of course, if you do this, there's a decent chance that if you try installing it again in 6 months, your shrinkwrapped version of at least one of the dependencies won't be available any more...

[1]: https://docs.npmjs.com/cli/shrinkwrap [2]: https://github.com/uber/npm-shrinkwrap

Yeah, I've been experimenting with shrinkwrap.

Biggest wart I've encountered is I've got a package that installs fsevents (OSX-only) as one of its optional dependencies. When I shrinkwrap and attempt to install on a Linux server, that optional dependency is treated as a required one, and it can't install. I have to manually zap it from the JSON. :-/

One wonders, why shouldn't it be 'npm lock'... I'm not that into plastic packaging, and not a native speaker, so shrinkwrap gives me as much clue about what the command does as blinktap, or pricklywarp.

Oh sure, but it works like a shotgun jetpack pointed at your foot.

I disagree. I think node is unlike anything we've seen thus far. It's not php, it's not python and it's not ruby.

I, literally, cannot rebuild my application from a year and a half ago that is standard node + npm. The deps are broken...the code won't build with node-gyp...i mean node-waf...i mean who knows? What a mess and a HUGE regret.

> I, literally, cannot rebuild my application from a year and a half ago... The deps are broken...

Welcome to the Cloud Future Web 3.0, where every library you use is maintained like some random guy's personal homepage, and his robots.txt prevents you from caching a stable copy.

I don't understand this argument. If you know what parts of your site the deps will effect it should be trivial to update them incrementally and rollback the commit if one unexpectedly breaks your code.

Besides, there's no universal unwritten rule stating that you have to use the bleeding edge version of every dependency.

Keeping all dependencies up-to-date is mostly in the interest of widely used libraries not one-off applications.

Not sure what the OP's problem was, but I've had issues with old libraries where some dependencies have been removed from npmjs.com. It's totally ridiculous.

I solve such problem for our clients by packaging every dependency we use in project as independent RPM package, so whole application can be installed using single "yum install ..." command from local repository without need to connect to internet. It allows us to precisely control version of libraries we use and also allows to apply patches to them when a problem is found.

I haven't seen the disappearing libraries from registry.

I did find a few libraries that have been completely abandoned...like 2/3 of the libraries I used.

So it's not immutable? Blinkin' egg, I'm happy I only played with node.js now. On the other hand, I guess it's always better to vendor one's deps, at least those that are not packaged by the operating systems. The language specific package managers add a lot of complexity.

I went as far as pulling the node_modules directory from production and perfectly matching the node version on my local machine. Linux -> linux and the app won't run locally. I think it's because the node-gyp influenced deps need to be built locally and linked to the right libs.

I then spent a few hours downgrading each version to isolate the issue...found a few libraries that were hard-deprecated (which was nice), found some breaking changes in the node version I'm using and then I just gave up.

Sure, but--as the traditional rant (http://blog.codinghorror.com/the-php-singularity/) goes--it works like a claw hammer with two claws and no face: sure, you can turn it sideways and drive nails with the middle part, but wouldn't it be easier to just get a hammer?

That is a bad tool only if you want to use it for driving nails. A claw hammer with two claws and no face is a magnificent tool for pulling out nails.

Rails is a hammer with a normal head but no claw. Hammering nails in is the more common case, but if you need to do both you're better off with the two-clawed one.

The only people that say this kind of shit are the ones that don't use node. There are many large companies using node in production. Most community members I've interacted with are professional devs.

> The only people that say this kind of shit [...]

You do not even know how to interact with people like a proper adult. There are many companies, large or small, using PHP. Many popular blogs run on moveable type, that's Perl 5. Many companies run on Microsoft technology. And some popular websites run partially or wholly on Node.js. So what? Should I make my technology decisions with a « jump on the most brightly coloured bandwagon » approach? Node.js is a toy. A cheap chinese one.

I know.

But then I've taken on the maintenance and security of a system that I am not familiar with the internal workings of. That seems riskier than finding an alternative.

True. But, if persona has a large and active open source community, it might be better to use that than maintain homegrown solution in the hope of "security by obscurity".

There are some strong auth/auth open source communities - https://github.com/Jasig that serve millions of users.

it would be awesome if the community could really take persona up and fix it up / make it easy to run etc.

i.e. i wish projects like this the best of luck and hope to be using them later :)

The community will never be able to implement BrowserID in the browser without Mozilla's permission. This is the missing piece that would have made BrowserID awesome, without it, there's little point, you might as well use Google/Facebook/Twitter log-in.

I am not aware of anyone ever trying to implement it. There is not even a plugin from what I know. If someone would integrate the UI in a plugin, that works and people use it, I would be surprised if Mozilla would not accept a proper Patch to Firefox implementing that.

The proposed UI was not blocking anything, not even taking space.

Given Persona survives this.

Reply on news.ycombinator.com