Irrelevant but I must say it: Node.js forced async IO is its strength but programming it is a pain in the butt.
Check out caolan's async module. It changes how you think about writing nontrivial js.
The Node.js Community is Quietly Changing the Face of Open Source
91–100 of 106 posts
Re: The Node.js Community is Quietly Changing the Face of Open Source
#92Earlier quoted context omitted.
And yet it succeeds. I think it's simply that async IO is in javascript developers' blood - sure, everything you can do in node you've been able to do for five years with twisted, but if you start trying to do something in twisted all that wonderful python ecosystem is suddenly useless to you, and no-one wants to talk about creating replacements because they've all moved on to tornado or gevent or incompatible-framew…
In web languages threading is often not the win that people think it will be. True web scale is serving 1000s of requests per minute if not second. Each of those users is a "thread" in Python, Java, Etc. So enabling multiple threads per users robs Peter to pay Paul. For this reason the Async model doesn't offer the huge performance gains in deployed code to enterprise scale, that it offers to single users trying to b…
You seem confused. The whole point of the async model is to allow one thread to serve many users, and it's precisely on large scale projects that this becomes useful.
Re: The Node.js Community is Quietly Changing the Face of Open Source
#93Great post. I'd also add to that list the benefits of local by default packages that are in your project folder. The approach of tools like easy_install, pip, bundler, etc is to hide all your depemdencies in some dot-prefixed folder outside your project directory. This promotes an out of sight, out of mind mentality. The npm approach on the other hand puts them in your project and makes it much more likely that you are going to explore the source of your dependencies, more likely that you bug fix those dependencies instead of work around bugs and most importantly you'll treat that folder like part of your own project. This last point means that you are likely to develop one of your own generic modules to the point where it's good enough to submit back to npm as a public module.
Re: The Node.js Community is Quietly Changing the Face of Open Source
#94Just what I want in a framework. Thousands of libraries with functional overlap, each tested in a small number of real use cases and having a large number of undiscovered bugs, none of which is flexible enough to solve my problem or has a large community to maintain it. In time, node users will realize the pain of abandoned library dependencies and the overhead of researching alternatives and grinding through bugs an…
I'll take monolithic, well designed, tested, and popular over a huge choice of one off libraries any day. Been there, done that. And, it's terrible. Monolithic things try to do too many things. It's fine if you grow along with it but a few years down the line - a beginner will find it very difficult to get started and manoeuvre around. Small, composable things are better. If something is popular, it will be forked an…
Small and composable things that are popular and well tested is great. That is not what you get from something like the wild-west of node. Perhaps your ideal is Linux, with small composable commands. How many of those commands copy or move a file? Pretty much one - that's because lots of unexpected things go wrong, and we need one good implementation instead of 500 shitty ones.
Rails is actually moving towards being a pre-installed collection of small composable things, much like a *nix distribution.
Small and composable is great. Everyone implementing cp is not.
Re: The Node.js Community is Quietly Changing the Face of Open Source
#95So, you want to compile LessCss. You go to npm and have a look at the options. Which package to use? assemble-less, baidu-less, buildr laessig, less, less-bal, less-clean, less-cluster, less-context-functions, less-features-connect, less-less, lesscompile, lesscw, lessup, lesswatcher, lessweb, style-compile, styles, watch-lessc, wepp Number of packages is far from a perfect measure of how much interesting and importa…
Only the "less" package is the one you care about. The rest of them aren't alternatives, they're extensions. Isn't that... a good thing?
Well, there are two hard problems in computer science, cache invalidation, naming things and off-by-one errors.
Extensions aren't bad, but you need to find them in the first place, and if all you've got is a single, non-hierarchical identifier... I'm aware that more elaborate namespaces like e.g. CPANs also can cause confusion, i.e. if they're not followed and you end up with modules all across the tree, but with a bit of community support the benefits still could outweigh this.
Re: The Node.js Community is Quietly Changing the Face of Open Source
#96Obviously if Node doesnt come 'batteries included' then you have to re-invent-from-scratch all the tools like package management, dependency management, MVC libraries, etc. That doesn't mean the community is amazing and wants to contribute! ...it means, that those features didn't exist, and someone had to do them (and yes, it's really great that they're all coming out open source, but it's not revolutionary) Any lang…
Obviously if linux doesn't come "batteries included" then you have to re-invent-from-scratch, or borrow, all the tools like compilers, web servers, package management, archive utilities, etc. That doesn't mean the community is amazing and wants to contribute! ... it means, that those features didn't exist, and someone had to do them (and yes, it's really great that they're all coming out open source, but it's not rev…
If you have a point, make it clearly instead of hiding it.
Re: The Node.js Community is Quietly Changing the Face of Open Source
#97Earlier quoted context omitted.
I like the fact that Node comes with a small core. I'm tired of vast, bloated, incomprehensible libraries that are going to take me more time to learn how to use than they'll be worth.
I'm sure eventually node will have it's very own Tornado/Twisted/Boost/etc that you can then apply to your argument.
Meteor?
Re: The Node.js Community is Quietly Changing the Face of Open Source
#98So, you want to compile LessCss. You go to npm and have a look at the options. Which package to use? assemble-less, baidu-less, buildr laessig, less, less-bal, less-clean, less-cluster, less-context-functions, less-features-connect, less-less, lesscompile, lesscw, lessup, lesswatcher, lessweb, style-compile, styles, watch-lessc, wepp Number of packages is far from a perfect measure of how much interesting and importa…
Imho. npm really isn't very good for finding libraries. I generally google for them instead and check out the first few hits on github. Perhaps that's why the writer of the article was so exited about the github monoculture.
Re: The Node.js Community is Quietly Changing the Face of Open Source
#99Obviously if Node doesnt come 'batteries included' then you have to re-invent-from-scratch all the tools like package management, dependency management, MVC libraries, etc. That doesn't mean the community is amazing and wants to contribute! ...it means, that those features didn't exist, and someone had to do them (and yes, it's really great that they're all coming out open source, but it's not revolutionary) Any lang…
Obviously if linux doesn't come "batteries included" then you have to re-invent-from-scratch, or borrow, all the tools like compilers, web servers, package management, archive utilities, etc. That doesn't mean the community is amazing and wants to contribute! ... it means, that those features didn't exist, and someone had to do them (and yes, it's really great that they're all coming out open source, but it's not rev…
node.js is like any other open source language in this case.
It's not so much like Linux (implied thesis: everyone will be running things on top of node.js like they are run on top of Linux)
Re: The Node.js Community is Quietly Changing the Face of Open Source
#100Earlier quoted context omitted.
No conflicts, but a tradeoff of loading two versions of library C. I assume at some point, the cost of multiple versions of everything (in terms of memory usage, for example) becomes an issue?
That's the tradeoff, with the crux being that adding more memory for a bit of JIT-compiled bytecode is preferable to having an app that just won't work.
There is something to be said for requiring developers to make things work right rather than work around their screwups, however.