yay
Node v4.0.0
131–140 of 277 posts
Re: Node v4.0.0
#132Earlier 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…
> 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. -- Do you have examples? My counter to your anecdotal evidence is my own--we've successfully built and managed multiple projects in production, that service m…
I agree that it's possible to build successful Node apps, but of all the languages I use, it's the most difficult to keep up to date with and most likely to cause problems.
If you're reading the mailing lists, going to meetups, etc, these things might not seem like huge issues. But if you're just trying to run a small Node project as one amongst many bits of software in many languages, Node causes a disproportionate number of problems.
I've given a couple of examples below - Zombie switching to io.js, and the whole self-signed certificate debacle from a couple of years ago.
Re: Node v4.0.0
#133Earlier 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…
> 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. -- Do you have examples? My counter to your anecdotal evidence is my own--we've successfully built and managed multiple projects in production, that service m…
[deleted]
Re: Node v4.0.0
#134Anyone know when Node will get IndexedDB?
That's likely out of scope for node.js. I'd recommend checking out leveldb: https://www.npmjs.com/package/level
Re: Node v4.0.0
#135Earlier quoted context omitted.
A group of contributors got tired of Node not using semver when the rest of the ecosystem does (among other gripes). They forked it and shipped io.js v1.0.0. In keeping with semver, they bumped the major version number on every breaking change. According to iojs.org, the most recent version is v3.3.0. Joyent and the io.js team reconciled and merged their codebases, maintaining everyone's versions. Since io.js had use…
No api stability promises before 1.0 is technically part of semver. It sounds like io.js should have stayed below 1.0 if they broke backwards compatibility three times in less than a year! I always found the naming-and-proclaiming of semver in the javascript community silly. Old style C libs have been doing what semver describes for decades, and while the js community talks it up like crazy, the compatibility and sta…
The Node library is massive, and tightly coupled to V8. The changes that bumped the major version weren't major changes for most people, just for those who happened to be using the parts of the library that changed. Maybe that's a deficiency in semver (or the way io.js used it), but going to v4 in one year isn't as unstable as it sounds; it's just following Chrome's example of not caring how big the version number gets, so long as the semantics make sense.
I believe the io.js community was in the "ship or get off the pot" camp, and found it silly that Node was a critical piece of infrastructure at firms like PayPal while still technically not having had a GM release. By forcing the issue, they got Joyent to commit to major version changes twice a year, which sounds like a reasonable compromise between everything-changing-all-the-time and we-can't-have-new-things-because-legacy.
Re: Node v4.0.0
#136Earlier quoted context omitted.
...all you have to do is re-install it with the GUI installer and you're good to go And fix all the incompatible changes in your own code.
It's backwards compatible and works fine from what I see
I thought changing the first number in SEMVER means breaking changes?
Re: Node v4.0.0
#137Earlier 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…
- Ruby: 20 years old - Python: 24 years old - Node: 6 years old Maybe your comparison is somewhat unfair...
- language
- language
- io loop + vm
Re: Node v4.0.0
#138Earlier quoted context omitted.
in fact, to my surprise, I've just tested our app (v0.10.x in production) on v4.0.0 and all our unit tests pass, the server works... I'm amazed. A single module had to be bumped (Elasticsearch@8) while we directly rely on 50+ third party modules... Our npm-shrinkwrap is 2600 lines long. That's not really a sign of instability to me, but rather great work
You seemingly have much more experience with Node than me. Perhaps my amateur anecdotes are just bad luck, but certainly my Bash scripts that talk to Node break frequently.
Bash scripts talking to Node sounds like a recipe for disaster.
Re: Node v4.0.0
#139Anyone know when Node will get IndexedDB?
That's likely out of scope for node.js. I'd recommend checking out leveldb: https://www.npmjs.com/package/level
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 the same thing? I've been building an entire app around IndexedDB, but now I have to port it to a different Api to run on a server? Why?
Re: Node v4.0.0
#140Earlier quoted context omitted.
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…
> I don't think most people working on Node want a Rails equivalent It wouldn't really be possible anyway. Async programming is hard and the shortcuts one can take with synchronous Ruby are impossible with Async Javascript. Nodejs has a "fibers" lib though , but it doesn't look like it is widely popular, but AFAIK it is the only to truly abstract async programming.
Using abstractions like http://koajs.com/ and https://github.com/tj/co make Node code feel like every other language.
var user;
try {
user = yield db.insertUser('foo')
} catch(err) {
if (err.code === '23505') {
this.flash['error'] = 'Username taken';
this.redirect('/register');
return;
}
throw err;
}