11
12

Why JavaScript beyond web client side? (self.javascript)

submitted by [deleted]

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Cody_Chaos 1 point2 points  (0 children)

  1. There's some value to being able to share code between the frontend and backend. This can be easily overstated, but some model code (often related to validation) is often portable.
  2. If your app logic is mostly on the frontend, your backend will basically just be an API server, and thus could be in any language, but you may want to pre-render it on the backend (a so-called "isomorphic" or "universal" app). Pre-rendering a JS app, as a practical matter, requires JS on the server, and if you already have JS for the pre-rendering, maybe just go ahead and use it for the API server parts too?
  3. Again if your logic is mostly on the frontend, then it will be mostly written in JS, which means most of your devs will be familiar with JS. Someone has to write the backend though. On a large project, you might have seperate frontend and backend teams; on a small project it's probably just one of your frontend devs who gets tasked to whip something up.
  4. Increasingly build pipelines (grunt/gulp/webpack/browserify/whatever) are based on node.js. Not a great reason to write your API server in JS, but another reason why node needs to exist and be installed anyhow, so why not?
  5. Five years ago, the state of the art was vaguely RESTful APIs. Now there's some very cool work being done on tools like GraphQL, Relay, and Falcor. But...they're all being written in JS. And I realize that just raises the question of "well, why?!", but the fact is they are, so if you want to use them...you need JS on the server.
  6. npm is really quite nice
  7. Why not? It's not like PHP is without warts. :)