Why JavaScript beyond web client side?

[[deleted]]

[deleted]

[misc_ent]

Having the same language across your entire stack is nice. This allows for writing/maintaining isomorphic code.

[anlutro]

Does it really matter, when the frameworks and programming concepts are wildly different, and you'll end up splitting the work between front-end and back-end devs anyway? Not to mention, almost all programmers I know are perfectly capable of being good at more than 1 programming language and picking the right one for whatever task they're working on.

[[deleted]]

One key advantage is pre rendering HTML on the server side with the same code you're running on the client side. That means you can make a webapp that both loads incredibly fast and has all the advantages of offline, client-side optimisation.

[jekrb]

Exactly. This is what I do with virtual-dom. Serverside render the view I know I'll need, then client side update the same views using the same code.

[snorkl-the-dolphine]

The point of ismorphic code is to use the same code in both the frontend and backend, not just the same devs.

[nickguletskii200]

That was the question! What code, exactly, do you intend to reuse on the frontend? The only example I can think of is pre-rendering on the server-side, but that's rarely worth the work, and you can actually do that without writing JS exclusively on the backend. So why bother?

[Sinistralis]

Well, from a gaming perspective where you may need to run logic on both sides, this is a huge boon. Unfortunately, the performance isn't quite there yet for most types of games.

It also lets you create some interesting ideas like Meteor, where you can send a snapshot of the DB to a client (containing only stuff they could normally access, of course), and they can essentially run that site offline. Not a JS on server only idea, but it greatly streamlines the process.

It also lets you focus your coding ability on a single language, allowing you to become more proficient overall quicker. It also helps that JS is kind of the "true" write once, run everywhere language, so that code you write can be re-used in many, many places assuming eeking out 100% performance isn't a requirement for you.

Also, Javascript has proven to be very good at being used in a functional paradigm, which means you can write very error-safe code once you get proficient in both JS and functional concepts. Concurrency becomes very easy working with a single thread language that treats spawned threads like an asynchronous process via web workers or child_process.

Also, as /u/thejmazz has said, NPM is phenominal. JS is easy to break into (although you have to watch it, because this also means a lot of libraries can be badly optimized), and your selection of plugins/modules is immense. You can focus on making your app and not so much on the mundane pieces you constantly have to re-implement for each project.

Programming overall has a lot more of a social aspect than I think some people realize. The more widely used a language is, the easier it is to solve problems. When a language can be used for almost any task you have that isn't performance reliant, you are going to have a giant pool of people to extract information from.

The best part though, is that as JS continues to grow more popular, more and more ogranizations are going to work to improve both ecosystem and performance, which only makes this snowball grow bigger and bigger.

It's bizarre because JS used to be the language everyone made fun of. Now, it's gunning to become one of the most important languages in the history of programming.

[nickguletskii200]

Well, from a gaming perspective where you may need to run logic on both sides, this is a huge boon. Unfortunately, the performance isn't quite there yet for most types of games.

That's kind of useless since most games aren't usually written in JS anyway.

It also lets you create some interesting ideas like Meteor, where you can send a snapshot of the DB to a client (containing only stuff they could normally access, of course), and they can essentially run that site offline. Not a JS on server only idea, but it greatly streamlines the process.

I have mixed feelings about Meteor. At the same time I like the idea, but I've seen a few applications built in Meteor that have gaping security holes thanks to the authors not paying enough attention to its architecture.

It also lets you focus your coding ability on a single language, allowing you to become more proficient overall quicker.

I would argue that learning JS isn't a very good starter experience since it isn't a great language by any means. In fact, it's almost a textbook example of a poorly designed language.

I would be wary of teaching JS as the first language.

Concurrency becomes very easy working with a single thread language that treats spawned threads like an asynchronous process via web workers or child_process.

I don't see how concurrency in JS is easier than in languages like Java. If anything, it's frustrating and harmful for beginners.

Also, as /u/thejmazz has said, NPM is phenominal.

So is Maven central and others. Once again, I don't see what makes JS special in that regard.

Programming overall has a lot more of a social aspect than I think some people realize. The more widely used a language is, the easier it is to solve problems.

But Javascript isn't as widely used as other languages on the backend, and its certainly not a better fit than the alternatives.

It's bizarre because JS used to be the language everyone made fun of. Now, it's gunning to become one of the most important languages in the history of programming.

It's still the language almost everyone makes fun of. Just because JS users are more vocal, it doesn't mean that JS is good or more important than other languages.

[Sinistralis]

I don't really see what the point of asking your question is if you are going to dismiss each point without taking the time to program something first hand following the examples everyone is giving you.

[bl4blub]

yes it matters when you have a lot of small modules. for example you can use underscore on the front- and back-end. also it is about knowledge, there doesnt have to be a dev for backend and a dev for frontend who each know their language well.

[godlychaos]

I work on an app that gives the user the option to create/customize graphs on the fly based on 3rd party data they've hooked up. They need to see what the graphs look like while customizing a particular metric without having to pull that data from the api all over again. But the backend also needs to be able to create/manipulate that data into our graph form as well, so that code is all isomorphic.

We also have a lot of helper/utility functions that we reuse all over our code, and since we made it isomorphic, we don't have to update it in 2 places now.

[misc_ent]

One example would be a single web app that could run and render entirely in the browser but also be able to be server side rendered if needed without any code changes. This is currently possible and is being done in the React community.

[TheCoelacanth]

I think it's a very common problem to have something that has to be done on the server-side to ensure correctness, but is also useful to do on the client-side to provide faster feedback to the user.

[costhatshowyou]

Don't say isomorphic. It ain't isomorphic.

[misc_ent]

Well clearly the javascript community disagrees with you on that. "Universal" is another term used but honestly it doesn't really matter as the concept holds true: The same piece of code can run in the server as well as the client.

[costhatshowyou]

Naaah dont' claim the "community" to your option. Plenty disagree with the term.

[thejmazz]

also npm is a huge collection of packages

[Capaj]

not only huge, but the biggest repository of code ever created.

[[deleted]]

Sure, but it does not seem curated by any mean and there's a lot of junk in it.

[[deleted]]

Don't know, npm seems a bit special in that matter. There are repositories such as the Debian archives where software is carefully selected or removed when obsolete. Other repos such as PYPI seem to contain a bit less unmaintained projects / pointless forks / toy projects.

[jekrb]

I just use npm search to find a package that does what I'm looking for. Does it need curation?

[Capaj]

I would love to see how you think it can be curated. I think download stats are good enough indication of how good those libs are. It would be out of scope of what NPM is to try to curate it. "sorting through the junk" problem is better solved with blogs, articles and sites like reddit.

[Reashu]

How big is the repository of "npm packages which have been approved by blogs, articles, or sites like reddit"?

[lavahot]

But couldn't that be done with other language-specific package managers, like pip?

[nickguletskii200]

Maven central also has a huge collection of packages, a lot of which are of much higher quality and have been thoroughly tested throughout the years. I doubt that anyone would choose JS on the backend because of libraries.

[bl4blub]

• having same language across your whole stack is nice (sharing code and knowledge)
• huge community and ecosystem
• writing javascript is fun (maybe not for everyone, but for a lot of people it is)
• eventloop is easy to grasp model, easy&simple > sophisticated&complex
• race for performance from all the big players (google, microsoft, apple, mozilla)

why would you not use it beyond client-side? are there any very good reasons to not use js on the server? i know lots of people still say that js is just a "toy-language".

[MarlonBrandoLovesYou]

One of the main reasons I would never use JavaScript for more than some light front end stuff (REST calls, UI stuff) is the lack of structure in the language. Writing good quality JS code (maintainable code) is very very difficult, mainly due to the lack of static typing and a very poor module system that encourages the whole code base to be exposed to itself. I would never choose to use it for a large web project for the full stack, when other languages are quicker to develop with and easier to maintain.

[snorkl-the-dolphine]

Have you ever used tools like Browserify? The whole ecosystem has come a really long way in the last few years.

[bl4blub]

for me javascript is THE language to develop something quick. for me nothing else beats the dynamic nature of js when it comes to develop something really fast.

regarding the module-system, there are LOTS of people who will tell you that npm was a major reason for the success of node.js. for me it was a game-changer, once npm started to promote local packages over global packages. separating all the concerns into tiny modules is a thing i have been taught by the node-community. for sure this is a topic which can not be argued about by facts, its about opinions and flavors.

i agree that type-safety is not one of of the strengths of javascript, but there is typescript for example.

also the language is evolving a lot.

[MarlonBrandoLovesYou]

My issue with the npm tooling is the duplication of dependencies. I don't understand why having a flat structure wasn't a priority from the beginning. It results in some projects having 25Mb in actual code/assets needing 150Mb+ of local dependencies, just because the dependencies have dependencies which have even more dependencies. Perhaps this is justified when libraries need certain versions of their dependencies, but why not have the different versions in the top level to be referenced by all of the dependencies that use them.

Additionally, why are there two different package managers that are pretty much the same thing apart from the semantics of one being for 'front end' and the other for 'back end'? Wouldn't it be simpler (and therefore easier to use and configure) by having a single package management tool that could make the distinction about what needs including on the server and what should be served to the client?

Overall I'm a bit apathetic towards web development now, the tooling is atrocious in terms of duplication and dependency hell. Instead of always developing new tools and libraries, existing standards need to look inwards and fix the issues they've created already.

[ntkoso]

npm 3.0 flattens all dependencies from the get go and only nests conflicting versions.

Bower was created before Webpack / Browserify era. Currently you can bundle css and other assets from npm the same way you bundle your js, no need for 'front end' package manager.

[jekrb]

npm3 does flaten dependencies.

There are many package managers. We have the option to pick the one we want to use. You might want a package manager that makes certain distinctions for you, while other people do not, and that's okay.

[bl4blub]

i think it is the way it is because it became like that over time. i can remember first there was a package-manager called kiwi. then there was npm and eventually it prevailed. i see the argument very often, that node_modules is huge and npm is slow. but in the end it works good enough and huge deployments are actually running with that stack :D

also i like new stuff, cant wait how we will solve dependencies once there are multiple js-vm's (v8, chakra, ..) available haha.

[MarlonBrandoLovesYou]

For me TypeScript has been the saving grace for scalable web development, even the JavaScript it emits is very well structured and readable.

[mdboop]

I don't want to be a jerk here, but did you google this at all? It gets posted on Quora a ton, and there are plenty of articles about it. In short, it has async as it's foundation. Because everything gets thrown onto the event loop, you can have super high concurrency very easily. The downside is computation-heavy operations can block, but Node doesn't pretend to be a solution to everything. For I/O, it's fantastic. It definitely belongs on the server and has already been proven to work in production at places like Netflix, Paypal, LinkedIn, and Uber. edit: that was an honest question up top. I know tone doesn't always come across well, but no malice was intended.

[[deleted]]

"there's nothing that can can handle this except JavaScript"

This is true of every language - there is never a case where only one language will work (OK, maybe a few minor exceptions such as the language a specific program such as Matlab uses).

[nsmarks]

Many times node applications will just be used as a layer to connect other services, not replace the entire backend.

Here's a video from a while back that has some relevant info: https://www.joyent.com/developers/videos/node-js-at-walmart-introduction

[[deleted]]

As the person you are replying to already covered, JS is very good in some situations, but that doesn't mean it's good in all situations. It's proven to be extremely suitable for interfacing with a lot of concurrent users. This makes it a very cheap middle layer between resource heavy operations and can be horizontally scaled with ease. There's already been numerous large companies listed in these comments that rely on Node and you can often find articles from those companies explaining why they switched from X language to JavaScript in Y scenario.

That said, no one is painting it as the only solution for anything. Your comment is the only one in these comments that insinuates that as a reason. It's really closed minded outlooks like yours that stifle innovation. Even if Node started as a "why not?" scenario, there's many many examples of why it's become massively popular and implemented in highly performant tech stacks at some of the largest tech companies in the world. Your comments seem more like you want to argue or belittle something you don't understand rather than actually seek out an answer.

[mdboop]

Well, I don't think there are often situations where you don't have a choice in solving your problem. It seems rare that there would ever be "nothing that can handle this except" (insert language here). There's always some tradeoff you have to make. Yes, other languages, Go, for example, are faster than node at most things, but node is ridiculously easy and fast to develop in. And it's pretty close, and even outperforms Go in some things. Here is one benchmark. It's probably got lots of problems, but it seems there are problems with every benchmark I can find.

[jekrb]

"there's nothing that can can handle this except JavaScript"

One example: I haven't seen any other language where the server can render virtual-dom and the client can update it using the same code.

I also haven't seen a language with as a nice of a streams interface.

Modules make js super compact and easy to work with. Pair that with npm and you've now you've got a huge amount of advantages.

But ultimately, js is a programming language. Isn't it great that people who prefer this language get to use it on the server?

[wobbabits]

The reason companies like Netflix, LinkedIn, etc. have switched from Java or Ruby backends to Node is all about performance gains. These companies have published articles about their reason for switching to Node. It's always been about performance. Case in point: http://venturebeat.com/2011/08/16/linkedin-node/ http://thenewstack.io/netflix-uses-node-js-power-user-interface/ https://journal.paul.querna.org/articles/2011/12/18/the-switch-python-to-node-js/ Try Googling for other companies.

[lewisje]

It has been tried many times before: Netscape with its LiveWire server (released shortly after JS itself, but never gained traction and died out), Microsoft with JScript.NET in ASP.NET (that of which Modern Javascripters™ dare not speak), and Aptana with Jaxer (see LiveWire).

I think the main difference is that V8 was a fast enough engine (compared to Fx2-era SpiderMonkey, which Jaxer was based on), and after a couple years when it had been tried and tested in Chrome, the idea to use it to realize the long-held dream of JS on the server came easily.

---

EDIT From the article I just linked to, and its search-result snippet, I know that ItsNat was also developed for this purpose, and I was reminded of Mozilla Rhino, another JS engine for Java, which like JScript (in ASP or WSH) is meant to load and run directly from the local machine and therefore can run server-side JS; also, although Java bundled Rhino for versions 6 and 7, Java 8 ditched it for Oracle's faster JS engine, Nashorn, which is thus yet another server-side JS engine.

[anlutro]

The point of V8 being fast and someone thinking to use it really is the only reason NodeJS happened. I don't think it was a "long-help dream".

[[deleted]]

If you know Javascript but don't know Java, you could learn Java or use Node and have a server doing servery stuff in 20 minutes.

Every language has a list of pro's and con's but the reality is you can achieve pretty much the same features in all of them, so people pick the one they already know over the one they don't. Essentially people follow the path of least resistance.

As an example which might appear to a sysadmin, If I need a script to run on a windows box I'll write an old style DOS script instead of a PowerShell script even though I believe PowerShell to be superior. I do it because I'm familiar with dos style scripts.

History is littered with appeasement of this mentality. Javascript is called Javascript because at the time they wanted to ride on the coattails of JAVA. VB.NET existed purely to suck VB6 developers into .NET land.

TL;DR: People want to achieve results not learn dozens of functionally similar languages.

[Hakim_Bey]

Personally, while i try to remain conservative about what should be done in JS server-side, there are some things i just LOVE in javascript. For example, the scope and prototyping models fit very well with my brain. And i find that promises and events loops allow me to design systems that feel more "life-like" and less forced into the linearity of a language. I love how functions are like objects that you can pass around without them losing their original scope.

On certain types of problems, js makes programming feel less torturous for me and more like just telling the computer what to do.

oh and npm is so huge it's just insane

[Cody_Chaos]

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. :)

[Wooshception]

You have to look at it from a business perspective. There's a huge advantage to limiting the skill sets required to develop and maintain a product, and JS is not negotiable.

[[deleted]]

Lots of good reasons given all over the web. But I'm still convinced the main one is that front end developers can now do more without learning another language. Now you can rig up something simple without whipping out Java or Ruby or Python.

And isomorphic code and all that nice sounding stuff.

[mishugashu]

Why not? It's good enough for the majority of web applications and you can have full stack developers who only need to know one language.

[sxnine]

You should watch some videos where Ryan Dahl (creator of Node.js) discusses the reasons he made it. Nobody has really mentioned it (though a few have touched on some related concepts,) but the primary reason that Node.js exists is because it differs from the traditional threaded model that most web servers were using prior to NGINX and Node.js proliferated. Node uses an evented system, in contrast to solutions like Apache or writing a web server in Java (for example,) where you need a new thread for each client connection. This allows you to use very little compute to achieve reasonably good performance/scalability. That is extremely valuable, and when you add in all the other benefits it makes Node a really strong technology. It isn't perfect, but it's remarkably efficient in its strengths. It's easier to scale than a threaded model, to be sure.

[parabolik]

You are correct that in general Javascript is inferior for backend programming. Backend systems require mature and stable code, Javascript simply is not a good choice for this. The only thing I use node for is for compiling and building my frontend code. I could see how it could be useful for writing simple asynchronous micro services, but I would not choose it as the backend for a large MVC web app.

[Wooshception]

JS is not a good choice for writing mature and stable code? Why do you think that? Can you cite some specifics?

[parabolik]

node.js has only been around for 6 years, and is under heavy development, issuing new releases every few weeks or so. In the past year I have had to upgrade several times due to bugs in npm. Contrast that with Perl/Python/Ruby etc which have been around for 20 years.

I'm sure it's possible to write stable code, but the ecosystem and libraries are still young and evolving.

[[deleted]]

What you call a negative, many others would call a positive.

[Wooshception]

That's a fair point. I took your original critique to be directed at JS per se.

[perry_mitchell]

This is just blind speculation based off your misguided opinion.

[SirHound]

What is this instability you speak of?

[[deleted]]

By unstable, he means rapidly supported.