If it doesn't feel natural, it will be replaced. Sorry node.js
8 comments
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.
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.
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.
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.
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....
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....
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.
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.
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.
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.
* 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.
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.
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?
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.
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.
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.
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.
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)
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)
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... ;)
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.
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".
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.