Why node.js disappoints me

http://www.eflorenzano.com/blog/post/why-node-disappoints-me/

by twampss • 16 years ago

63 88 16 years ago

eflorenzano.com

_3ex72• 16 years ago

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

mhd• 16 years ago

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

wccrawford• 16 years 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• 16 years 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• 16 years 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."

kls10• 16 years 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• 16 years ago

I think a lot more people will start considering this possibility seriously the day Google announces it parses Javascript.

pilif5• 16 years ago

Google parses and executes JavaScript already.

http://code.google.com/web/ajaxcrawling/docs/getting-started...

that's where that exclamation mark in the hash of the URL in recent sites comes from (like new twitter)

Edit:

Look at this query:

http://www.google.com/search?sourceid=chrome&ie=UTF-8...

it finds the existence of that word on my privacy page that gets only loaded via AJAX. So it must be able execute the javascript (sammy, basically) that intercepts these links to load the correct page fragment.

Edit:

Explanation is wrong. It takes a little bit of server side magic to work. See comment below. I completely forgot about this after implementing it in April :-)

simonw3• 16 years ago

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.

neilk• 16 years ago

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.

percept2• 16 years ago

"Sites" vs. "apps."

pilif5• 16 years ago

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)

kls10• 16 years ago

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.

swah4• 16 years ago

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.

kls10• 16 years ago

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.

bad_user2• 16 years ago

> I am of the opinion that there is no longer a need for server side templating languages

This makes the assumption that all apps are dumb frontends to a database.

thomas11• 16 years ago

Why? You can have arbitrarily complex logic and computation in client-side JavaScript. Whether it's a good idea is another question.

kls10• 16 years ago

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.

toddheasley• 16 years ago

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

icey5• 16 years 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.

_3ex72• 16 years ago

Well some of the libraries out there are glue for C++ code. I think that is what he was inferring anyways.

icey5• 16 years 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.

xyzzyz• 16 years ago

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

mahmud• 16 years 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• 16 years 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• 16 years 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.

Locke16893• 16 years 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• 16 years ago

To which I ask you to check out Objective-J.

Locke16893• 16 years 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. :)

icey5• 16 years 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/

silentbicycle4• 16 years ago

Flexible compared to what? Given the circumstances, that's definitely damning with faint praise.

1337p3372• 16 years ago

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.

dasil0033• 16 years ago

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.

simonw3• 16 years ago

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.

silentbicycle4• 16 years ago

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.

Locke16893• 16 years ago

<rant>

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>

chipsy• 16 years ago

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.

COP• 16 years 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.

dasil0033• 16 years 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• 16 years 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). 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.

jashkenas8• 16 years 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.

jashkenas8• 16 years ago

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.

SkyMarshal• 16 years 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...)

tlrobinson3• 16 years 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.

jashkenas8• 16 years 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.

bmelton3• 16 years ago

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.

jashkenas8• 16 years ago

While it's quite embarrassing in regards to this conversation, zero effort has gone into making the homepage render properly in IE. The language is quite another matter. After working around IE bugs all day, getting up motivation to tackle them for the homepage of personal project is difficult -- you want to draw a line in the sand, and say, not this time. But you're right, of course.

Edit: CSS updated, see below.

exit2• 16 years ago

do you think it's worth fixing deeper stuff, like arrays of numbers being lexically sorted?

jashkenas8• 16 years ago

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.

dstein2• 16 years 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

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• 16 years 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.

dstein2• 16 years 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• 16 years ago

A screencast is not the appropriate way to introduce your code to developers. We want text.

silentbicycle4• 16 years ago

Seriously, we're not Ruby programmers. We can read, we don't need screencasts. ;)

tlrobinson3• 16 years 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• 16 years 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• 16 years 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-man...)

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

olsonjeffery• 16 years 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/ 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• 16 years ago

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

DjDarkman• 16 years 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.

Why node.js disappoints me

Related Stories