I will upvote you if you explain what you mean by the last part about "this style of programming" previously being on its (it's? anyone) way out. Do you mean an asynchronous style using callbacks?
Yes. Asynchronous style using callbacks has been done many, many, many times, and it really doesn't work very well. It does small things quickly, but have you noticed the number of complaints about how Node.js produces spaghetti code increasing lately, quietly and slowly but steadily? It's still buried under the hype, but expect it to get worse. And not "get worse before it gets better", just... get worse.
Javascript doesn't particularly bring any abstraction capabilities to the table that Perl (POE, Event::Lib, IO::Async), Python (Twisted), or Ruby (EventMachine) doesn't, and current Javascript is actually deficient in the abstraction department by comparison. (The latest ECMAscript spec can compare to them, so Javascript will get there. Something like Python generators allow you to string together a couple more tricks together before the complexity becomes a problem, and Javascript will eventually have this.) They all result in programs that end up the same way. There are some tricks you can play that improve the situation a bit over raw callbacks, like trying to sequence them, but composing these tricks together gets harder and harder the fancier you get.
None of those libraries really took off and some of them I know had way more effort poured into them than Node.js has seen yet, like Twisted. And it's because the style, combined with language runtimes that can't manage the scheduling for you while retaining the code context, has certain inevitable results. You can (and should!) delay the inevitable, but it's still inevitable.
At the very least, I would suggest that if you going to consider using Node.js you should be aware of the fact that it's not a blindingly new thing, it's a relatively well-explored space being translated into a new language, and you can get a good sense of the tradeoffs from the many previous explorations of this space. There are still places where it may be the right choice; as I said in that other message, I have chosen event-based coding in another context because it was still the right choice. But I knew the tradeoffs going in, and took steps to mitigate them, rather than being blindsided by them.
what do you think of that erlang version of the V8 interpreter I posted about higher up? I do find the idea of using the erlang VM where it can do a lot of good to be very attractive. While I would probably prefer python running on Beam to Javascript, JS is very "lightweight" if you take my meaning a certain way, and quite ubiquituous even compared to Python. It would also seem to dissolve your specific complaints posted here, would it not?
I use this architecture myself where there's an Erlang thing sitting in the center, dispatching relatively heavyweight jobs to Perl daemons waiting for them, and it does work. That isolates all the "eventish" stuff in Erlang, and turns the Perl daemons into, well, basically webservers, in the sense that they are just serving stateless RPC answers synchronously. This definitely avoids the complexity explosion.
You don't need a project like Beam.js to do that, but having someone else having already written the utility code can certainly be useful. Nothing like that existed for Perl but it hasn't been hard to do what I needed.
"way out" belongs to "it", so you're looking for the possessive form. English pronoun possessives do not use apostrophes (whose, mine, his, her, their, its), while everything else DOES (the dog's, Steve's, Portugal's, the crowd's).
