My point is that the proliferation of HN posts regarding node.js is not reflective or driven by a host of new and significant improvements that it brings to the table. I suppose one response is this shouldn't be surprising, since anything implemented after the 70s could have been done with C instead of language X.
But my complaint is that it seems a lot of attention is paid to projects which are not actually doing new things with node.js, just things that have already been done with other technologies.
I'd argue that being in javascript is an advantage rather than a disadvantage. Sharing code between server and client (browser) is much easier, and there is no alternative to javascript in the browser.
I'm not saying javascript is the king of languages, just that we're limited to it because that's what's in the browser, and writing server code in the same language simplifies things.
> Sharing code between server and client (browser) is much easier, and there is no alternative to javascript in the browser.
That's a fallacy, the environments have nothing in common, the coding styles and interactions don't either, the only things you're going to be able to meaningfully share are trivial helper libraries à la underscore..
> and writing server code in the same language simplifies things.
Why? How? Where? I see that assertion often, but I have yet to see it backed by anything but "because I said so".
Actually the environments have a whole lot in common. Templating, validation and data retrieval/storage for example can be done both client & server-side, depending on the situation.
A fallacy? Sharing code between client and server is easier when the two are in the same language than when the two are in a different language. How is that flawed reasoning?
One example: you can run the same input validation in the client as you do in the server if you can easily share code between the two.
But there is way more. Here's an example of an application that shares all of its data models between client and server:
http://tilemill.com/docs/models.html
Server side logic is usually radically different. And given that you usually share information between the server and the client in a language agnostic manner (e.g. JSON) and that the client (browser) cannot be trusted with other than view logic, I see few cases where implementation specific code sharing contributes greatly.
The server and the client has such different concerns that code sharing probably wouldn't contribute that much.
Except the client can act as a server once you start thinking about localStorage caching. Form/input validation is another thing which is really useful to have on both the client and server and benefits greatly from code sharing.
Basically: Client side validation is about user experience, Server side is about security. I'm hard pressed to believe you can get both with the same code.
I also don't see how localStorage is relevant to code sharing between client and server.
Rendering templated HTML on the server for serving the first page from cache and then using the same code to render subsequent pages on the client is one use I'd like to experiment with.
I definitely regard server side JavaScript as a strong advantage - doing client development in JavaScript, database development in CouchDB is feels wrong to be doing the server application component in something else.
Why does it feel wrong? JavaScript isn't that great a language; even if you use CoffeeScript, there are nicer languages out there, and on the server you have the option of using whatever language you want.
Using the same language on client and server can come in handy if you've got some non-trivial amount of code they can share in common. When I made a multi-user text editor (think Etherpad, but simpler), all the code for transforming the editing operations so that everybody's documents converge was written in a single JavaScript file, which I ran on both the client and the server, via node.js. That was great. That was fun. But if you don't have a situation like that, where's the advantage in using JS on the server?
Of course, the comment about it being "wrong" is completely subjective. I just really like JavaScript these days (and I've been paid to program in a lot of other languages - Lisp, C, C++, PostScript, Java, C#...).
Comments
My point is that the proliferation of HN posts regarding node.js is not reflective or driven by a host of new and significant improvements that it brings to the table. I suppose one response is this shouldn't be surprising, since anything implemented after the 70s could have been done with C instead of language X.
But my complaint is that it seems a lot of attention is paid to projects which are not actually doing new things with node.js, just things that have already been done with other technologies.
Actually, this comment sums it up much better than my comment: http://news.ycombinator.com/item?id=1549023
I'd argue that being in javascript is an advantage rather than a disadvantage. Sharing code between server and client (browser) is much easier, and there is no alternative to javascript in the browser.
I'm not saying javascript is the king of languages, just that we're limited to it because that's what's in the browser, and writing server code in the same language simplifies things.
> Sharing code between server and client (browser) is much easier, and there is no alternative to javascript in the browser.
That's a fallacy, the environments have nothing in common, the coding styles and interactions don't either, the only things you're going to be able to meaningfully share are trivial helper libraries à la underscore..
> and writing server code in the same language simplifies things.
Why? How? Where? I see that assertion often, but I have yet to see it backed by anything but "because I said so".
Actually the environments have a whole lot in common. Templating, validation and data retrieval/storage for example can be done both client & server-side, depending on the situation.
A fallacy? Sharing code between client and server is easier when the two are in the same language than when the two are in a different language. How is that flawed reasoning?
One example: you can run the same input validation in the client as you do in the server if you can easily share code between the two.
But there is way more. Here's an example of an application that shares all of its data models between client and server: http://tilemill.com/docs/models.html
Server side logic is usually radically different. And given that you usually share information between the server and the client in a language agnostic manner (e.g. JSON) and that the client (browser) cannot be trusted with other than view logic, I see few cases where implementation specific code sharing contributes greatly.
The server and the client has such different concerns that code sharing probably wouldn't contribute that much.
Except the client can act as a server once you start thinking about localStorage caching. Form/input validation is another thing which is really useful to have on both the client and server and benefits greatly from code sharing.
Except in most cases validation cannot be complete on the client side, anything related to server side logic has to be additionally checked.
Validation is also two different concerns if you compare serverside vs clientside.
http://stackoverflow.com/questions/162159/javascript-client-...
Basically: Client side validation is about user experience, Server side is about security. I'm hard pressed to believe you can get both with the same code.
I also don't see how localStorage is relevant to code sharing between client and server.
Rendering templated HTML on the server for serving the first page from cache and then using the same code to render subsequent pages on the client is one use I'd like to experiment with.
I definitely regard server side JavaScript as a strong advantage - doing client development in JavaScript, database development in CouchDB is feels wrong to be doing the server application component in something else.
Why does it feel wrong? JavaScript isn't that great a language; even if you use CoffeeScript, there are nicer languages out there, and on the server you have the option of using whatever language you want.
Using the same language on client and server can come in handy if you've got some non-trivial amount of code they can share in common. When I made a multi-user text editor (think Etherpad, but simpler), all the code for transforming the editing operations so that everybody's documents converge was written in a single JavaScript file, which I ran on both the client and the server, via node.js. That was great. That was fun. But if you don't have a situation like that, where's the advantage in using JS on the server?
Of course, the comment about it being "wrong" is completely subjective. I just really like JavaScript these days (and I've been paid to program in a lot of other languages - Lisp, C, C++, PostScript, Java, C#...).