7 ms·

I dont buy that "less context switching using the same language client and server-side" nonsense. Are you storing data in a database? Context switch. Are you

by mdg 17y ago

I dont buy that "less context switching using the same language client and server-side" nonsense. Are you storing data in a database? Context switch. Are you outputting HTML? Context switch. I also dont buy that it makes client-side Javascript better because you are using it on the server as well. The client-side Javascript is probably going to send and receive JSON. When it gets that JSON, it has no clue (and doesnt care) what language or framework generated it. On a side note - I have been lurking on the node.js mailing list for a while now. Why do people think writing a MVC framework is apropriate? Isn't there something more exciting you can do with node.js?

pbh 17y ago
I think that the example you give is actually a very good example of a set of context switches that people regularly deal with poorly, even though they are, as you note, very common. How many server side web developers do you know who can output standards compliant HTML/XHTML that also works on IE6? (In fact, I suppose this is one major reason why templating is so common---so you can separate the web development experts from the web design experts.) How many web developers will have a database enforce their integrity constraints rather than having the logic in their program? How many know how to write PL/SQL? How many compilers are there now from some source language down to JavaScript in order to reduce the number of languages that a developer needs to know and control interactions between? The danger of these sorts of context switches seems to be difficult project coordination, code redundancy, performance bugs, and logic errors. (On a side note, it's not that I think that developers are stupid, it's that writing code well in a given language seems to require not just familiarity with that often idiosyncratic language, but it also requires continued knowledge of standard idioms, libraries, frameworks, and sources of answers to common problems.)
grayrest 17y ago
> Isn't there something more exciting you can do with node.js? My goal for node is to push my apps client side. Once you go all the way client side, the server only needs to serve up the static application files so that I can have them application cached, to backup/distribute/contain the localStorage, and to act as a communication channel. Node has the potential to excel at the last two while remaining widely comprehensible since most developers can at least read javascript. I don't see the need for a django or rails on the platform, but I don't have a problem with the current major efforts of a database abstraction layer or simple DSLs like sinatra.
old-gregg 17y ago
Less context switching probably means two things: * Mental context switch between server/client languages. * Better code reuse, i.e. the same model class can be used on the server and client side. Those things you're talking about are just protocols: storage protocol, transfer protocol, etc.
- mdg 17y ago
  > * Mental context switch between server/client languages. Not sure I follow. The client-side Javascript you write will probably interact with the DOM API. The server-side Javascript will probably interact with the filesystem of the server, it is BYOD (Bring Your Own DOM). Plus, no matter what, you will always have that switch between client/server because that switch is what defines client/server. > * Better code reuse, i.e. the same model class can be used on the server and client side. Does anyone actually do this? True, it is the same language, but it is not the same environment.
  - litewulf 17y ago
    Sharing models makes doing some form validations MUCH easier. My template language also runs on both server and client making progressive enhancement pretty trivial (in terms of updating dom elements when models change) As for context-switch on server/client... if you use something like underscore on both ends, lots of things end up looking the same.
  - maxwell 17y ago
    > ...it is the same language, but it is not the same environment. It is for me. I'm building a framework and enterprise app that just targets V8 (Node server, Chrome client). It's very liberating, to say the least. I still use Firefox (Firebug) for experimental stuff though, as Chrome's dev tools aren't up to par yet.
    - pohl 17y ago
      I'm surprised to hear WebKit's DOM Inspector being compared unfavorably to Firebug. What's missing?

by mdg 17y ago

pbh 17y ago

I think that the example you give is actually a very good example of a set of context switches that people regularly deal with poorly, even though they are, as you note, very common. How many server side web developers do you know who can output standards compliant HTML/XHTML that also works on IE6? (In fact, I suppose this is one major reason why templating is so common---so you can separate the web development experts from the web design experts.) How many web developers will have a database enforce their integrity constraints rather than having the logic in their program? How many know how to write PL/SQL? How many compilers are there now from some source language down to JavaScript in order to reduce the number of languages that a developer needs to know and control interactions between? The danger of these sorts of context switches seems to be difficult project coordination, code redundancy, performance bugs, and logic errors. (On a side note, it's not that I think that developers are stupid, it's that writing code well in a given language seems to require not just familiarity with that often idiosyncratic language, but it also requires continued knowledge of standard idioms, libraries, frameworks, and sources of answers to common problems.)

grayrest 17y ago

> Isn't there something more exciting you can do with node.js? My goal for node is to push my apps client side. Once you go all the way client side, the server only needs to serve up the static application files so that I can have them application cached, to backup/distribute/contain the localStorage, and to act as a communication channel. Node has the potential to excel at the last two while remaining widely comprehensible since most developers can at least read javascript. I don't see the need for a django or rails on the platform, but I don't have a problem with the current major efforts of a database abstraction layer or simple DSLs like sinatra.

old-gregg 17y ago

Less context switching probably means two things: * Mental context switch between server/client languages. * Better code reuse, i.e. the same model class can be used on the server and client side. Those things you're talking about are just protocols: storage protocol, transfer protocol, etc.

mdg 17y ago
> * Mental context switch between server/client languages. Not sure I follow. The client-side Javascript you write will probably interact with the DOM API. The server-side Javascript will probably interact with the filesystem of the server, it is BYOD (Bring Your Own DOM). Plus, no matter what, you will always have that switch between client/server because that switch is what defines client/server. > * Better code reuse, i.e. the same model class can be used on the server and client side. Does anyone actually do this? True, it is the same language, but it is not the same environment.
- litewulf 17y ago
  Sharing models makes doing some form validations MUCH easier. My template language also runs on both server and client making progressive enhancement pretty trivial (in terms of updating dom elements when models change) As for context-switch on server/client... if you use something like underscore on both ends, lots of things end up looking the same.
- maxwell 17y ago
  > ...it is the same language, but it is not the same environment. It is for me. I'm building a framework and enterprise app that just targets V8 (Node server, Chrome client). It's very liberating, to say the least. I still use Firefox (Firebug) for experimental stuff though, as Chrome's dev tools aren't up to par yet.
  - pohl 17y ago
    I'm surprised to hear WebKit's DOM Inspector being compared unfavorably to Firebug. What's missing?