Live data from Hacker News

Why node.js disappoints me

eflorenzano.com

71–80 of 92 posts

Re: Why node.js disappoints me

#71
post #62

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-yourse…

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

There are lots of things that it would be wonderful to fix, but can't be done without either patching native objects, running an interpreter on top of JS, or adding lots of special functions in a required library.

Take, for example, negative array indices. It would be lovely if JS allowed you to say:

    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.

Re: Why node.js disappoints me

#72

Earlier quoted context omitted.

I like CoffeeScript, but what does it have to do with Eric's complaints? It does nothing to prevent people from duplicating effort or tying libraries to a specific environment.

Eric complained about implementation-specific language features in JavaScript -- things that only run on some, but not all of: SpiderMonkey, V8, JScript, and Nitro. To quote: Instead of coding in one language, we're actually coding in two. One is the subset JavaScript that can be run in all browsers, and another is the set of JavaScript that can be run by Node. He's not talking about features specific to the Node API…

When he said "language" I guess I automatically translated that to "APIs" since that's usually what people mean when they complain about incompatibility in JavaScript environments.

Differences in the JavaScript language in engines are fairly minimal these days (BTW all the features you mentioned can be added to legacy engines, see http://github.com/280north/narwhal/blob/master/engines/defau...) I think the bigger problem with sharing code between client and server is the libraries that unnecessarily tie themselves to APIs specific to each environment (i.e. the DOM and other browser APIs, and Node.js or other server-side APIs)

Re: Why node.js disappoints me

#73
post #47

Earlier quoted context omitted.

Right, my point was that templating was a concern of the UI, yet I wanted to be clear that business logic and data services remain the domain of the application server. Further I try to remove templating from any run-time concern (server or client) by doing all static content templating in a CMS and then publishing it to a web server.

OK, sorry, I misunderstood your point. Yes, it makes a lot of sense to do Javascript server-side for templating (client-side only is still tricky because of concerns related to crawlers, like search-engines). But on the other hand, I would prefer the JVM with Rhino, not Node.js ... especially since using Java NIO you can have scalability for I/O bound requests similar to Node.js.

No I don't do any templating server side, it is a waste of server resources. So all of our templating Header, footer, static articles are in a CMS all dynamic elements are done via JavaScript. We use a headless web browser to serve pages to crawlers from a dedicated server. It acts as a parser for the crawlers and when it sees a crawler agent and the hash mark it acts as the client Javascript engine and composites the page. This way, we don't have a hand coded solution for a platform problem that is infrastructure related.

Re: Why node.js disappoints me

#74

Earlier quoted context omitted.

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…

When he said "language" I guess I automatically translated that to "APIs" since that's usually what people mean when they complain about incompatibility in JavaScript environments. Differences in the JavaScript language in engines are fairly minimal these days (BTW all the features you mentioned can be added to legacy engines, see http://github.com/280north/narwhal/blob/master/engines/defau... ) I think the bigger pr…

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.

Re: Why node.js disappoints me

#75
post #62

Earlier quoted context omitted.

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

There are lots of things that it would be wonderful to fix, but can't be done without either patching native objects, running an interpreter on top of JS, or adding lots of special functions in a required library. Take, for example, negative array indices. It would be lovely if JS allowed you to say: array[-1] As an alias for array[array.length - 1] Unfortunately, we can't add the feature because you'd have to interc…

fair enough. i suppose ultimately the browser just needs a neutral vm.

Re: Why node.js disappoints me

#76
post #41

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?

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…

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 ;)

Re: Why node.js disappoints me

#77

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?

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

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

Re: Why node.js disappoints me

#78
post #48
post #43

Earlier quoted context omitted.

in this case, the API was so simple, I could easily roll my own (it's not even a real framework - I have one resource, the alias and I allow basically just POST to /aliases to create one at the moment). The beauty about node is that it's so simple to extend and add the functionality you need. No magic, no huge framework to learn. The little things you get though work awesomely well and are a pleasure to use.

If you could find the time to shot me an email (possible with some samples, or some links) of how you did your REST services with Node, I would be forever in your debt. My email is in my profile if you get a chance.

if it wasn't a bit ugly (organically grown, just one endpoint), I'd direct you to the source code of the tempalias HTTP server.

You can still have a look at it. As I said though, it's really ugly and I should really split it up into multiple files, factor out the common stuff and make the whole thing more clear.

Still. Here goes:

http://github.com/pilif/tempalias/blob/master/lib/tempalias_...

Lines 30 and following handle calls to /aliases (in my case, that's just a POST to /aliases to create an alias - later I'd add PUT to /aliases/ to update it and DELETE /aliases/ to delete it - assuming that a correct update key (part of the response to creation) has been created.

As I said: Butt-ugly code. Don't do it like this - factor out common stuff, create smaller functions for the various parts of the needed setup.

Re: Why node.js disappoints me

#79
post #32

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?

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/

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

Re: Why node.js disappoints me

#80
post #55
post #42

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 th…

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

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