Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why node.js disappoints me

eflorenzano.com

Post reply on HN
Print view View original

11–20 of 92 posts

Re: Why node.js disappoints me

#11

Post by swah »

kls wrote: post #3

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

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.

Re: Why node.js disappoints me

#13

Post by icey »

_3ex7 wrote: post #9
icey wrote: post #7

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.

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

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.

Re: Why node.js disappoints me

#14

Post by pilif »

olalonde wrote: post #6
kls wrote: post #3

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

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

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&#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 :-)

Re: Why node.js disappoints me

#15

Post by simonw »

olalonde wrote: post #6
kls wrote: post #3

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

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

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.

Re: Why node.js disappoints me

#16

Post by bad_user »

kls wrote: post #3

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

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

Re: Why node.js disappoints me

#17

Post by neilk »

olalonde wrote: post #6
kls wrote: post #3

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

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

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.

Re: Why node.js disappoints me

#18

Post by simonw »

pilif wrote: post #14
olalonde wrote: post #6

Earlier quoted context omitted.

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

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&#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 j…

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

Gets converted by their crawler in to this:

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.

Re: Why node.js disappoints me

#19

Post by pilif »

simonw wrote: post #18
pilif wrote: post #14

Earlier quoted context omitted.

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&#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 j…

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 Gets converted by their crawler in to this: 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.

Of course you are right. It has been a while since I've done this. Sorry for the confusion. I totally forgot that :-)

Re: Why node.js disappoints me

#20

Post by chewbranca »

icey wrote: post #7

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.

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.

Post reply on HN