
Why node.js disappoints me - twampss
http://www.eflorenzano.com/blog/post/why-node-disappoints-me/
======
jashkenas
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.

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

~~~
tlrobinson
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...](http://github.com/280north/narwhal/blob/master/engines/default/lib/global-
es5.js)) 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)

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

------
kls
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
I think a lot more people will start considering this possibility seriously
the day Google announces it parses Javascript.

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

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

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

------
icey
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
Well some of the libraries out there are glue for C++ code. I think that is
what he was inferring anyways.

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

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

------
Locke1689
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?

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

~~~
Locke1689
<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>

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

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

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

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

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

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

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

------
sh1mmer
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...](http://www.yuiblog.com/blog/2010/04/09/node-js-yui-3-dom-manipulation-
oh-my/))

The latest demos of this have Expressjs being used to render using a YUI3
based templating (<http://express.davglass.com/>).

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

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

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

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

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

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

~~~
mhd
I'd say the problem is people expecting that any new technology is
revolutionary.

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

