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?
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.
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...
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.
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.
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?
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.
