notes-computer-programming-programmingLanguageDesign-prosAndCons-nodejs

btw yes i know it's a framework not a language

http://www.youtube.com/watch?feature=player_embedded&v=GaqxIMLLOu8

" o

Yeah, if you're going to have to do async to be performant than it better be pretty pervasive throughout all the libraries. Bonus points if the language supports syntax to make async easier as well. Node is beating out Python for server stuff not simply because it is "async", but because it is so much FASTER. The speed of V8 vs. CPython is a big part of that. In fact, vanilla JS doesn't have much to make async programming particularly easy: it has verbose function declaration and no yield mechanisms. Even library-level solutions like promises are merely 'OK'.

Still, it is easier to build a fast server that can handle streams in Node than it is in Python. Async Python? I'll just stick to async JS in that case.

reply

rdtsc 1 day ago

I think there is another issue here. Python world has watched as Node.js has been eating its lunch on the server side and they decided, ah, surely that is because Node.js has async, if we add that too, everyone will love Python again and come crawling back. They are not saying, I think that is written between the lines.

Except one thing, as you pointed out, people use Node.js -- 1) it is JS 2) V8 is fast.

reply

nashequilibrium 1 day ago

The reason why you getting so many downvotes is because your comment is not just silly but flat wrong. Twisted, Tornado were around before nodejs. There are also async frameworks that make writing async code the same as synchronous code. I like tornado but I am using nodejs for my current app because of the libraries. This is where nodejs really shines, the community and libraries are awesome. Twisted has a lot of libraries but it has so much going on that many developers find it too complex. Tornado is a much simpler async framework to adapt to and allows you to run twisted libraries.

Twisted's inlinecallback's and tornado's gen module gets rid of all the async spaghetti code. This is hard to do with nodejs but I still chose nodejs because the available libraries made my project quicker to develop.

reply "

"

petercooper 19 hours ago

And the language simply isn't as good, IMHO. The ecosystem and the runtime may be better in numerous ways (the "node" part of "node.js" is also superb) and it may be fun to develop in, but that's in spite of the language. As a pure language JS isn't just up with Python, Ruby, C# or the like yet IMHO but progress is being made on this front (and even if it doesn't, things like asm.js, CoffeeScript?, TypeScript?, and Dart give us options.) "

---

module system:

" carrja99 1 day ago

I'd have to say the biggest thing that npm has over module systems found in java, ruby, python etc. is the complete isolation of transitive dependencies. It is nice to use two dependencies and not waste a day or two because:

• module A depends on module C v1.0.2
• module B depends on module C v1.4.3

In all the languages you mentioned it becomes a pain because you can only use one version of module C, meaning either module A or B simply will not work until you find a way around it.

reply "

" dragonwriter 1 day ago

> Semantic versioning's raison d'être is to prevent these sorts of issues.

Semver may surface them by making it very clear (assuming all involved libraries use semver) where they can occur, but, if you have a package management/loading system that only allows one version of a particular package to be loaded, obviously can't do anything to prevent the situation where different dependencies rely on incompatible versions of the same underlying library.

Sure, with semver it won't happen if A depends on C v.1.0.1 and B depends on C v.1.4.3 (as A and B can both use C v.1.4.3), but it will still happen if A depends on C v.1.0.1 and B depends on C v.2.0.0.)

To actually avoid the problem, you need to isolate dependencies so that they aren't included globally but only into the package, namespace, source file, or other scope where they are required.

reply "

" No1 1 day ago

NPM's way of managing dependencies still can waste a day or two (or more) of your time. For example, get a C object from B, then pass it into A.

Things are even more twisted when you have a half dozen versions of C floating around in your node_modules, and the problem isn't in your code, but a dependency of a dependency.

Another issue I've run into is patching a bug in a module, and then having to figure out how to get that patch into all of the other versions that cropped up in node_modules.

NPM is one way to solve the modules problem, but it's no panacea. "

" k3n 1 day ago

That's great, but it's not without cost. Here, the cost is you end up with deeply-nested directory nodes (which breaks Jenkins ability to properly purge the directory after a job). Node modules are also extremely liberal in the number of files they create -- even a "simple" app using just a few common modules could end up with 1k+ extra files. This can produce problems in your IDE, as well as with your source control or continuous delivery systems, among other things.

So, it solves some headaches, and creates others.

reply "

npm shrinkwrap

"

nobleach 1 day ago

While I like using NuGet? packages with C#, I'm not really wild about how they can get magically linked in to a project, and then required. I had nunit and fluent assertions become inextricable from a project I was working on even after all the tests were removed. Just a total mind-f*ck. Python when using pip is a whole lot better but I've had some issues finding things there too. Ruby... it depends. Are we talking Rails gemfile or "gem install $package"? Conflicting versions can become an issue. Java with Gradle has been pretty cool so far. NPM as a whole, has just worked. Packages are referenced in ONE place (package.json) I can do an "npm install $package --save" during development and it gets included automatically. "

"

clintonb11 1 day ago

I agree. PIP in python is great, but has some extra overhead and difficulty with it, like having to setup virtual environments for each project. NPM by default installs to the local project only and with a quick --save will put it in package.json dependencies (similar to requirements.txt with pip). Node package management is awesome because it is so simple.

reply

rhelmer 1 day ago

Virtual environments are optional though, right? You could have one big virtualenv for all projects, or simply install things into the system path (although I wouldn't recommend either)

reply "

"

PuercoPop? 1 day ago

I should just probably say, clearly you haven't seen Common Lisp's defpackage, modules are actually first class objects there and are completely decoupled from the file system.

But most importantly as Barbara Liskov mentions in this video[1] we don't know what is a module exactly or how to use them yet. Which is an specific statement aligned with Alan Kay's famous "We don't know how to design systems so let's not turn it into a religion yet."[2]

tl;dr; 1) Innovation is good. 2) Javascript's module is a half assed implementation of Common Lisp's defpackage. (Don't get me wrong is still way better than Python's abhorrent ninja goto: import)

[1]: http://www.infoq.com/presentations/programming-abstraction-l... [2]: https://www.youtube.com/watch?v=oKg1hTOQXoY

reply "

"

coolsunglasses 1 day ago

You have not used a good module system. Clojure's namespace system for example is really nice.

reply

rafekett 1 day ago

Have you used ML?

reply

bungle 1 day ago

Still that is the thing that Node.js lead developer regrets the most. Too late to change it, though.

reply

"

---

"

nadaviv 1 day ago

ES6's generators and the `yield` keyword plays very nicely with callback-based code, doesn't require any changes to the underlying libraries and gives you a much nicer syntax to work with.

See https://github.com/visionmedia/co

reply

JoshGlazebrook? 1 day ago

I've been looking at another library like the one you linked. Essentially the "yield" keyword can be compared to "await" in C#.

https://github.com/bjouhier/galaxy

reply "

"

CyruzDraxs? 1 day ago

It was easier until we discovered even cleaner ways, and most of the Javascript community began to adopt them. But node chose to stick to the "old" ways. (Not really old, but not as shiny and new as the alternatives)

I feel like promises don't need to be part of core though. It's easy enough to wrap the standard library in userland and just have other things depend on the wrappers.

reply "

olegp 1 day ago

You can use fibers. We are doing that via common-node (https://github.com/olegp/common-node/) and are very happy with the choice at https://starthq.com

reply

ilaksh 1 day ago

Take a look at ToffeeScript? https://github.com/jiangmiao/toffee-script

reply

kailuowang 1 day ago

> Callbacks will remain the de facto way to implement

> asynchrony. Generators and Promises are interesting and

> will remain a userland option. "

I am seeking for a comparable alternative to node (or something on top of node) in which Promises are the de facto way to implement async. Any suggestions?

reply

uniclaude 1 day ago

Is the fact that they use callbacks instead of Promises outside of userland a real problem for you (as an application developer)?

You can totally write your node applications using only Promises using something like Q if you feel like it.

reply

spankalee 1 day ago

Dart is very Node-like is that it's event based, but almost all async APIs are based on Future and Streams, including all IO, and therefore any other packages that do IO, like database drivers. This makes things very consistent and composable.

On top of that you get to use a much nicer language than JavaScript?.

reply

fizx 1 day ago

Scala+finagle is comparable in use cases, but scala isn't very close to javascript. Perhaps still worth looking into though.

reply

halayli 1 day ago

Checkout C++11. It has lambda callbacks, promises/futures and async with threading.

reply

usea 1 day ago

I don't think C++11 is a comparable alternative to node, personally. Although I understand that's a subjective judgment on my part.

reply

CyruzDraxs? 1 day ago

Have a look at node.native. It's just libuv and c++11, which behaves pretty much the same as node. But much lighter, and with no Javascript engine tacked on. Obviously not nearly as stable and supported, but it's an example of how c++11 can work very similarly.

reply

rmgraham 1 day ago

Or luvit (libuv + Lua)

reply

bryanlarsen 1 day ago

It probably would be fairly straightforward to write a generator that wrapped every function in a module with Q.nfcall.

reply

abecedarius 1 day ago

The E language http://erights.org/ works that way. It's unfortunately been inactive for years; its BDFL moved on to the Javascript committee.

reply

agilord 1 day ago

Dart. Look for Future and Stream.

reply

dustingetz 1 day ago

node + clojurescript. you can do better than promises.

http://swannodette.github.io/2013/07/12/communicating-sequen...

reply

ilaksh 1 day ago

Take a look at CoffeeScript? (cleaner callbacks) and ToffeeScript? (callbacks hidden, just look like sync code). Those are much better solutions that promises.

reply

domenicd 1 day ago

You may find https://npmjs.org/package/pr useful.

reply

..

pcunite 1 day ago

I'm new to web programming but I got the impression that C++ for web work was silly ... use PHP, use Rails, use this, blah, blah, everyone said. Now it seems that Node.js is just C++ style programming in JavaScript?, expect that you get "packages" that manage the HTTP headers (and other things of course) for you.

It would be cool if someone makde a Node.C++. I would have less of a learning curve.

reply

ricardobeat 1 day ago

You mean this https://github.com/d5/node.native? Godspeed.

reply

oscargrouch 1 day ago

i hit "casablanca" the other day from microsoft.. what impress me is that is open source and it also runs in linux. (not even in my wild dreams o would predict this to happen one day)

anyway.. looking at the source its pretty decent, and go right to the point.. of course its focused in HTTP/REST..

theres a bultin IO scheduler and a concurrent task system.. from microsoft.. who would say so :)

reply

pcunite 1 day ago

Wow ... thanks for the info!

reply "

"

rdtsc 1 day ago

> Ryan Dahl created Node. He's not just some schmuck.

---

"The only interesting languages are C/C++, Go, Dart, JS (and possibly Rust). Everything else is legacy bullshit." "

https://www.joyent.com/developers/node/design

---