Why node.js disappoints me(eflorenzano.com)
eflorenzano.com
Why node.js disappoints me
http://www.eflorenzano.com/blog/post/why-node-disappoints-me/
17 comments
Sorry, I accidentally downmodded you, so went through your comments and upvoted some to cancel.
(Using Epiphany browser for the first time today, and it seems to offset the upvote/downvote arrow links so that you have to click above the upvote arrow to upvote. Clicking the upvote arrow itself downvotes. Maybe this is a problem with its text zoom feature...)
(Using Epiphany browser for the first time today, and it seems to offset the upvote/downvote arrow links so that you have to click above the upvote arrow to upvote. Clicking the upvote arrow itself downvotes. Maybe this is a problem with its text zoom feature...)
I like CoffeeScript, but what does it have to do with Eric's complaints? It does nothing to prevent people from duplicating effort or tying libraries to a specific environment.
Eric complained about implementation-specific language features in JavaScript -- things that only run on some, but not all of: SpiderMonkey, V8, JScript, and Nitro. To quote:
CoffeeScript doesn't prevent you from using implementation-specific features if you want to, but provides in-language alternatives to all of the things listed above, in a cross-browser fashion.
Objective-J works in the same way, doesn't it? It's possible to write Objective-J code that is tied to a particular runtime, but if you write in the regular style, you won't have any cross-browser trouble.
Instead of coding in one language, we're actually coding
in two. One is the subset JavaScript that can be run in
all browsers, and another is the set of JavaScript that
can be run by Node.
CoffeeScript doesn't prevent you from using implementation-specific features if you want to, but provides in-language alternatives to all of the things listed above, in a cross-browser fashion.
Objective-J works in the same way, doesn't it? It's possible to write Objective-J code that is tied to a particular runtime, but if you write in the regular style, you won't have any cross-browser trouble.
When he said "language" I guess I automatically translated that to "APIs" since that's usually what people mean when they complain about incompatibility in JavaScript environments.
Differences in the JavaScript language in engines are fairly minimal these days (BTW all the features you mentioned can be added to legacy engines, see http://github.com/280north/narwhal/blob/master/engines/defau...) I think the bigger problem with sharing code between client and server is the libraries that unnecessarily tie themselves to APIs specific to each environment (i.e. the DOM and other browser APIs, and Node.js or other server-side APIs)
Differences in the JavaScript language in engines are fairly minimal these days (BTW all the features you mentioned can be added to legacy engines, see http://github.com/280north/narwhal/blob/master/engines/defau...) I think the bigger problem with sharing code between client and server is the libraries that unnecessarily tie themselves to APIs specific to each environment (i.e. the DOM and other browser APIs, and Node.js or other server-side APIs)
First -- your global-es5.js module is awesome. I frequently point folks to it for a way to bring old browsers up to speed. But at the same time, if you don't include a library like it, you have to admit that there are 30 core functions in there that it's easy to depend on, and that the global-es5 implementation isn't perfectly compatible with real browser implementations, it's just very close (Object.getPrototypeOf being a good example of something you can't fix).
The other approach, and the one that Eric is lamenting, is writing lowest-common-denominator JavaScript. The problem he calls out in Node isn't that it's not possible to write cross-implementation libraries -- but that people aren't doing it. There are tons of Node libraries which could very easily run in the browser, but don't. Just browsing through NPM, here are three random ones:
http://github.com/visionmedia/lingo/
http://github.com/Marak/Faker.js/
http://github.com/past/speller/
All of those do nothing Node-specific, but use JavaScript features that aren't present in IE6, 7, and 8.
The other approach, and the one that Eric is lamenting, is writing lowest-common-denominator JavaScript. The problem he calls out in Node isn't that it's not possible to write cross-implementation libraries -- but that people aren't doing it. There are tons of Node libraries which could very easily run in the browser, but don't. Just browsing through NPM, here are three random ones:
http://github.com/visionmedia/lingo/
http://github.com/Marak/Faker.js/
http://github.com/past/speller/
All of those do nothing Node-specific, but use JavaScript features that aren't present in IE6, 7, and 8.
I don't know if it matters per se, but I'm in IE7, and while the 'run this code' demos work on the site, almost nothing else does. Specifically, none of the buttons in the floating toolbar do anything.
Also, I can't read the first paragraph of text, as the toolbar is hovering over it.
Also, I can't read the first paragraph of text, as the toolbar is hovering over it.
While it's quite embarrassing in regards to this conversation, zero effort has gone into making the homepage render properly in IE. The language is quite another matter. After working around IE bugs all day, getting up motivation to tackle them for the homepage of personal project is difficult -- you want to draw a line in the sand, and say, not this time. But you're right, of course.
Edit: CSS updated, see below.
Edit: CSS updated, see below.
Oh no, I understand completely. If my personal homepage works in IE7, it's a fortunate, but unintended happening altogether.
That said, I was very interested in CoffeeScript as part of my job is to write new whiz-bang features into applications that run on older browsers (such as the IE7 I visited you on today.)
Bear in mind, CoffeeScript especially appeals to people in my position. It just sucks I can't read it / play with it now.
Still, I've bookmarked it for later reading from home, so hopefully I won't forget.
That said, I was very interested in CoffeeScript as part of my job is to write new whiz-bang features into applications that run on older browsers (such as the IE7 I visited you on today.)
Bear in mind, CoffeeScript especially appeals to people in my position. It just sucks I can't read it / play with it now.
Still, I've bookmarked it for later reading from home, so hopefully I won't forget.
I've pushed some CSS tweaks for IE to CoffeeScript.org -- it still won't look real pretty, but everything should be usable now. Should have done it a long time ago, thanks for the nudge.
They work like a champ, though I basically got what I wanted out of it last night at home.
Any idea how far away you are from putting out something one might consider 'stable'? I'm in the government, and it's effectively impossible to use 'beta' code here.
Any idea how far away you are from putting out something one might consider 'stable'? I'm in the government, and it's effectively impossible to use 'beta' code here.
The language syntax is pretty much stable at this point -- getting to 1.0 is now mainly a matter of shaking out the edge cases in parsing, and solidifying the compiler as much as possible.
Fortunately, you don't have to take my word for it. Even if the CoffeeScript compiler were to disappear in a puff of smoke this afternoon -- you'd still be left with pretty-printed, quite-readable JavaScript. It's not like depending on a beta of a VM or interpreter.
Fortunately, you don't have to take my word for it. Even if the CoffeeScript compiler were to disappear in a puff of smoke this afternoon -- you'd still be left with pretty-printed, quite-readable JavaScript. It's not like depending on a beta of a VM or interpreter.
do you think it's worth fixing deeper stuff, like arrays of numbers being lexically sorted?
There are lots of things that it would be wonderful to fix, but can't be done without either patching native objects, running an interpreter on top of JS, or adding lots of special functions in a required library.
Take, for example, negative array indices. It would be lovely if JS allowed you to say:
Take, for example, negative array indices. It would be lovely if JS allowed you to say:
array[-1]
array[array.length - 1]
a[b]
fair enough. i suppose ultimately the browser just needs a neutral vm.
I am of the opinion that there is no longer a need for server side templating languages and that they only serve to complicate the technology stack. With REST services, Javascript, CSS and HTML the technology stack for web development has become significantly simplified due to the fact that it is once again digestible. A designer can know HTML and CSS and provide designer services without having to know the intricacies of a back end technology (many times several) further they can graduate into JavaScript UI programming as they grow and gain experience. Finally they can grow into developing back end services. With modern web development the layers have become compartmentalized or black boxed to shield each layer from the implementation details of the others. This is a good thing because a new developer does not have to master "technology soup" to become the lowest level of proficient. With current trends in web development, server side UI frameworks make no sense. The take a longer development cycle and they produce inferior results.
I think a lot more people will start considering this possibility seriously the day Google announces it parses Javascript.
I won't. The web for me is URLs and HTML. JavaScript is for providing user experience enhancements on top of that. I don't want a Web which can only be understood by running a JavaScript interpreter against it.
I used to agree, but now I actually think there are two webs. There is the original web, the document web, but there is also the application web. Sometimes the two overlap, and almost every site has at least some documents that should be plain ol' HTML.
However in working on the application web for the last 5 years I've come to appreciate the power of new approaches for web-based user applications. It turns out that generating full HTML pages for users can turn into an incredible waste of resources and significantly worse UX, for what amounts to a very tiny accessibility and SEO advantage. Facebook is the canonical example here. The way they load a page is brilliant from a UX and server resource perspective.
But consider apps that are much less dynamic. Say you have a 50k page with 1k of dynamic content per user or some other variable such as country. Page caching is impossible. You can rig up all kinds of complex server side fragment caching mechanisms, and squeeze quite a bit of performance out. However these schemes quickly grow very complex, whereas the client/server architecture lends itself to a solution that is orders of magnitude more elegant, which is simply to load the dynamic bits via AJAX. This A) offloads processing to the client, B) solves all kinds of caching problems, allowing full HTTP caching where it would have been impossible, and bypasses hordes of thorny cache invalidation problems, C) creates some elegant optimizations that would have chicken-or-egg problems if attempted on a server-side MVC architecture alone, D) Improves page responsiveness dramatically as the initial HTML shell and static assets can start loading almost instantaneously, and E) allows a more de-coupled architecture that makes sharding and scaling much easier.
Because of the technical advantages, it's inevitable that web-based app development will continue moving in this direction. Web apps that don't go in this direction will be at a disadvantage from an operating cost and UX perspective.
However in working on the application web for the last 5 years I've come to appreciate the power of new approaches for web-based user applications. It turns out that generating full HTML pages for users can turn into an incredible waste of resources and significantly worse UX, for what amounts to a very tiny accessibility and SEO advantage. Facebook is the canonical example here. The way they load a page is brilliant from a UX and server resource perspective.
But consider apps that are much less dynamic. Say you have a 50k page with 1k of dynamic content per user or some other variable such as country. Page caching is impossible. You can rig up all kinds of complex server side fragment caching mechanisms, and squeeze quite a bit of performance out. However these schemes quickly grow very complex, whereas the client/server architecture lends itself to a solution that is orders of magnitude more elegant, which is simply to load the dynamic bits via AJAX. This A) offloads processing to the client, B) solves all kinds of caching problems, allowing full HTTP caching where it would have been impossible, and bypasses hordes of thorny cache invalidation problems, C) creates some elegant optimizations that would have chicken-or-egg problems if attempted on a server-side MVC architecture alone, D) Improves page responsiveness dramatically as the initial HTML shell and static assets can start loading almost instantaneously, and E) allows a more de-coupled architecture that makes sharding and scaling much easier.
Because of the technical advantages, it's inevitable that web-based app development will continue moving in this direction. Web apps that don't go in this direction will be at a disadvantage from an operating cost and UX perspective.
[deleted]
Google parses and executes JavaScript already.
http://code.google.com/web/ajaxcrawling/docs/getting-started...
that's where that exclamation mark in the hash of the URL in recent sites comes from (like new twitter)
Edit:
Look at this query:
http://www.google.com/search?sourceid=chrome&ie=UTF-8...
it finds the existence of that word on my privacy page that gets only loaded via AJAX. So it must be able execute the javascript (sammy, basically) that intercepts these links to load the correct page fragment.
Edit:
Explanation is wrong. It takes a little bit of server side magic to work. See comment below. I completely forgot about this after implementing it in April :-)
http://code.google.com/web/ajaxcrawling/docs/getting-started...
that's where that exclamation mark in the hash of the URL in recent sites comes from (like new twitter)
Edit:
Look at this query:
http://www.google.com/search?sourceid=chrome&ie=UTF-8...
it finds the existence of that word on my privacy page that gets only loaded via AJAX. So it must be able execute the javascript (sammy, basically) that intercepts these links to load the correct page fragment.
Edit:
Explanation is wrong. It takes a little bit of server side magic to work. See comment below. I completely forgot about this after implementing it in April :-)
Their Ajax crawling stuff doesn't work by executing JavaScript within their crawler. If you read the docs you linked to, they specify that this URL:
http://tempalias.com/#!/privacy
Gets converted by their crawler in to this:
http://tempalias.com/?_escaped_fragment_=/privacy
It's up to you to implement your server-side code such that ?_escaped_fragment_ causes an indexable version of your content to be served up.
http://tempalias.com/#!/privacy
Gets converted by their crawler in to this:
http://tempalias.com/?_escaped_fragment_=/privacy
It's up to you to implement your server-side code such that ?_escaped_fragment_ causes an indexable version of your content to be served up.
Of course you are right. It has been a while since I've done this. Sorry for the confusion. I totally forgot that :-)
Nothing about the idea requires abandoning HTML for content.
However, something like login management could be completely handled by an API. So the browser would be combining different sources of HTML into once package. This is pretty much what is happening with the Facebook "Like" button anyway.
There are a lot of sites out there which serve pages which are mostly static content with just a little bit extra -- the login name at the top, personalized tools here and there.
I happen to work with Wikipedia content, so that's top of my mind right now. If you are logged in, we give you content rendered mostly from scratch, since the caching system is optimized for the non-logged-in user and there are user preferences which might transform the content in complicated ways. (Even things like date formats are subject to user preferences, so it's considerably harder to cache). This works okay, but it's dramatically more expensive for logged in users. We would have to rethink things if we ever got to a world where a lot more people are logged in.
A paradigm I'd like to explore would be to fetch the static content from one set of servers, and login state and personal options and other transformations from another, and get the browser to combine it all. Probably won't ever happen on Wikipedia though, at least not soon.
However, something like login management could be completely handled by an API. So the browser would be combining different sources of HTML into once package. This is pretty much what is happening with the Facebook "Like" button anyway.
There are a lot of sites out there which serve pages which are mostly static content with just a little bit extra -- the login name at the top, personalized tools here and there.
I happen to work with Wikipedia content, so that's top of my mind right now. If you are logged in, we give you content rendered mostly from scratch, since the caching system is optimized for the non-logged-in user and there are user preferences which might transform the content in complicated ways. (Even things like date formats are subject to user preferences, so it's considerably harder to cache). This works okay, but it's dramatically more expensive for logged in users. We would have to rethink things if we ever got to a world where a lot more people are logged in.
A paradigm I'd like to explore would be to fetch the static content from one set of servers, and login state and personal options and other transformations from another, and get the browser to combine it all. Probably won't ever happen on Wikipedia though, at least not soon.
"Sites" vs. "apps."
agreed. My first bigger node project (http://tempalias.com) works without generating even a single byte of HTML dynamically on the server.
It's all plain HTML and JavaScript statically served and talking to the server via a REST API.
This way I don't have to "bolt on" an API that might be incomplete. Instead, the frontend uses exactly the same API as any prospective client would.
When I started the thing, I was using the Express framework, but soon began to feel exactly like the original poster. Express was porting Rails to Node and I wanted something else.
Hence I moved to paperboy to serve the static files and did the (simple!) API on my own - plugging paperboy into an existing node server with existing endpoints is incredibly easy (or I could serve the static files directly, but I wanted the code to work without external dependencies to help the community to get a service of their own to run).
If you are interested in the development (tempalias is MIT licensed and available at github), I would recommend you either the development journal (http://www.gnegg.ch/tag/tempalias) or the talk I gave at jsconf.eu (http://bit.ly/b4gsrL)
It's all plain HTML and JavaScript statically served and talking to the server via a REST API.
This way I don't have to "bolt on" an API that might be incomplete. Instead, the frontend uses exactly the same API as any prospective client would.
When I started the thing, I was using the Express framework, but soon began to feel exactly like the original poster. Express was porting Rails to Node and I wanted something else.
Hence I moved to paperboy to serve the static files and did the (simple!) API on my own - plugging paperboy into an existing node server with existing endpoints is incredibly easy (or I could serve the static files directly, but I wanted the code to work without external dependencies to help the community to get a service of their own to run).
If you are interested in the development (tempalias is MIT licensed and available at github), I would recommend you either the development journal (http://www.gnegg.ch/tag/tempalias) or the talk I gave at jsconf.eu (http://bit.ly/b4gsrL)
Thanks for the reply, my next project is going to be doing the REST services with Node. I have been using Java for my services because until Node I really did not see a big enough reason to move platforms. What are you using for your REST services implementation, a Node library or did you roll your own? I did not know about Paperboy so thanks for pointing me to that project.
in this case, the API was so simple, I could easily roll my own (it's not even a real framework - I have one resource, the alias and I allow basically just POST to /aliases to create one at the moment).
The beauty about node is that it's so simple to extend and add the functionality you need. No magic, no huge framework to learn.
The little things you get though work awesomely well and are a pleasure to use.
The beauty about node is that it's so simple to extend and add the functionality you need. No magic, no huge framework to learn.
The little things you get though work awesomely well and are a pleasure to use.
If you could find the time to shot me an email (possible with some samples, or some links) of how you did your REST services with Node, I would be forever in your debt. My email is in my profile if you get a chance.
if it wasn't a bit ugly (organically grown, just one endpoint), I'd direct you to the source code of the tempalias HTTP server.
You can still have a look at it. As I said though, it's really ugly and I should really split it up into multiple files, factor out the common stuff and make the whole thing more clear.
Still. Here goes:
http://github.com/pilif/tempalias/blob/master/lib/tempalias_...
Lines 30 and following handle calls to /aliases (in my case, that's just a POST to /aliases to create an alias - later I'd add PUT to /aliases/<id> to update it and DELETE /aliases/<id> to delete it - assuming that a correct update key (part of the response to creation) has been created.
As I said: Butt-ugly code. Don't do it like this - factor out common stuff, create smaller functions for the various parts of the needed setup.
You can still have a look at it. As I said though, it's really ugly and I should really split it up into multiple files, factor out the common stuff and make the whole thing more clear.
Still. Here goes:
http://github.com/pilif/tempalias/blob/master/lib/tempalias_...
Lines 30 and following handle calls to /aliases (in my case, that's just a POST to /aliases to create an alias - later I'd add PUT to /aliases/<id> to update it and DELETE /aliases/<id> to delete it - assuming that a correct update key (part of the response to creation) has been created.
As I said: Butt-ugly code. Don't do it like this - factor out common stuff, create smaller functions for the various parts of the needed setup.
Thanks don't worry about the ugly. We all have pieces we are not proud off. I would just like to see the basic of what you did so I have a head start when I jump into Node.
I can give you this, it is prettier than any code I have written in Node (if it is not apparent from my posts, I have not worked in Node).
I can give you this, it is prettier than any code I have written in Node (if it is not apparent from my posts, I have not worked in Node).
Post it here! Or someplace we can access, if it's useful.
Your ideas since this (http://news.ycombinator.com/item?id=898947) have been an eye opener to me. Definitely this just seems to make most parts easier and more testable and more distributed.
I'm thinking how the several parts web frameworks implement would work in the "Client/server 2.0" model. One of the parts I can't quite figure, probably because frameworks like Django hide it completely, is how would we implement sessions. I'm thinking about the user closing a page, then reopening and wanting to see their cart there, for example.
I'd love you if gave me more links to read to understand how I could implement this. I'm starting to write code for my startup and this model seems a perfect fit.
I'm thinking how the several parts web frameworks implement would work in the "Client/server 2.0" model. One of the parts I can't quite figure, probably because frameworks like Django hide it completely, is how would we implement sessions. I'm thinking about the user closing a page, then reopening and wanting to see their cart there, for example.
I'd love you if gave me more links to read to understand how I could implement this. I'm starting to write code for my startup and this model seems a perfect fit.
There are two schools of thought on session. On is that it should be avoided at all cost and believe that it is an ant-pattern The web was designed to be a stateless medium and session introduces state. Which causes all kinds of problems on a platform that was designed to be stateless.
While I agree with the line of reasoning, I consider myself pragmatic and therefore subscribe to the second school of though which is session should be guarded. Our system throws warning flags whenever someone checks in new code that uses session, it is then flagged for review.
We tend to try to build our services stateless by passing the relevant information needed to complete a transaction. You could think of the communication like this: one could be represented as a telephone call, where you have to have the context of previous messages to understand the communication (stateful), while the other could be though of like voice mails where the entire context of the communication is transmitted as a complete package.
We tend to try to design our services like the latter but some times it is not practical due to sensitive information or other concerns. This is where session comes into play.
So for us, how we build out services is that we generate an identity token (based on SAML), that token represents the users (authentication and authorization). Further we store any global information that is not sensitive in a cookie that way they can be passes with the context of the communication to make a full stateless call to a service.
Finally, if there is a special case, that requires performance we will place that information in session for a user, we find that these cases are rarer than one would expect.
I am working on a blog: http://www.httparchitect.com it is by no means ready for prime time, but if you want to check it out it does have links to reference material. My next article was actually going to be on session management and statelessness.
While I agree with the line of reasoning, I consider myself pragmatic and therefore subscribe to the second school of though which is session should be guarded. Our system throws warning flags whenever someone checks in new code that uses session, it is then flagged for review.
We tend to try to build our services stateless by passing the relevant information needed to complete a transaction. You could think of the communication like this: one could be represented as a telephone call, where you have to have the context of previous messages to understand the communication (stateful), while the other could be though of like voice mails where the entire context of the communication is transmitted as a complete package.
We tend to try to design our services like the latter but some times it is not practical due to sensitive information or other concerns. This is where session comes into play.
So for us, how we build out services is that we generate an identity token (based on SAML), that token represents the users (authentication and authorization). Further we store any global information that is not sensitive in a cookie that way they can be passes with the context of the communication to make a full stateless call to a service.
Finally, if there is a special case, that requires performance we will place that information in session for a user, we find that these cases are rarer than one would expect.
I am working on a blog: http://www.httparchitect.com it is by no means ready for prime time, but if you want to check it out it does have links to reference material. My next article was actually going to be on session management and statelessness.
In this (http://news.ycombinator.com/item?id=1628991) comment you give an example of a cart, and how it shouldn't be bounced between client and server all the time, but be carried with the client which sends it in the end, when its done.
I'm trying to understand: how can you keep a Javascript object (the Cart array, lets say) between pages?
I'm trying to understand: how can you keep a Javascript object (the Cart array, lets say) between pages?
I would design my cart widget so that it does not require multiple pages that way it stays memory resident. The entire cart workflow would exist in a shopping cart widget. Further we designed a routine that wires into the page load and unload that does the following. Any data marked as persitable is stuffed into client side storage (we use Dojo so it figures out where it can store stuff, Cookie, Flash, IFrame). The routine looks for stuff stored in this segment when a page loads and pulls it back into memory and flushes the data from storage. On unload it repeats the process of serializing marked data. If you absolutely need a multi-page model you can use a similar pattern.
Interesting. I was thinking about using something like a hidden frame. Some StackOverflow posts mention storing data in "window.name". But we need something secure to store the user auth token...
You should consider using one of the toolkits, many of them have something akin to Dojo's storage http://ajaxian.com/archives/dojostorage-offline-access-and-p... . This buffers you from the implementation details and as newer browsers come along they are able to update the implementation to take advantage of newer browsers built in databases, while providing you with the same backwards compatible API. If you have not chosen one, I recommended you take a look at Dojo, if you are going to build a full on web app and jQuery if you have lighter requirements.
Side note: we are really starting to side track this thread, why don't you email me (in my profile) or add me to your contacts in Skype (if you use Skype) that way you can hit me up on any questions you have.
Side note: we are really starting to side track this thread, why don't you email me (in my profile) or add me to your contacts in Skype (if you use Skype) that way you can hit me up on any questions you have.
I did send an email yesterday, the title is "Your approach to web development. I realize now that the title might look like SPAM :) Anyway those questions were answered, I'll send you another one.
> I am of the opinion that there is no longer a need for server side templating languages
This makes the assumption that all apps are dumb frontends to a database.
This makes the assumption that all apps are dumb frontends to a database.
No it makes the assumption that UI logic provides the best user experience when it is closest to the UI. Services can provide any form of calculation logic that one needs them too. UI logic is removed from the server and placed with the UI while business logic and data services remain with the business systems.
> This makes the assumption that all apps are dumb frontends to a database.
I think the commenter is talking specifically about templating languages, not all server-side logic. In terms of MVC, I think the idea is that now you can move the entire view layer to the client, rather than doing half on the server and half in JavaScript.
I think the commenter is talking specifically about templating languages, not all server-side logic. In terms of MVC, I think the idea is that now you can move the entire view layer to the client, rather than doing half on the server and half in JavaScript.
Right, my point was that templating was a concern of the UI, yet I wanted to be clear that business logic and data services remain the domain of the application server. Further I try to remove templating from any run-time concern (server or client) by doing all static content templating in a CMS and then publishing it to a web server.
OK, sorry, I misunderstood your point.
Yes, it makes a lot of sense to do Javascript server-side for templating (client-side only is still tricky because of concerns related to crawlers, like search-engines).
But on the other hand, I would prefer the JVM with Rhino, not Node.js ... especially since using Java NIO you can have scalability for I/O bound requests similar to Node.js.
Yes, it makes a lot of sense to do Javascript server-side for templating (client-side only is still tricky because of concerns related to crawlers, like search-engines).
But on the other hand, I would prefer the JVM with Rhino, not Node.js ... especially since using Java NIO you can have scalability for I/O bound requests similar to Node.js.
No I don't do any templating server side, it is a waste of server resources. So all of our templating Header, footer, static articles are in a CMS all dynamic elements are done via JavaScript. We use a headless web browser to serve pages to crawlers from a dedicated server. It acts as a parser for the crawlers and when it sees a crawler agent and the hash mark it acts as the client Javascript engine and composites the page. This way, we don't have a hand coded solution for a platform problem that is infrastructure related.
Why? You can have arbitrarily complex logic and computation in client-side JavaScript. Whether it's a good idea is another question.
[deleted]
While GWT, Pyjamas, and other such toolkits have a ways to go I think there is some reason to believe that in the end they might work out.
For example, Pyjamas just got a kickstart in development (again) and released a compiler that can target both javascript and GTK from a single codebase. It also incorporates a JSON-RPC client, effectively abstracting out backend calls into what appear to be normal Python methods in the source.
My idea was to couple Pyjamas as an alternative front-end to normal template packages. You could theoretically write your entire application, UI code and all, in normal Python. The UI code would be heavily coupled to your backend code as if there were no seperation between the two. Once compiled to the javascript target, the interface should work just as well without any notice from you, the humble developer (making calls over JSON-RPC).
Check out my fork of Pylons on bitbucket to see how I've made wsgi apps speak json-rpc. It's a start. The problem right now is that I've heard many people moan that Pyjamas (and even GWT for that matter) do not spit out the best js. Something that could use improvement over time (and something I think will as long as there are interested developers). Either way, the next step is to write a paster template plugin to setup a project for using Pyjamas and a distribute pluging to add a compilation step to the build process.
For example, Pyjamas just got a kickstart in development (again) and released a compiler that can target both javascript and GTK from a single codebase. It also incorporates a JSON-RPC client, effectively abstracting out backend calls into what appear to be normal Python methods in the source.
My idea was to couple Pyjamas as an alternative front-end to normal template packages. You could theoretically write your entire application, UI code and all, in normal Python. The UI code would be heavily coupled to your backend code as if there were no seperation between the two. Once compiled to the javascript target, the interface should work just as well without any notice from you, the humble developer (making calls over JSON-RPC).
Check out my fork of Pylons on bitbucket to see how I've made wsgi apps speak json-rpc. It's a start. The problem right now is that I've heard many people moan that Pyjamas (and even GWT for that matter) do not spit out the best js. Something that could use improvement over time (and something I think will as long as there are interested developers). Either way, the next step is to write a paster template plugin to setup a project for using Pyjamas and a distribute pluging to add a compilation step to the build process.
It sounds like the problem he's having isn't with Node, but with the libraries people have built on top of node.
He's arguing that somehow using libraries makes it a "different language" than the one you'd use in the browser.
He's arguing that somehow using libraries makes it a "different language" than the one you'd use in the browser.
Well some of the libraries out there are glue for C++ code. I think that is what he was inferring anyways.
I don't see how the argument is any different than saying you have to use a "different Python" for web development and client-server development.
It's a little bigger consideration in this case imo, because one of the big selling points is the ability to do "JS everywhere" and share code between the browser and server side of apps. Not that that's the only reason node.js exists, but it's a nice aspect that becomes harder if the server and browser sides diverge more.
Ah, if that's the case then I misread.
If the problem is the broken promise of writing code once than runs perfectly well on the server or in the browser then I guess I could see the frustration. Although, I'm not sure that's an entirely realistic expectation given the different roles you'd expect the server and client to fill.
If the problem is the broken promise of writing code once than runs perfectly well on the server or in the browser then I guess I could see the frustration. Although, I'm not sure that's an entirely realistic expectation given the different roles you'd expect the server and client to fill.
When I started doing server side JavaScript a few years ago I was frustrated by JavaScript libraries which were unnecessarily tied to browser-specific APIs like the DOM. That seems to have been somewhat fixed. Now I'm frustrated by the reverse.
The first step to fixing this is getting good implementations of CommonJS modules in the browser. JavaScript needs a module system (no, <script> tags are not good enough) and CommonJS is the closest thing we have to a standard that can be added to existing environments.
Also important for interoperability is making sure people don't use proprietary extensions to CommonJS modules, which Node unfortunately has plenty of.
The first step to fixing this is getting good implementations of CommonJS modules in the browser. JavaScript needs a module system (no, <script> tags are not good enough) and CommonJS is the closest thing we have to a standard that can be added to existing environments.
Also important for interoperability is making sure people don't use proprietary extensions to CommonJS modules, which Node unfortunately has plenty of.
I don't understand the applause for Javascript. Yeah, we've unified on one language for client-side and server-side, but I don't like programming in Javascript. Why would I move to Javascript for server-side when I could program in Python and minimize the amount of JS I actually have to write?
Does everyone just like Javascript?
Does everyone just like Javascript?
Javascript is fun because it is flexible.
If you don't like the syntax, you could play around with Coffeescript. It may appeal to your Pythonic sensibilities: http://jashkenas.github.com/coffee-script/
If you don't like the syntax, you could play around with Coffeescript. It may appeal to your Pythonic sensibilities: http://jashkenas.github.com/coffee-script/
Flexible compared to what? Given the circumstances, that's definitely damning with faint praise.
Flexible compared to languages that don't use prototypal inheritance. Metaprogramming is part of every-day use for js developers; and it's a frequently used (and yes, sometimes abused) tool. As a result, developers can significantly change the way the language itself functions.
While this is amazing for smaller groups of disciplined developers; it can certainly cause maintenance pain. So, I guess I'd flip it around and call it praise with faint damnation.
While this is amazing for smaller groups of disciplined developers; it can certainly cause maintenance pain. So, I guess I'd flip it around and call it praise with faint damnation.
Ok, just curious. I use Lua quite a bit, and I find its mix of prototype-based OO and clean functional programming to be very practical, as well.
It sounds like other people find the same pragmatism in Javascript, but after learning Lua, I find Javascript really depressing - it had so much potential, but...it's like Lua's little brother whose mind never had a chance to fully develop (due to the browser wars). It's sad. Lua's design has been refined for 17 years, and ... Javascript was frozen after 2. Just reading about thruth-y and false-y types in Javascript makes me cringe.
Granted, Lua doesn't have the strangehold on web development that Javascript does (it was designed for scripting C/C++ instead, like Tcl), but I'm working on that.
It sounds like other people find the same pragmatism in Javascript, but after learning Lua, I find Javascript really depressing - it had so much potential, but...it's like Lua's little brother whose mind never had a chance to fully develop (due to the browser wars). It's sad. Lua's design has been refined for 17 years, and ... Javascript was frozen after 2. Just reading about thruth-y and false-y types in Javascript makes me cringe.
Granted, Lua doesn't have the strangehold on web development that Javascript does (it was designed for scripting C/C++ instead, like Tcl), but I'm working on that.
That was my reaction to Node.js. "So...I can use...Javascript?"
I have been sad for a long time that there is a language, just one, that you use for web browsers. And one that has an ad-hoc design like this. I've never really been a fan, and have been waiting for someone to expose a properly jailed VM to the web developer.
The JVM, incidentally, has Javascript support (Rhino), the choice of plenty of languages, and is relatively easy to restrict. Imagine a Webkit-based browser that handles Javascript and JVM bytecode. It would take some hacking, but you could have a safe, language-independent environment for client-side web scripting. Your One Application Language could be Javascript, Scheme, Python, Ruby, Scala, Clojure. I think devs would flock to this; I certainly would.
I have been sad for a long time that there is a language, just one, that you use for web browsers. And one that has an ad-hoc design like this. I've never really been a fan, and have been waiting for someone to expose a properly jailed VM to the web developer.
The JVM, incidentally, has Javascript support (Rhino), the choice of plenty of languages, and is relatively easy to restrict. Imagine a Webkit-based browser that handles Javascript and JVM bytecode. It would take some hacking, but you could have a safe, language-independent environment for client-side web scripting. Your One Application Language could be Javascript, Scheme, Python, Ruby, Scala, Clojure. I think devs would flock to this; I certainly would.
A big problem is that the largest source of frustration with javascript is DOM incompatibility rather than JS itself. At least the unified language allows projects like jQuery to partially clean up the mess for everyone. If you had multiple languages, imagine the mess.
Incompatibility is certainly a headache, but having worked on a 10k-line, Firefox-only Javascript project, I can say with confidence that there are a number of pain-points in the language itself.
Scoping weirdness, the erratic semantics of the 'this' keyword, etc.
If you had multiple languages atop a VM, it would be simpler, in fact. The browser only needs to worry about bytecode, except in the case of Javascript, where the inclusion of Rhino (or its equivalent) would be needed for pragmatic reasons. Any hooks into the DOM would be exposed through the VM, and a sensible way to talk to the VM would be the language implementor's problem.
Scoping weirdness, the erratic semantics of the 'this' keyword, etc.
If you had multiple languages atop a VM, it would be simpler, in fact. The browser only needs to worry about bytecode, except in the case of Javascript, where the inclusion of Rhino (or its equivalent) would be needed for pragmatic reasons. Any hooks into the DOM would be exposed through the VM, and a sensible way to talk to the VM would be the language implementor's problem.
Have you ever taken the time to learn it? JavaScript is a pretty neat little language - the way it does functions and closures allows for a programming style that doesn't really work in Python (due to the lack of multi-line lambdas).
My eyes were first opened to JavaScript during my Computer Science degree, during a course on Programming Languages - the professor spent a full lecture on how interesting it is, and it completely changed my opinion of the language.
My eyes were first opened to JavaScript during my Computer Science degree, during a course on Programming Languages - the professor spent a full lecture on how interesting it is, and it completely changed my opinion of the language.
<rant>
Have you ever taken the time to learn it? JavaScript is a pretty neat little language - the way it does functions and closures allows for a programming style that doesn't really work in Python (due to the lack of multi-line lambdas).
Yes, I have, that's why I said I don't like programming in Javascript, not that I don't know Javascript. Most of the design decisions serve to frustrate me more than empower me. The variable context I'm working in always seems always a bit mystical. Their method of FFF has a lisp air but they way it's written always makes it seem like more of a bastardization than an homage.
Python doesn't have multiline anonymous functions, but it does have inner functions. Given that I find the style of doSomething(function () { something; something; something; }); verbose and confusing, I prefer Python's implementation.
In Javascript there is More Than One Way To Do It(TM). Sometimes I don't mind this -- writing Haskell has never felt anything like writing Python. In fact, writing Haskell almost feels like writing a proof (and for good reason, look into the type system theoretics if you're interested) instead of a program. Therefore when writing Haskell I never feel like I need to make a comparison to languages like Python. They work differently and will be used by for different things.
Javascript, on the other hand, feels bland and conventional and begs for me to compare it to languages like Python. When I do I realize that the modularity, import system, and library of functions I've written in Python have disappeared into the wind, along with the ability to jump to C when necessary for performance.
In fact, when it comes to performance, Javascript is the worst! Not that Javascript performance itself is terrible as a scripting language, but that There Is More Than One Way To Do It but Only One Way Is Fast. The JQuery author is an expert at this, as well as some of my good friends at Google. There's always been a Book of Javascript, passed from developer to developer, that says what the Fast Way is. I hate that. I don't want to have to memorize idioms if I want my code to be performant. In summary, I guess, I want Python ;)
</rant>
Have you ever taken the time to learn it? JavaScript is a pretty neat little language - the way it does functions and closures allows for a programming style that doesn't really work in Python (due to the lack of multi-line lambdas).
Yes, I have, that's why I said I don't like programming in Javascript, not that I don't know Javascript. Most of the design decisions serve to frustrate me more than empower me. The variable context I'm working in always seems always a bit mystical. Their method of FFF has a lisp air but they way it's written always makes it seem like more of a bastardization than an homage.
Python doesn't have multiline anonymous functions, but it does have inner functions. Given that I find the style of doSomething(function () { something; something; something; }); verbose and confusing, I prefer Python's implementation.
In Javascript there is More Than One Way To Do It(TM). Sometimes I don't mind this -- writing Haskell has never felt anything like writing Python. In fact, writing Haskell almost feels like writing a proof (and for good reason, look into the type system theoretics if you're interested) instead of a program. Therefore when writing Haskell I never feel like I need to make a comparison to languages like Python. They work differently and will be used by for different things.
Javascript, on the other hand, feels bland and conventional and begs for me to compare it to languages like Python. When I do I realize that the modularity, import system, and library of functions I've written in Python have disappeared into the wind, along with the ability to jump to C when necessary for performance.
In fact, when it comes to performance, Javascript is the worst! Not that Javascript performance itself is terrible as a scripting language, but that There Is More Than One Way To Do It but Only One Way Is Fast. The JQuery author is an expert at this, as well as some of my good friends at Google. There's always been a Book of Javascript, passed from developer to developer, that says what the Fast Way is. I hate that. I don't want to have to memorize idioms if I want my code to be performant. In summary, I guess, I want Python ;)
</rant>
Have you ever looked into Lua? It's like a more mature version of Javascript. The overall design has a lot in common, but unlike JS, Lua didn't get frozen before its early design errors could be fixed (due to the browser wars) - instead it has had 15+ years of gradual refinement.
It's targeted at scripting C / C++ applications rather than web sites. It's great as a standalone scripting language, too.
It's targeted at scripting C / C++ applications rather than web sites. It's great as a standalone scripting language, too.
I like JS for serving as an assembly language for the web - it's not theoretically ideal, but no assembly language really is.
You have an ever-increasing set of options for compiling non-JS code into JS. Just poke around a little - you could use haXe, CoffeeScript, ParenScript, Objective-J, Pyjamas, GWT, Fantom...
Any platform - browser, server, etc. - that supports JS can reap the benefits of these alternative languages - just get your APIs ported and you're most of the way there.
You have an ever-increasing set of options for compiling non-JS code into JS. Just poke around a little - you could use haXe, CoffeeScript, ParenScript, Objective-J, Pyjamas, GWT, Fantom...
Any platform - browser, server, etc. - that supports JS can reap the benefits of these alternative languages - just get your APIs ported and you're most of the way there.
I'll probably get downvoted (again) for tooting my own horn, but I am developing a JavaScript framework to definitively solve the JavaScript templating problem.
http://www.jaxscript.com
Here's a screencast version of a presentation I did for a local user group: http://vimeo.com/15127654
The technology works, it's really, really solid. I think all server-side template languages are going to be obsolete a lot faster than most developers are prepared for.
http://www.jaxscript.com
Here's a screencast version of a presentation I did for a local user group: http://vimeo.com/15127654
The technology works, it's really, really solid. I think all server-side template languages are going to be obsolete a lot faster than most developers are prepared for.
Interesting idea. A few comments:
- It would be nice to see some more detail on your page. Writing stuff down might help with ideas too.
- The video is too laboured. Too slow. I lasted 9 minutes, and was very interested, but that was as long as I could last. You need to script video fairly tightly to hold folk's attention. You can get away with more space when live, but it doesn't translate to video. There's a reason film makers storyboard.
Anyway, I look forward to hearing about progress. I've just started exploring PhoneGap, so what you are doing is definitely of interest.
- It would be nice to see some more detail on your page. Writing stuff down might help with ideas too.
- The video is too laboured. Too slow. I lasted 9 minutes, and was very interested, but that was as long as I could last. You need to script video fairly tightly to hold folk's attention. You can get away with more space when live, but it doesn't translate to video. There's a reason film makers storyboard.
Anyway, I look forward to hearing about progress. I've just started exploring PhoneGap, so what you are doing is definitely of interest.
Yeah I know what you mean. I'm not terribly experienced with screencasts, and I did this one mainly for practice before a live presentation. I posted it for people who weren't in attendance, but thought perhaps others might be interested.
A screencast is not the appropriate way to introduce your code to developers. We want text.
Seriously, we're not Ruby programmers. We can read, we don't need screencasts. ;)
He misses the point. You still need to operate in two different environments, but it's possible to share a large set of code, business logic and helper functionality.
tl;dr -- if the only reason you'd consider "swallowing the bitter pill" of programming in JS on the server is because of the fallacy that you can get a single codebase for the client and server, then node isn't for you.
Way to knock down the straw man, you really showed 'em.
Look around on http://nodejs.org/ and tell me where I can read that one of node's stated goals was to facilitate a single codebase between the client and server?
Head on over to the node.js mailing list and you'll find a very sharply divided community when it comes to this question (one codebase for client/server), not surprisingly.
In my opinion, many (although certainly not all) of the people out there talking about one-codebase-to-rule-them-all are doing so mostly out of a shallow grasp of the domains in question. I'm not trying to be derisive here or bring the wrath of the gods down upon me, but you just have to accept that the client and server are different environments/platforms, period. Attempts to seek the "silver bullet" in this regard will end as most, if not all, other such attempts have: outright failure or, at best, mediocrity.
Putting the merits (or lack thereof) of my previous paragraph aside, if the question in your mind that follows from that is: "then why use node? javascript blows/is meh/is not ruby/etc?", well, I would respectfully beg to differ. The laissez-faire nature of javascript is pretty empowering, to me, and I enjoy it greatly. Additionally, node.js is novel in the manner in which is leverages the power of V8 and is built from, basically, the bare-metal on-up as an evented architecture (the same cannot be said for twisted or eventmachine). It's more than just throwing a bone to developers with a predominantly client/javascript-based portfolio and I think it's disingenuous to dismiss or characterize node's appeal as such (and yeah, now I'm building the straw men).
Way to knock down the straw man, you really showed 'em.
Look around on http://nodejs.org/ and tell me where I can read that one of node's stated goals was to facilitate a single codebase between the client and server?
Head on over to the node.js mailing list and you'll find a very sharply divided community when it comes to this question (one codebase for client/server), not surprisingly.
In my opinion, many (although certainly not all) of the people out there talking about one-codebase-to-rule-them-all are doing so mostly out of a shallow grasp of the domains in question. I'm not trying to be derisive here or bring the wrath of the gods down upon me, but you just have to accept that the client and server are different environments/platforms, period. Attempts to seek the "silver bullet" in this regard will end as most, if not all, other such attempts have: outright failure or, at best, mediocrity.
Putting the merits (or lack thereof) of my previous paragraph aside, if the question in your mind that follows from that is: "then why use node? javascript blows/is meh/is not ruby/etc?", well, I would respectfully beg to differ. The laissez-faire nature of javascript is pretty empowering, to me, and I enjoy it greatly. Additionally, node.js is novel in the manner in which is leverages the power of V8 and is built from, basically, the bare-metal on-up as an evented architecture (the same cannot be said for twisted or eventmachine). It's more than just throwing a bone to developers with a predominantly client/javascript-based portfolio and I think it's disingenuous to dismiss or characterize node's appeal as such (and yeah, now I'm building the straw men).
Node's strength are in doing streaming UIs. Like realtime twitter feeds that push new tweets to the UI the moment they come in. It also does allow sharing code such as client side and server side validation. And if you use require.js you can develop modules that work server aide and client side.
Node.js does add new features, it's ease of use is a feature. Server side push used to be more complicated than it had to be. Python has twisted which I found difficult to setup as it required Python skills which I was rusty on and was more abstracted than I needed.
And of course server side JavaScript really is great, I don't see how it's that hard to understand two environments. You can't get rid of that they are different environments but they can share much code and does require one less language to use than most web app frameworks.
Node.js does add new features, it's ease of use is a feature. Server side push used to be more complicated than it had to be. Python has twisted which I found difficult to setup as it required Python skills which I was rusty on and was more abstracted than I needed.
And of course server side JavaScript really is great, I don't see how it's that hard to understand two environments. You can't get rid of that they are different environments but they can share much code and does require one less language to use than most web app frameworks.
The beauty of javascript is that it is supported in multiple environments (various browsers, rhino, v8, etc). But with that comes VM specific implementations, and that's real life.
To truly achieve what the author said, programmer has to dumb-down their javascript to the lowest common denominator. Or have one common library to make sure all javascript features are supported, even if some have to be written in javascript.
Take array comprehension for example (https://developer.mozilla.org/en/New_in_JavaScript_1.7). Rhino, since it's a Mozilla thing, supports it. How about IE? I'm not sure if V8 even supports that.
Separation between server side and client side is bound to happen. Especially since it's a lot easier to use bleeding edge features on server side.
To truly achieve what the author said, programmer has to dumb-down their javascript to the lowest common denominator. Or have one common library to make sure all javascript features are supported, even if some have to be written in javascript.
Take array comprehension for example (https://developer.mozilla.org/en/New_in_JavaScript_1.7). Rhino, since it's a Mozilla thing, supports it. How about IE? I'm not sure if V8 even supports that.
Separation between server side and client side is bound to happen. Especially since it's a lot easier to use bleeding edge features on server side.
Except that there are plenty of cross-browser-incompatible features that aren't exactly "bleeding-edge", unfortunately.
For example, in IE < 9, there is no implementation of "Array#indexOf" -- the only way to check if a value is present in an array is to write out a loop to check each element.
For example, in IE < 9, there is no implementation of "Array#indexOf" -- the only way to check if a value is present in an array is to write out a loop to check each element.
I think the author has a valid point, but I disagree with his tone. I feel like those of us who were speaking about this early on always said that the browser would be the constraint.
This is why Yahoo has been working on using YUI3 in Node to offer an API layer that works both in the browser and the server. (http://www.yuiblog.com/blog/2010/04/09/node-js-yui-3-dom-man...)
The latest demos of this have Expressjs being used to render using a YUI3 based templating (http://express.davglass.com/).
This is why Yahoo has been working on using YUI3 in Node to offer an API layer that works both in the browser and the server. (http://www.yuiblog.com/blog/2010/04/09/node-js-yui-3-dom-man...)
The latest demos of this have Expressjs being used to render using a YUI3 based templating (http://express.davglass.com/).
I came into this one language concept in 2006. Back then there were already helma.org, which has functionality of RoR but it has being around since 1999.
Now Helma NG is relunched as RingoJS.org I would highly recommend checking it out.
Now Helma NG is relunched as RingoJS.org I would highly recommend checking it out.
Wow you really missed the boat. You should have checked out Foobar FU which had Rails 3 functionality back in 1995. The one-language thing was already played out by 2004.
Actually this is not Node.js's fault, you could easily create your own templating library that suits your purpose. Node is not an all in one solution.
Weblocks and Parenscript and CL-WHO and hu.dwim.perec and I write code in only one language too.
There is a good chance you might lose doing that.
Use Lisp for its strengths, and other technologies for theirs. Server side CL, client side jQuery, Postgres on the backend, and your choice of caches, proxies and middle-ware in between.
I have tried nearly every other combination of New Thing and Hyped Awesome, and came to this conclusion: don't do everything yourself, and don't use technologies others are not investing big $ in. Anyone can push something to github and launch a nice tryfoo.org site, that doesn't mean you should use it.
FWIW, I am migrating my entire web toolchain to the JVM and intend to start writing servlets in Lisp. Let Big Business be my R&D bitch. JVM is good enough, and it's posh.
Use Lisp for its strengths, and other technologies for theirs. Server side CL, client side jQuery, Postgres on the backend, and your choice of caches, proxies and middle-ware in between.
I have tried nearly every other combination of New Thing and Hyped Awesome, and came to this conclusion: don't do everything yourself, and don't use technologies others are not investing big $ in. Anyone can push something to github and launch a nice tryfoo.org site, that doesn't mean you should use it.
FWIW, I am migrating my entire web toolchain to the JVM and intend to start writing servlets in Lisp. Let Big Business be my R&D bitch. JVM is good enough, and it's posh.
The title is misleading. It is not node.js that disappoints you.
The underlying problem is the kool aid drinking, not node.js
I'd say the problem is people expecting that any new technology is revolutionary.
I think the underlying problem is programmers who aren't very good at programming. That means they're constantly on the look out for some magic potion that will make it easier for them.
Of course some things do make it easier - frameworks, libraries etc. But they often only make it easier at the start before your project gets complex and needs custom out of the box things.
Programmers should just knuckle down and try to improve their skills rather than chasing the latest fads.
Of course some things do make it easier - frameworks, libraries etc. But they often only make it easier at the start before your project gets complex and needs custom out of the box things.
Programmers should just knuckle down and try to improve their skills rather than chasing the latest fads.
Or expecting that new things will work with everything immediately, and be perfect.
His main gripe here is that the server's javascript and the browsers' javascript isn't 100% the same, and that current libraries don't run on both.
Jeez, give it some time. Or better yet, work on it.
His main gripe here is that the server's javascript and the browsers' javascript isn't 100% the same, and that current libraries don't run on both.
Jeez, give it some time. Or better yet, work on it.
Yes, but imho the kool aid is believing that there is (or even should be) "one language to rule them all".
node.js is neat but it's also immature and incomplete. There are all types of "applications" were it would be a good choice or at least worth consideration. But if you pick it (because you know javascript and don't wanna learn Erlang) over say Erlang/OTP for serious a/o large production deployment you're probably and idiot and certainly a "too much kool aid drinker."
node.js is neat but it's also immature and incomplete. There are all types of "applications" were it would be a good choice or at least worth consideration. But if you pick it (because you know javascript and don't wanna learn Erlang) over say Erlang/OTP for serious a/o large production deployment you're probably and idiot and certainly a "too much kool aid drinker."
If you want JS with nice features, and not to have to worry about JS language support, do yourself a favor and check it out.