CoffeeScript (http://coffeescript.org) is my attempt to solve this exact problem. Take the parts of JavaScript that work well, fix the broken areas (statements-vs-expressions, variable scoping, difficult prototype chains), add features (like the array comprehensions mentioned in the article) ... and compile it all to lowest-common-denominator JavaScript that runs just as fast as the JS-you-would-have-written-yourself, and runs just fine from V8 to IE6.
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.
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:
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.
He's not talking about features specific to the Node API, but to features present in V8 that are lacking in older versions of JScript, effectively. A lot of Node libraries use features like Array#forEach, Object.create, Array#indexOf, Function#bind, making libraries unusable in the browser, even when they should be able to run perfectly well there.
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)
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:
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.
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.
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.
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.
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.
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:
array[-1]
As an alias for
array[array.length - 1]
Unfortunately, we can't add the feature because you'd have to intercept "[]" at every call site. For example:
a[b]
Is a an array or an object? Is b a string or a number, and if so, is it negative? You just don't know at compile time, so we don't support the feature. This is just one example of something that would be nice to fix about JS, but can't be done cleanly -- there are plenty of others.
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...)
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.
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)
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.
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.
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).
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.
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.
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.
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.
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.
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 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.
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 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.
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 :-)
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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 ;)
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.
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.
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.
- 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.
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).
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.
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.
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.
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.
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.
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.
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.
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."
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.
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.