you realize that you're just making Ted's point for him from the opposite direction, right?
his point, when you look behind the trolling, is that node.js is not magical special sauce and that shitty coders who write poorly-scaling code will be shitty coders who write poorly-scaling code no matter what technology they use -- the "cancerous" properties of node arise simply because of the amount of groupthink that pitches the Next Big Thing as intrinsically better than everything that came before it.
if I had to sum up his philosophy in three sentences, here they are:
your job is software engineering. every bit of fancy shiny stuff that you add onto your software is another thing that can break. the most important decision you need to make in your job is determining when your tools are good enough and don't need further elaboration -- at a certain point you need to stop jerking off about your toolchain, and just ship your project.
Yeah, some of those blog posts don't make much sense. The queues article, for example. RabitMQ and ActiveMQ are big Java things to keep your sysadmins up at night. ZeroMQ is just a networking library. Yes, they all end in "MQ", but at the end of the day, everything in computing as a message queue. If you don't like it, go back to typewriters :)
Fine. So you pick your tool (Java, Python, Node.js, presumably with an Nginx or Apache front end, though I'm not sure you want to put Node behind Apache), and use it.
I don't see how Node.js isn't a valid tool. Async can be a bit of an over-optimization, but you don't have to use it (even in Node), as Ted's naive Fib server shows. And Javascript is ugly as sin. But so's PHP, the language behind Wikipedia, and you have to use JS (or something like Coffee-script) anyway.
I don't know enough about Node to really judge it, but there's nothing I've heard in this whole flame-war that really rules it out.
agreed -- for what it's worth, I've looked into node.js for some of my projects, then thrown it out because I already know other technologies which serve the same purpose. the problem isn't with the technology, the problem is with the marketing (and that includes grass-roots marketing through engineers who swear by the technology as one-size-fits-all.)
It is an old question 'How do we tell truths that might hurt?'.
If you try the well reasoned analysis, you get passed over. It turns out that no-one pays attention unless there is a fight happening (c.f. tech crunch's reporting style)
'If the truths are sufficiently impalatable, our audience is psychically incapable of accepting them and we will be written off as totally unrealistic, hopelessly idealistic, dangerously revolutionary, foolishly gullible or what have you.'
The morale is - everyone admonishes a flame, but nothing else gathers posts quite like it. If you think something is terrible, holding back will get you nowhere.
Personally I've never seen node.js pitched as a solution for newbies or sub-par coders toiling away in the enterprise trenches. I've always seen it marketed as a useful tool for people who know WTF they're doing.
buzz is omnidirectional -- when people start talking about a technology, platform, or stack, people of all shapes and colors will show up and use it. and when your product pitches itself as having super amazing performance due to this programming paradigm omg!, you are responsible for making its limitations known to all and sundry who use it, rather than assuming prior knowledge.
also, the joyent node.js homepage itself claims, as a business advantage:
"• Huge JavaScript developer pool at the ready for faster development"
implying that any Javascript developer can just dig their hands right into server code and get working.
Right, let's just stop talking about cool new technologies since some people might misuse them. Does anyone want to help me debug my webapp? It's written in C.
my point isn't that you shouldn't build up buzz. it's that, when buzz exists around something, your job as a platform implementor includes making people aware of the things your product can't do well, and pitfalls the end-user might run into.
saying "well, it's their own fault for not being clueful enough to know what they were doing wrong, this technology is for pro hackers only!" is developer-hostile.
Being a wee bit pessimistically inclined, I somewhat agree with the assessment of the node.js programmer pool (seems similar to the first migration of PHP programmers to Ruby after the infamous RoR screencast), I find it hard to attribute to this to the developer(s).
Or in other words,
a) what did they do wrong?
b) What do you think would be the best way to "spin" a new platform like that without either being cluelessly elitist or giving the unwashed masses false hope?
disclaimer: I'm not a node.js expert by any means, and most of my day's work is on client code written in system programming languages (C and C++.) that which isn't, is in C#. I don't know of anything in particular that they're doing wrong because I don't really keep in touch with that particular PL community.
that said, my ideal pitch page would contain something to the effect of: "extensive standard library, including robust facilities for concurrent/non-blocking I/O". nothing marketing-y about non-blocking I/O or a given programming model making a language intrinsically "fast" or scalable, like nodejs.org's:
"This is in contrast to today's more common concurrency model where OS threads are employed. Thread-based networking is relatively inefficient and very difficult to use. [...] Almost no function in Node directly performs I/O, so the process never blocks. Because nothing blocks, less-than-expert programmers are able to develop fast systems."
in addition, node.js is in a little bit of a weird position of introducing a whole new language environment for an existing programming language, since node.js is effectively the vanguard of server-side/concurrent Javascript: I'd hope for an official series of tutorials designed to introduce the nonprogrammer, or "Web app-only programmer" of Javascript, to concurrent programming in the large.
that said, the node community might already be doing things like this which aren't obvious to the layman, and if so, good on them. good concurrent programmers are hard to find, and anything that encourages people to learn how to do concurrency well is a good thing.
Node is marketed towards people with Javascript experience to a large degree, it seems to me (I could be wrong). People with Javascript experience more than likely have it via writing for a browser. A browser functions functions identically to Node: the event loop. So, those coming from writing Javascript in a browser will merely carry through their knowledge of development practices to Node, meaning they intrinsically will write event based code.
Or at least that line of thought makes sense to me.
Really? I've almost never seen node.js pitched to anyone other than newbies (although not in the enterprise trenches for sure).
Rarely the pitch involves being able to share libraries between the server side and browser side (wonderful benefit of node.js)
Most of the time it's being sold as "you already know javascript" or "it's super fast, because non-blocking is magic sauce!"
I haven't used Node.js for anything serious but the hype and especially the discussion around the now infamous node is cancer post sure makes it seem like Biilmann was correct when he said "For better or worse, Node is like the PHP of concurrency and ever so often worse is better"
Even if that's not true, if that demographic is the dominant users of and contributors to Node then that's what Node will become.
I find the notion of sharing libraries between the client and server kind of odd, in that people who talk about the "open web" think it's a desirable quality.
it allows you to rev a protocol faster, but at the cost of not being forced to have a point of reference that isn't also intrinsically tied to one implementation of the protocol, which seems a very un-open thing to do to me.
The libraries I was thinking of sharing are all ones that are tightly coupled to the specific pages they would be on and all related to UI.
Things like form validation, user input normalization, navigation options. There are ton of small data manipulation functions that you either have to maintain in both javascript and your server side language and cause some weird bugs when one version doesn't behave exactly the same as the other or else you need to make a bunch of unnecessary ajax calls just to avoid reimplementing things in js.
There is much deeper integration you could do but I think we're on the same page as to why that's a bad idea.
his point, when you look behind the trolling, is that node.js is not magical special sauce and that shitty coders who write poorly-scaling code will be shitty coders who write poorly-scaling code no matter what technology they use -- the "cancerous" properties of node arise simply because of the amount of groupthink that pitches the Next Big Thing as intrinsically better than everything that came before it.