Live data from Hacker News

Why node.js disappoints me

eflorenzano.com

81–90 of 92 posts

Re: Why node.js disappoints me

#81
post #32

Earlier quoted context omitted.

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.

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.

Re: Why node.js disappoints me

#82
post #81

Earlier quoted context omitted.

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

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

Ok, just curious. I use Lua quite a bit, and I find its mix of prototype-based OO and clean functional programming to be very practical, as well.

It sounds like other people find the same pragmatism in Javascript, but after learning Lua, I find Javascript really depressing - it had so much potential, but...it's like Lua's little brother whose mind never had a chance to fully develop (due to the browser wars). It's sad. Lua's design has been refined for 17 years, and ... Javascript was frozen after 2. Just reading about thruth-y and false-y types in Javascript makes me cringe.

Granted, Lua doesn't have the strangehold on web development that Javascript does (it was designed for scripting C/C++ instead, like Tcl), but I'm working on that.

Re: Why node.js disappoints me

#83
post #65

Earlier quoted context omitted.

Oh no, I understand completely. If my personal homepage works in IE7, it's a fortunate, but unintended happening altogether. That said, I was very interested in CoffeeScript as part of my job is to write new whiz-bang features into applications that run on older browsers (such as the IE7 I visited you on today.) Bear in mind, CoffeeScript especially appeals to people in my position. It just sucks I can't read it / pl…

I've pushed some CSS tweaks for IE to CoffeeScript.org -- it still won't look real pretty, but everything should be usable now. Should have done it a long time ago, thanks for the nudge.

They work like a champ, though I basically got what I wanted out of it last night at home.

Any idea how far away you are from putting out something one might consider 'stable'? I'm in the government, and it's effectively impossible to use 'beta' code here.

Re: Why node.js disappoints me

#84
post #78
post #48

Earlier quoted context omitted.

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

Thanks don't worry about the ugly. We all have pieces we are not proud off. I would just like to see the basic of what you did so I have a head start when I jump into Node.

I can give you this, it is prettier than any code I have written in Node (if it is not apparent from my posts, I have not worked in Node).

Re: Why node.js disappoints me

#85
post #83

Earlier quoted context omitted.

I've pushed some CSS tweaks for IE to CoffeeScript.org -- it still won't look real pretty, but everything should be usable now. Should have done it a long time ago, thanks for the nudge.

They work like a champ, though I basically got what I wanted out of it last night at home. Any idea how far away you are from putting out something one might consider 'stable'? I'm in the government, and it's effectively impossible to use 'beta' code here.

The language syntax is pretty much stable at this point -- getting to 1.0 is now mainly a matter of shaking out the edge cases in parsing, and solidifying the compiler as much as possible.

Fortunately, you don't have to take my word for it. Even if the CoffeeScript compiler were to disappear in a puff of smoke this afternoon -- you'd still be left with pretty-printed, quite-readable JavaScript. It's not like depending on a beta of a VM or interpreter.

Re: Why node.js disappoints me

#86
post #34
post #11

Earlier quoted context omitted.

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

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…

In this (http://news.ycombinator.com/item?id=1628991) comment you give an example of a cart, and how it shouldn't be bounced between client and server all the time, but be carried with the client which sends it in the end, when its done.

I'm trying to understand: how can you keep a Javascript object (the Cart array, lets say) between pages?

Re: Why node.js disappoints me

#87
post #86
post #34

Earlier quoted context omitted.

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…

In this ( http://news.ycombinator.com/item?id=1628991 ) comment you give an example of a cart, and how it shouldn't be bounced between client and server all the time, but be carried with the client which sends it in the end, when its done. I'm trying to understand: how can you keep a Javascript object (the Cart array, lets say) between pages?

I would design my cart widget so that it does not require multiple pages that way it stays memory resident. The entire cart workflow would exist in a shopping cart widget. Further we designed a routine that wires into the page load and unload that does the following. Any data marked as persitable is stuffed into client side storage (we use Dojo so it figures out where it can store stuff, Cookie, Flash, IFrame). The routine looks for stuff stored in this segment when a page loads and pulls it back into memory and flushes the data from storage. On unload it repeats the process of serializing marked data. If you absolutely need a multi-page model you can use a similar pattern.

Re: Why node.js disappoints me

#88
post #87
post #86

Earlier quoted context omitted.

In this ( http://news.ycombinator.com/item?id=1628991 ) comment you give an example of a cart, and how it shouldn't be bounced between client and server all the time, but be carried with the client which sends it in the end, when its done. I'm trying to understand: how can you keep a Javascript object (the Cart array, lets say) between pages?

I would design my cart widget so that it does not require multiple pages that way it stays memory resident. The entire cart workflow would exist in a shopping cart widget. Further we designed a routine that wires into the page load and unload that does the following. Any data marked as persitable is stuffed into client side storage (we use Dojo so it figures out where it can store stuff, Cookie, Flash, IFrame). The r…

Interesting. I was thinking about using something like a hidden frame. Some StackOverflow posts mention storing data in "window.name". But we need something secure to store the user auth token...

Re: Why node.js disappoints me

#89

Earlier quoted context omitted.

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

A big problem is that the largest source of frustration with javascript is DOM incompatibility rather than JS itself. At least the unified language allows projects like jQuery to partially clean up the mess for everyone. If you had multiple languages, imagine the mess.

Incompatibility is certainly a headache, but having worked on a 10k-line, Firefox-only Javascript project, I can say with confidence that there are a number of pain-points in the language itself.

Scoping weirdness, the erratic semantics of the 'this' keyword, etc.

If you had multiple languages atop a VM, it would be simpler, in fact. The browser only needs to worry about bytecode, except in the case of Javascript, where the inclusion of Rhino (or its equivalent) would be needed for pragmatic reasons. Any hooks into the DOM would be exposed through the VM, and a sensible way to talk to the VM would be the language implementor's problem.

Re: Why node.js disappoints me

#90
post #88
post #87

Earlier quoted context omitted.

I would design my cart widget so that it does not require multiple pages that way it stays memory resident. The entire cart workflow would exist in a shopping cart widget. Further we designed a routine that wires into the page load and unload that does the following. Any data marked as persitable is stuffed into client side storage (we use Dojo so it figures out where it can store stuff, Cookie, Flash, IFrame). The r…

Interesting. I was thinking about using something like a hidden frame. Some StackOverflow posts mention storing data in "window.name". But we need something secure to store the user auth token...

You should consider using one of the toolkits, many of them have something akin to Dojo's storage http://ajaxian.com/archives/dojostorage-offline-access-and-p... . This buffers you from the implementation details and as newer browsers come along they are able to update the implementation to take advantage of newer browsers built in databases, while providing you with the same backwards compatible API. If you have not chosen one, I recommended you take a look at Dojo, if you are going to build a full on web app and jQuery if you have lighter requirements.

Side note: we are really starting to side track this thread, why don't you email me (in my profile) or add me to your contacts in Skype (if you use Skype) that way you can hit me up on any questions you have.

Post reply on HN