|
We use Node at my office. It's pretty great for little start-up companies where you only have one developer and you need a back-end and a front-end and why switch context when you can just live in JS all the time? The V8 engine is pretty spectacular, so you can get a lot of mileage out of this setup. You're often doing most of the work on the front-end, and the back-end is just a layer on the database. We've been hitting some Node walls lately, because it's not a good general-purpose back-end choice. There's a much higher number of heavily-used libraries that are dumb than I'm used to. Logging kills it (yes, logging kills all back-ends, but Node goes down faster and with fewer users than anything else). Callbacks are great when the chain is short (take a request, hit a DB, hit another web service, reply to the request), but once you have 10 operations to perform, it's hell. If you have 10 operations to perform and you're not doing callbacks, then you're hosed because it's single-threaded. It's easy to write code, and I'd definitely use Node for prototyping. Beyond that, though, I feel like you either run into trouble or you have to become such a deep expert at the V8 engine and the C libraries that you lose the whole "any dumb programmer can do it" point of Node.
|
#
¿
Feb 28, 2015 06:43
|
|
|
|
| # ¿ May 11, 2024 19:53 |
|
|
RICHUNCLEPENNYBAGS posted:I am, like I said, a neophyte. But isn't this where a promise library would be useful? If there's little to no complexity, then yes. But if you want to run some async operations in parallel you get nested promises and that can be pretty ugly. And some things like Node.js streams (which are nice) use a callback interface and so you have to do both promises and callbacks. We mostly use Bluebird for promises and there spots where promises make things harder instead of easier. I've heard good things about Async.js for managing callbacks but haven't used it. It's not like you can't do anything you want in JS. But my experience with Node is that it makes a certain class of easy problems a little easier, and makes most hard problems harder. Coming from a server-side Java background, that's not typically the trade-off that I want to be making.
|
|
#
¿
Feb 28, 2015 14:05
|
|
|
Steve French posted:Can you explain this comment? I know little about the proposed or planned promise implementation in javascript, but every other implementation of promises or futures that I've used makes it incredibly easy to run async operations in parallel... Not really. I'd have to paste 5 pages of our internal code, write 5 pages describing the clients and the other back-end services and what the code is for, and then everyone would pick apart the dumb bits (there are plenty) and suggest alternate libraries and technologies ad nauseam. I don't think "incredibly easy" can ever describe interleaved threads of execution. I'm not claiming "JavaScript can't do complex parallel operations". I'm claiming that when you need to build a complex DAG of forks and joins, languages that expose some thread construct make things easier because you can write some operations serially and trust the language to handle the parallelism but you can also control all the parts that you need to. It's ugly, hard code no matter how you slice it, though. Node.js (with or without promises) adds complexity here because you've got all these operations that must be written async since you don't have threads. Maluco Marinero posted:As per usual, the trivial examples people use to say how great node is never really hit this problem. Yeah, this. And you can write actual money-generating applications that are built out of nothing but trivial pieces and use Node fine. And if you need more, you can become an expert at all the deepest bits of V8 and Node and JavaScript and every library you use. But then you're no longer instantly converting your front-end developers to full-stack.
|
|
#
¿
Mar 1, 2015 04:53
|
|
|
I understand that Async is popular if you want to do callbacks, though I haven't used it. At my office, we use Bluebird for promises. Then your 10 nested callbacks turn into 10 chained promises. If it's a straight chain, promises are nice. They often feel easier to wrap your head around, too. On the other hand, whenever I start working with Node's streams (which are quite nice) I need to use callbacks and then I regret the callback/promise mixture that I end up with. Finally you could look into using fibers, which I think would be the most pleasant way to handle a sequence of DB calls.
|
|
#
¿
Jun 19, 2015 12:36
|
|