4 ms·

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 make

by icey 16y 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.

mdg 16y ago
Well some of the libraries out there are glue for C++ code. I think that is what he was inferring anyways.
- icey 16y 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.
  - _delirium 16y ago
    It's a little bigger consideration in this case imo, because one of the big selling points is the ability to do "JS everywhere" and share code between the browser and server side of apps. Not that that's the only reason node.js exists, but it's a nice aspect that becomes harder if the server and browser sides diverge more.
    - icey 16y ago
      Ah, if that's the case then I misread. If the problem is the broken promise of writing code once than runs perfectly well on the server or in the browser then I guess I could see the frustration. Although, I'm not sure that's an entirely realistic expectation given the different roles you'd expect the server and client to fill.
chewbranca 16y ago
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.

by icey 16y ago

mdg 16y ago

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

icey 16y 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.
- _delirium 16y ago
  It's a little bigger consideration in this case imo, because one of the big selling points is the ability to do "JS everywhere" and share code between the browser and server side of apps. Not that that's the only reason node.js exists, but it's a nice aspect that becomes harder if the server and browser sides diverge more.
  - icey 16y ago
    Ah, if that's the case then I misread. If the problem is the broken promise of writing code once than runs perfectly well on the server or in the browser then I guess I could see the frustration. Although, I'm not sure that's an entirely realistic expectation given the different roles you'd expect the server and client to fill.

chewbranca 16y ago

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.