5 ms·

> The language of the web is javascript. Until web browsers allow Go as the embeddable language, node will remain useful. Do people really get that much code r

by kbd 14y ago

> The language of the web is javascript. Until web browsers allow Go as the embeddable language, node will remain useful. Do people really get that much code re-use between client and server that using Javascript on the server provides a large benefit?

Raynos 14y ago
In a medium sized web application, 50-70% of server-side code can be re-used verbatim between server and client.
- jsprinkles 14y ago
  Well, whatever "medium sized" means, I work on a high-traffic Web application that reuses 0% of code from the client; in almost everything I've worked on, I've found reuse between client and server nearly impossible, enough that they're almost always segregated repositories. There's an argument for models existing on both sides (which is reiterated below), but I have a hard time seeing models as 50-70% of any application. Just not my experience that this is the case. Though I might be old-fashioned.
  - tomjen3 14y ago
    The amount of traffic has nothing to do with it. A crud app would properly share relatively little code between the server and the client. A multiplayer game would share much, much more.
    - jsprinkles 14y ago
      And which do you think is more prevalent in the world, a CRUD app or a multiplayer game?
  - Raynos 14y ago
    "medium" means I don't have personal experience of how the percentage scales to large applications. as for sharing: data sources, domain models, utilities and templates can be shared. its the io handling (HTTP and dom) that can not be shared.
  - rodw 14y ago
    For what it's worth, here's one counter-example: I've recently been working with a team that is developing a content management system for which the display side of things (responsible for routing requests to models and views, fetching model content, rendering, etc.) is about 500 lines of non-comment CoffeeScript code. Nearly 100% of the server-side code is re-used on the client, and perhaps 80% of the (non-library) client-side code is shared with the server. In this case the exceptions are: - Things like HTTP-level request handling and reading from local files rather than over HTTP are used on the server-side only. - Things like DOM-manipulation and interacting with browser events are used on the client-side only. I wonder if a significant factor may be how much functionality you're actually replicating on both the client and server. In our case, browser-permitting, the entire display engine runs equally well on the client or on the server. If we had a lot of JQuery kind of stuff happening in the client-side JavaScript the ratios might be a little different, but "also-run-the-app-on-the-client" is a good example of a use case that leads to a lot of reuse of the server side code.
tomjen3 14y ago
For small apps, no. For complex ones yes. The actual code shared may not be that much, but consider the advantages in sharing validation code between the client and server -- you never accidentally forget one requirement on the server side, leaving you vulnerable to an attack.
- jsprinkles 14y ago
  Alternatively, there's an argument that one should not validate on the client to avoid this exact scenario (split-brain validation).
  - sim0n 14y ago
    Why not validate on both? Validate on the client to give a nicer and quicker notice if something is wrong (good UX) and then validate on the server for actual security.
    - jsprinkles 14y ago
      To avoid a split-brain validation scenario. Update your model? Don't forget to update your validation in both the client and server. Otherwise, you'll validate something on the client but not the server (bad UX), invalidate something on the client but not the server (bad UX), or corrupt your data slowly when validation entirely fails (bad UX). Since it's a pain in the ass to remember to update two places when you make a change, you're seeing people make ridiculous leaps of programming ingenuity by choosing a server-side language that allows them to not have to update two places at once, and Javascript absolutely sucks for server programming. Every time I have to do any client-side Javascript I, quite literally, hate my life. People that love Javascript and want to apply it to everything have arguments about the stupidest things, like using semicolons, which is telling about how awful of a programming environment it can be. Easier: Just don't validate on the client, and make a round trip. If you're doing mobile or on a high-latency link, there's an argument for doing client-side validation but then you just need the discipline to update both sides at once, which hopefully integration tests should help with.
KaoruAoiShiho 14y ago
Check out stuff like meteor or firebase. They barely even differentiate btwn client and server code. Rolling your own framework based on the same ideas is not hard.
phoboslab 14y ago
I'm currently working on the next major version of my JavaScript game engine[1]. The main new feature will be real time multiplayer. Being able to run the same game code server and client side is invaluable. [1] http://impactjs.com/ http://impactjs.com/

by kbd 14y ago

Raynos 14y ago

In a medium sized web application, 50-70% of server-side code can be re-used verbatim between server and client.

jsprinkles 14y ago
Well, whatever "medium sized" means, I work on a high-traffic Web application that reuses 0% of code from the client; in almost everything I've worked on, I've found reuse between client and server nearly impossible, enough that they're almost always segregated repositories. There's an argument for models existing on both sides (which is reiterated below), but I have a hard time seeing models as 50-70% of any application. Just not my experience that this is the case. Though I might be old-fashioned.
- tomjen3 14y ago
  The amount of traffic has nothing to do with it. A crud app would properly share relatively little code between the server and the client. A multiplayer game would share much, much more.
  - jsprinkles 14y ago
    And which do you think is more prevalent in the world, a CRUD app or a multiplayer game?
- Raynos 14y ago
  "medium" means I don't have personal experience of how the percentage scales to large applications. as for sharing: data sources, domain models, utilities and templates can be shared. its the io handling (HTTP and dom) that can not be shared.
- rodw 14y ago
  For what it's worth, here's one counter-example: I've recently been working with a team that is developing a content management system for which the display side of things (responsible for routing requests to models and views, fetching model content, rendering, etc.) is about 500 lines of non-comment CoffeeScript code. Nearly 100% of the server-side code is re-used on the client, and perhaps 80% of the (non-library) client-side code is shared with the server. In this case the exceptions are: - Things like HTTP-level request handling and reading from local files rather than over HTTP are used on the server-side only. - Things like DOM-manipulation and interacting with browser events are used on the client-side only. I wonder if a significant factor may be how much functionality you're actually replicating on both the client and server. In our case, browser-permitting, the entire display engine runs equally well on the client or on the server. If we had a lot of JQuery kind of stuff happening in the client-side JavaScript the ratios might be a little different, but "also-run-the-app-on-the-client" is a good example of a use case that leads to a lot of reuse of the server side code.

tomjen3 14y ago

For small apps, no. For complex ones yes. The actual code shared may not be that much, but consider the advantages in sharing validation code between the client and server -- you never accidentally forget one requirement on the server side, leaving you vulnerable to an attack.

jsprinkles 14y ago
Alternatively, there's an argument that one should not validate on the client to avoid this exact scenario (split-brain validation).
- sim0n 14y ago
  Why not validate on both? Validate on the client to give a nicer and quicker notice if something is wrong (good UX) and then validate on the server for actual security.
  - jsprinkles 14y ago
    To avoid a split-brain validation scenario. Update your model? Don't forget to update your validation in both the client and server. Otherwise, you'll validate something on the client but not the server (bad UX), invalidate something on the client but not the server (bad UX), or corrupt your data slowly when validation entirely fails (bad UX). Since it's a pain in the ass to remember to update two places when you make a change, you're seeing people make ridiculous leaps of programming ingenuity by choosing a server-side language that allows them to not have to update two places at once, and Javascript absolutely sucks for server programming. Every time I have to do any client-side Javascript I, quite literally, hate my life. People that love Javascript and want to apply it to everything have arguments about the stupidest things, like using semicolons, which is telling about how awful of a programming environment it can be. Easier: Just don't validate on the client, and make a round trip. If you're doing mobile or on a high-latency link, there's an argument for doing client-side validation but then you just need the discipline to update both sides at once, which hopefully integration tests should help with.

KaoruAoiShiho 14y ago

Check out stuff like meteor or firebase. They barely even differentiate btwn client and server code. Rolling your own framework based on the same ideas is not hard.

phoboslab 14y ago

I'm currently working on the next major version of my JavaScript game engine[1]. The main new feature will be real time multiplayer. Being able to run the same game code server and client side is invaluable. [1] http://impactjs.com/ http://impactjs.com/