

If it doesn't feel natural, it will be replaced.  Sorry node.js - hoodoof

When a new software development technology starts to get traction, it's often clear in hindsight that the old technology was kind of hard, unnatural, going against the grain somehow.
Consider XML versus JSON - JSON feels far more natural, XML feels harder, more verbose, more complex. Consider ORMs compared to NoSQL - NoSQL feels easier, like a more natural fit, like a natural solution to many common programming challenges, whereas ORMs feel like a difficult, slow kludge, a technology mismatch which just doesn't feel right. Consider Java versus Scala - Java is verbose and requires much code which is not directly getting the job done - other languages that run on the JVM are coming to the forefront which remove the unnatural, pointless bits.<p>So whenever a new software development technology comes along, if it feels "unnatural" then there is bound to be something that will come along and replace it.<p>node.js is the king of unnatural programming, forcing programmers to twist their heads into callback spaghetti oriented programming. This is very rough and unnatural but developers endure it because it allows Javascript at the back end and because the performance is very good. But when the next technology comes along that removes the need for that painful callback mindset AND provides high performance and Javascript, people will breathe a sigh of relief and flock to it. "At last, we can program again in a natural style".<p>node.js just doesn't feel natural, so it's clear that it's yet another stepping stone to a better web server technology. We are not there yet.
======
Jesse_Ray
XML may seem harder than JSON, until you actually try to work with the data.
When you need to create an automated system that checks that data has a
certain format, XML has support for schemas and there are many software tools
for creating schemas, which is something that cannot be said of JSON.
Likewise, searching for data is much easier when you have a standard like
XPath. Something akin to XPath would be much harder to make for JSON, since it
lacks native support for element attributes. When the data needs to be
transformed into a variety of formats, XSLT comes to the rescue. When you want
to give the user data in a readable way, JSON requires server-side processing
whereas XML and CSS (and sometimes XSLT) support is built into the web
browser. In my opinion, JSON gets too much attention for what little it
offers. It could become a serious alternative to XML in the distant future,
but not until it has the kind of technological environment that XML enjoys.

~~~
batista
* In my opinion, JSON gets too much attention for what little it offers. It could become a serious alternative to XML in the distant future, but not until it has the kind of technological environment that XML enjoys.*

JSON has smoked XML in the RPC/SOAP etc style uses. Including replacing the X
(for XML) in AJAX.

It is also the preferred format for many datastores.

It does not have mature tools like the ones you describe, e.g for schema
validation, transformation, etc. Then again, lots of people have found that in
regards to XML, the aren't gonna need them, anyway.

For other uses, still, XML is king.

~~~
Jesse_Ray
Thanks for the information, batista. It does not surprise me to hear that JSON
has gotten popular in Javascript applications and the datastores that interact
with them, and likewise with key-value datastores since the data mapping seems
rather straight-forward when compared with XML (element attributes would seem
to pose some problems). However, it would pique my interest to hear that other
kinds of datastores prefer it. Do you have any links handy that show this
about other data-stores and the technical reasons behind the preference? And
at the risk of requesting too much, any links that show JSON besting XML in
many RPC/SOAP use-cases?

------
jgrahamc
What if what you are feeling is only a personal opinion reflecting your
particular skill set? There might be a large pool of people who think in the
node.js style and to whom it is completely natural.

Your argument could be applied to functional programming languages that to
many feel 'unnatural', but to others feel like the one true way. Similarly RPN
or 'normal' calculators. RPN feels natural to some, alien to others.

~~~
batista
_What if what you are feeling is only a personal opinion reflecting your
particular skill set?_

Trust me, it's not his "personal opinion". The callback spaghetti mess is a
real problem, there are several libs that provide not-perfect-but-ok
solutions, and even hardcore Node folks acknowledge it. Basically, you cannot
NOT acknowledge it, except if you haven't got any experience with a language
with proper constructs to avoid this kind of thing.

 _Your argument could be applied to functional programming languages that to
many feel 'unnatural', but to others feel like the one true way._

That's not much of a counter-argument, since those others that "feel like
functional languages are the one true way" are few and far between, and those
languages never caught on the mainstream ever in 50 years.

And when the new, better thing, came along (functional capabilities in a more
friendly syntax, be it Scala or Ruby or whatever) people adopted it much
better than all the functional languages with the "strange syntax" combined.

 _RPN feels natural to some, alien to others._

Same thing here. That's why RPN is not mainstream, because the guys that get
it are few and far between.

And that's what he argues --a technology that feels unnatural to many will be
replaced with a similar technology that has the same goals/benefits but feels
more natural.

~~~
ryanto
Programming is hard. It is really really really hard. It can also be really
enjoyable, especially those ah-ha moments when you figure out the reasoning
behind a certain pattern/style/idiom.

You are dead right that callback spaghetti is a problem, but instead of
blaming the language/library you might want to reevaluate your implementation.
There are a number of ways to deal with node callbacks. This is an excellent
easy to follow article:
[http://seanhess.github.com/2012/02/20/functional_javascript....](http://seanhess.github.com/2012/02/20/functional_javascript.html)

------
manuscreationis
You realize that every single point you make in the first paragraph is 100%
subjective. Each one has its strengths and weaknesses. It just feels like you
personally don't get some of these "outdated technologies" or weren't brought
up in environments where their strengths shined.

There are no magic bullets. Regardless of how bad you might think something
is, someone else out there can give you a wide range of reasons why it should
be used.

That said, Node is fun, but its no savior.

------
scriby
Don't like callback hell? Use fibers.

<https://github.com/scriby/asyncblock>

(My pet project, a flow control library built on fibers that gives you all the
benefits of async programming without the callbacks)

------
rasengan
I have to disagree. While I understand your points and where you are coming
from, I love event and callback based code. Maybe it's from the days of mIRC
scripting... ;)

------
geuis
Node feels _completely_ natural to me. I spent my time in the trenches with
PHP and Python, then spent many years mainly writing client-side code with
javascript. Next to node.js, Python is my favorite server-side language. It
fits the way my brain works. It might be the particular history I've had in my
career of doing development on both sides of the table, but I took to node
very easily.

I think your first paragraph is spot-on. You make some good points, though I
would recommend the addendum that while for most cases JSON is a lot lighter-
weight and easier to handle than XML, there are certain types of data that are
actually harder to model in JSON than XML. I think these cases are a minority,
but they do exist.

To your point, "forcing programmers to twist their heads into callback
spaghetti oriented programming", this usually happens when someone who doesn't
truly understand prototypal inheritance and evented programming is getting
started. Its a totally valid criticism, since that is certainly a way to
structure your code. But you're not forced to do that. Just as you can write
bad code in any other language, the same is most certainly true for js.

The secret is to use good development patterns. Do a quick search for
"javascript futures" and/or "javascript promises". Here's one article, though
a couple years old. <http://curtisb.posterous.com/what-are-futures-and-why-
shoul>

I've recently had(have) similar feelings as you've expressed, except towards
Backbone.js. I have spent the last couple of weeks trying over and over to
understand how to actually use the framework to do anything productive. I
conceptually understand and love the concepts it espouses. I even wrote a
small sample framework for my own edification that uses a module pattern, url
routing, and global events for intra-module communication but explicitly stays
away from trying to replicate models and views. That's something I was able to
write quickly and use immediately.

My problem with Backbone is the documentation and tutorials. While the docs
for Backbone itself is pretty good as far as laying out what the features are,
there's almost no information on how you should _structure_ a Backbone app. On
how everything links together. The tutorial apps that are linked to are little
more than sparsely documented bug-splats of code concluding, "Here's a working
app!".

I've read pretty much everything I can find on Backbone. I get what models,
collections, views, and routers are. I see how they are related and can
interact. (Though the relationships between collections and views is _not_
well defined, in my opinion.) I even bought the Peepcode Backbone.js tutorial
1st section. Everything I read seems to start simple, and then all progresses
along fine, and suddenly there's a sudden upsweep where we're writing
collections, and models, and parent views, and binding this function to
'this', all at the same time, in no particular order and without really
explaining why we're doing what we're doing, and then we're refreshing the
page and saying "Look, an app!"

So to bring this back to your comments about node.js, I totally understand the
frustration. For me, I understand there's something conceptual about Backbone
that hasn't _quite_ sunk in. I see the rough shape of the hole in the puzzle
but haven't quite figured out what shape the missing piece is yet. But once I
do, then everything else will suddenly make sense.

For you, I would recommend to keep working on it. If you have questions, talk
to people who write node apps. I wish I could find some people who actually
write Backbone to talk to.

Eventually you'll see how powerful it is. As examples, I have 2 apps running
right now on node. <http://jsonip.com> and <http://popped.at>.

jsonip.com supports a moderate volume of traffic. It briefly reached a couple
hundred thousand requests an hour a few weeks ago and barely blinked. Its
dropped back down to its normal volume since. Its only about 20 lines of code,
most of which isn't even the core part of the app.

Popped.at is another service I work on in my spare time. Little visitor
traffic, but it processes thousands of tweets a day (might be 10s of
thousands) in realtime barely using 2% cpu on the host.

I've also written other node.js apps that support high traffic volumes that
run quite nicely.

------
goatslacker
It seems your problems are with JavaScript and not node.js.

With all of the transpilers surfacing such as CoffeeScript, Roy,
ClojureScript, etc; you can program in an 'expressive' and 'natural' way and
use node.js as well.

I don't see the problem with that.

------
joshontheweb
What is your server-side language of choice? What kind of apps are you trying
to build? I find node.js to be a breath of fresh air when trying to build
real-time webapps. I think once you get over the initial unfamiliarity phase
you may change your mind, at least, I did.

