151–160 of 277 posts
"In parallel, we will be branching a new Stable line of releases every 6 months, one in October and one in April each year." Nice, they're syncing up with the ubuntu release cycle. Should make updating servers a bit easier.
Earlier quoted context omitted.
it's difficult to use it for anything serious without investing a lot of time into it. Isn't that true for many platforms? Either way, I have multiple apps running Node in production, and I've never had the issues described. You don't have to be as breakneck as Node itself - some things I have are still running v0.10x just fine.
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…
I contrast this with node/npm where my projects seem to behave identically across deployments (and in some cases, when in a bind, I've even been able to simply tar & scp the project src and have it run without further effort beyond installing node, something I've never been able to do with ruby).
ES6 support is nice, especially if there is no performance hits for using ES6 features. I slightly prefer Typescript, but the extra language features in ES6 really make JavaScript development more fun for me. Thanks to the newly re-combined Node team!
Earlier quoted context omitted.
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…
This is great news. I'm especially excited about the new ECMA6 features (arrows, etc.)
Earlier quoted context omitted.
> 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.
ECMAScript 7 has brought true async/await into the language, which currently works in Babel on top of Promises. As far as a regular user is concerned, define a function as "async" and then "await" on the result you're after inside of it. Hardly difficult, in my opinion!
A great essay on this is "What Color is Your Function": http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
> I think asynchronous programming in the reactor pattern is a good solution pattern for many types of problems, and Node.js is a solid application of that pattern. Asynchronous programming a la Node (with callbacks etc) is an anti-pattern. We've had better ways to handle that for 4 decades now.
For the benefit of any who are not sure what you are talking about, could you please elaborate on what some of these "better ways to handle that" are? It would make your comment much more helpful, IMHO.
People associate threads with shared-memory concurrency, which can be really hard to deal with, but shared heaps are not the important part - blocking is.
Blocking threads means that all your functions can call each other, all control flow constructs just work, and debugging is sane. With blocking threads functions don't need to belong to a special class of async functions that in general need to be called from other async functions.
It would have been great if node invested in allowing many concurrent blocking JS threads. To see what that could have looked like, see Dart's Fletch project: https://github.com/dart-lang/fletch
Alright, now everybody stare at ffmpeg and libav!