201–210 of 277 posts
Earlier quoted context omitted.
`nvm install v4.0.0` and you're ready to go.
If you don't mind fetching package locations over HTTP https://github.com/creationix/nvm/issues/614
Everything else is done over Github's super-secure HTTPS - so there's really nothing to be paranoid about.
Earlier quoted context omitted.
`nvm install v4.0.0` and you're ready to go.
nvm install 4.0 works, do we really need the "v"?
Earlier quoted context omitted.
As somebody who uses Node only at the periphery of my role (for things like the Zombie browser, and SASS parsing) the massive instability has put me off from relying on it for anything core. Documentation is quickly out of date, libraries seem to have incompatibilities which only become obvious when they don't work, there's no 'recommended' approach for even basic tasks. I won't pretend I'm speaking for everyone, as…
I mean, Ruby was created in 1995, Python in 1991. Node was first released in 2009. That's not an entirely fair comparison since, of course, JavaScript was created long before Node, but Node introduced the language to a new environment, and a lot of complications needed (and in some cases, still need) to be sorted out. As for no recommend approach - that's deliberate. I don't think most people working on Node want a R…
Actually, no, it didn't. JavaScript was first introduced "on the server side" about 20 years ago in the Netscape web server[1].
We learn from history that we learn nothing
from history.
George Bernard Shaw[2]
2 - http://www.wisdomquotes.com/quote/george-bernard-shaw-19.htm...
Earlier quoted context omitted.
I use Java/Spring, Ruby, and Node.js in production, and Node.js is by far the hardest to stay up to date with without introducing major problems. The only framework I have used that is harder to update is Finagle. It's not just Node itself to blame. There seems to be a culture of breaking things in the Node.js ecosystem. Breaking changes in third-party libraries are common. I have to specify exact dependency versions…
In my experience, Ruby (particularly rubygems) is quite a pain in the ass with regard to package upgrades, especially when the previous developer/ops has leveraged rvm to install multiple combinations of ruby/gem versions. I can't tell you how many times I've had to trace down problems in a project because a single gem fails to upgrade/pull/compile/resolve on 2 out of 4 machines even though the project has an identic…
Earlier quoted context omitted.
Why out of scope? It's a DB api that has no browser/ui dependencies. I see that the levelDB implementation you pointed to can use a backend that uses IndexedDB. So theoretically this levelDB Api could provide an Api that work across both browser and server. But argh. IndexedDB is a standardized api. It has a usable open source implementation in WebKit. Why not just go with that?? Why create a different API that does…
IndexedDB is standardized for IndexedDB, which is not at all designed for use on a backend.
Earlier quoted context omitted.
If you don't mind fetching package locations over HTTP https://github.com/creationix/nvm/issues/614
nvm maintainer here: the only thing that's done over HTTP is the initial redirect on http://nvm.sh , which will soon be HTTPS. This URL is only used if you type it in (because it's easy to remember). Everything else is done over Github's super-secure HTTPS - so there's really nothing to be paranoid about.
Earlier quoted context omitted.
Why out of scope? It's a DB api that has no browser/ui dependencies. I see that the levelDB implementation you pointed to can use a backend that uses IndexedDB. So theoretically this levelDB Api could provide an Api that work across both browser and server. But argh. IndexedDB is a standardized api. It has a usable open source implementation in WebKit. Why not just go with that?? Why create a different API that does…
If you'd used leveldb from the beginning you wouldn't have this problem as it will happily work on the server and in the browser https://www.npmjs.com/package/level-js
Now look what's happened to Node just in 6 years. And this is just the beginning.
Alright, now everybody stare at ffmpeg and libav!
Don't forget about bitcoin core and bitcoin-xt! People are screaming bloody murder about that, it will be very, very interesting to see how it plays out.
"Lets hope the spork gets spooned so that no projects get knifed. If not then I guess we have to hope for a knork so we don't get stuck with a couple of chopsticks."