10 ms·

Why node.js disappoints me

63 points by twampss 16y ago

mdg 16y ago
The underlying problem is the kool aid drinking, not node.js
- mhd 16y ago
  I'd say the problem is people expecting that any new technology is revolutionary.
  - wccrawford 16y ago
    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.
  - points 16y ago
    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.
- njharman 16y ago
  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."
kls 16y ago
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.
- olalonde 16y ago
  I think a lot more people will start considering this possibility seriously the day Google announces it parses Javascript.
  - pilif 16y ago
    Google parses and executes JavaScript already. http://code.google.com/web/ajaxcrawling/docs/getting-started.html 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&q=site:tempalias.com+prune http://www.google.com/search?sourceid=chrome&ie=UTF-8&#3... 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 :-)
    - simonw 16y ago
      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 http://tempalias.com/#!/privacy Gets converted by their crawler in to this: http://tempalias.com/?_escaped_fragment_=/privacy 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.
icey 16y ago
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.
- mdg 16y ago
  Well some of the libraries out there are glue for C++ code. I think that is what he was inferring anyways.
  - icey 16y ago
    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.
    - _delirium 16y ago
      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.
      - icey 16y ago
        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.
- chewbranca 16y ago
  He's seems frustrated with available libraries that work both in user space and server side, and while I understand what he's getting at, I don't necessarily agree. There are efforts to bring the two together, such as Common.js, which definitely has a ways to go, but for right now, the server/client distinction still exists so there will be a natural distinction between code that runs in the client and code that runs on the server. I'm currently building a CouchApp which is a self contained CouchDB application written purely in javascript (html/css) from the ground up. All of the database views are in javascript, the frontend uses evently which is a utility library on top of jquery to facilitate working with events and having a clean interface for having events trigger your typical web stack events, database request, data processing, view generation from mustache templates all the while happening client side in the user's browser. So I can use jQuery utility functions to process the data returned from CouchDB, or I can do a console.log from my database query directly into the browser. There is still the natural divide between client/server, yes, jQuery is much more tightly integrated with the entire stack, but I'm still using standalone javascript at the database layer. There are some talks on the CouchDB mailing list to get Common.js into the view layer of CouchDB which is further bridging the gap between client/server code. I still feel there is a natural separation between the two, and while common libraries will make it much simpler to code across the stack, there will still be code that logically fits on one side or the other. That said, there are a lot of new javascript frameworks and tools that are really blurring the lines, like sammy.js, express.js for node.js, CouchApps, Soca (alternative CouchApps framework) and even YUI is usable to some extent in node.js. Personally I am very excited about the future of javascript in the application stack, and I for one am really liking being able to use javascript up and down the stack. The only thing really missing for me is a solid javascript UI, I'm keeping an eye on jquery's new toolkit.
xyzzyz 16y ago
Weblocks and Parenscript and CL-WHO and hu.dwim.perec and I write code in only one language too.
- mahmud 16y ago
  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.
gorm 16y ago
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.
endergen 16y ago
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.
Locke1689 16y ago
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?
- jadedoto 16y ago
  To which I ask you to check out Objective-J.
  - Locke1689 16y ago
    I actually have something in mind for a Master's thesis that may solve my problems permanently, but I'm afraid I have to keep it quiet for now. :)
- icey 16y ago
  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/ http://jashkenas.github.com/coffee-script/
  - silentbicycle 16y ago
    Flexible compared to what? Given the circumstances, that's definitely damning with faint praise.
    - icey 16y ago
      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.
COP 16y ago
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.
- dasil003 16y ago
  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.
didip 16y ago
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 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.
- jashkenas 16y ago
  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.
jashkenas 16y ago
CoffeeScript (http://coffeescript.org 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.
- SkyMarshal 16y ago
  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...)
- tlrobinson 16y ago
  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.
  - jashkenas 16y ago
    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.
dstein 16y ago
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 http://www.jaxscript.com Here's a screencast version of a presentation I did for a local user group: http://vimeo.com/15127654 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.
- auxbuss 16y ago
  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.
  - dstein 16y ago
    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.
- bobds 16y ago
  A screencast is not the appropriate way to introduce your code to developers. We want text.
  - silentbicycle 16y ago
    Seriously, we're not Ruby programmers. We can read, we don't need screencasts. ;)
tlrobinson 16y ago
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.
agentultra 16y ago
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.
sh1mmer 16y ago
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-manipulation-oh-my/ 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/ http://express.davglass.com/).
olsonjeffery 16y ago
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/ 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).
js4all 16y ago
The title is misleading. It is not node.js that disappoints you.
DjDarkman 16y ago
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.

63 points by twampss 16y ago

mdg 16y ago

The underlying problem is the kool aid drinking, not node.js

mhd 16y ago
I'd say the problem is people expecting that any new technology is revolutionary.
- wccrawford 16y ago
  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.
- points 16y ago
  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.
njharman 16y ago
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."

kls 16y ago

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.

olalonde 16y ago
I think a lot more people will start considering this possibility seriously the day Google announces it parses Javascript.
- pilif 16y ago
  Google parses and executes JavaScript already. http://code.google.com/web/ajaxcrawling/docs/getting-started.html 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&q=site:tempalias.com+prune http://www.google.com/search?sourceid=chrome&ie=UTF-8&#3... 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 :-)
  - simonw 16y ago
    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 http://tempalias.com/#!/privacy Gets converted by their crawler in to this: http://tempalias.com/?_escaped_fragment_=/privacy 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.

icey 16y ago

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.

mdg 16y ago
Well some of the libraries out there are glue for C++ code. I think that is what he was inferring anyways.
- icey 16y ago
  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.
  - _delirium 16y ago
    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.
    - icey 16y ago
      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.
chewbranca 16y ago
He's seems frustrated with available libraries that work both in user space and server side, and while I understand what he's getting at, I don't necessarily agree. There are efforts to bring the two together, such as Common.js, which definitely has a ways to go, but for right now, the server/client distinction still exists so there will be a natural distinction between code that runs in the client and code that runs on the server. I'm currently building a CouchApp which is a self contained CouchDB application written purely in javascript (html/css) from the ground up. All of the database views are in javascript, the frontend uses evently which is a utility library on top of jquery to facilitate working with events and having a clean interface for having events trigger your typical web stack events, database request, data processing, view generation from mustache templates all the while happening client side in the user's browser. So I can use jQuery utility functions to process the data returned from CouchDB, or I can do a console.log from my database query directly into the browser. There is still the natural divide between client/server, yes, jQuery is much more tightly integrated with the entire stack, but I'm still using standalone javascript at the database layer. There are some talks on the CouchDB mailing list to get Common.js into the view layer of CouchDB which is further bridging the gap between client/server code. I still feel there is a natural separation between the two, and while common libraries will make it much simpler to code across the stack, there will still be code that logically fits on one side or the other. That said, there are a lot of new javascript frameworks and tools that are really blurring the lines, like sammy.js, express.js for node.js, CouchApps, Soca (alternative CouchApps framework) and even YUI is usable to some extent in node.js. Personally I am very excited about the future of javascript in the application stack, and I for one am really liking being able to use javascript up and down the stack. The only thing really missing for me is a solid javascript UI, I'm keeping an eye on jquery's new toolkit.

xyzzyz 16y ago

Weblocks and Parenscript and CL-WHO and hu.dwim.perec and I write code in only one language too.

mahmud 16y ago
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.

gorm 16y ago

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.

endergen 16y ago

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.

Locke1689 16y ago

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?

jadedoto 16y ago
To which I ask you to check out Objective-J.
- Locke1689 16y ago
  I actually have something in mind for a Master's thesis that may solve my problems permanently, but I'm afraid I have to keep it quiet for now. :)
icey 16y ago
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/ http://jashkenas.github.com/coffee-script/
- silentbicycle 16y ago
  Flexible compared to what? Given the circumstances, that's definitely damning with faint praise.
  - icey 16y ago
    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.

COP 16y ago

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.

dasil003 16y ago
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.

didip 16y ago

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 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.

jashkenas 16y ago
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.

jashkenas 16y ago

CoffeeScript (http://coffeescript.org 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.

SkyMarshal 16y ago
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...)
tlrobinson 16y ago
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.
- jashkenas 16y ago
  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.

dstein 16y ago

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 http://www.jaxscript.com Here's a screencast version of a presentation I did for a local user group: http://vimeo.com/15127654 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.

auxbuss 16y ago
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.
- dstein 16y ago
  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.
bobds 16y ago
A screencast is not the appropriate way to introduce your code to developers. We want text.
- silentbicycle 16y ago
  Seriously, we're not Ruby programmers. We can read, we don't need screencasts. ;)

tlrobinson 16y ago

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.

agentultra 16y ago

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.

sh1mmer 16y ago

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-manipulation-oh-my/ 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/ http://express.davglass.com/).

olsonjeffery 16y ago

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/ 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).

js4all 16y ago

The title is misleading. It is not node.js that disappoints you.

DjDarkman 16y ago

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.