

Business Case for JavaScript and Node.js / JXcore - nodefan
http://jxcore.com/business-case-for-javascript-and-node-js-jxcore/

======
couchand
As someone who's been emphatically trying to make this case for a while, I'm a
little disappointed. There are a number of good points, but the bulk of the
article is just a rehash of open-source trends and job posting data. I was
hoping for a more in-depth analysis of the tradeoffs, data on productivity
increases, etc. I'm not sure popularity figures will be very compelling to the
entrenched interests.

And the article fails to mention the single biggest feature of server-side
JavaScript development: the ability to write isomorphic code that runs the app
on both client and server. No more duplication of development and maintenance
effort, writing business logic in both JavaScript and some heavy traditional
language.

Once and only once FTW!

------
forgottenpass
_It is hard to argue against these numbers._

It's actually quite easy to argue with those numbers.

They're not measuring what you think they're measuring. See github's bad
language detection if I put jquery in git. Also, number of modules available
does not imply utility, quality or size, nor take into consideration the
utility quality and size of standard libraries.

There is no acknowledgement that there is a domain where javascript is the
only option, and that adoption is not by choice but out of necessity (in which
case, there is no reason to argue for a language, you're either building for
that domain or not).

There is no distinguishing between frontend and backend javascript. Growth on
the frontend is not a case for node.js. Unless I'm assuming I'll use the exact
same employees for both, that they only know JS and that they're so worthless
they can't pick up a second language that is probably very close to javascript
evolutionarily.

The above points were specific, but the overall argument presented is that
javascript is undergoing rapid growth. Not a great reason to jump on a
technology, but even if you're willing to jump on something just because it's
growing, it doesn't look at the context of _WHY_ it just started growing.

 _It is crucial to understand the pros and cons of using JavaScript._

Well yes, but that's a gimmie, it's crucial to understand the pros and cons of
just about everything in your field. It would have been nice had this article
gone into those pros and cons, but this was not a business case for
JavaScript. It was a persuasive essay that the reader should evaluate JS on
their own and possibly create a business case for it.

~~~
couchand
_See github 's bad language detection if I put jquery in git._

Well, actually, no [0]. Just use the standard name and Linguist ignores it.
But your larger point is still valid: popularity does not imply utility.

 _Unless I 'm assuming I'll use the exact same employees for both_

You really should be. If your devs only understand a siloed part of your
codebase you're doing it wrong.

 _that they only know JS and that they 're so worthless they can't pick up a
second language_

Holy private demons, Batman! I don't know how you've been hurt in the past but
please don't bring it here. There are plenty of valid reasons to intentionally
avoid introducing a second language on a project. In fact, I'd argue that the
burden of proof is on showing why it's worth introducing the additional
complexity.

[0]:
[https://github.com/github/linguist/blob/master/lib/linguist/...](https://github.com/github/linguist/blob/master/lib/linguist/vendor.yml#L56)

------
zo1
So, nodefan, are we actually going to get concrete technical reasons? Or are
you just going to try shove down the old "look how many github projects for
_javascript_ are popping up" and "look how many javascript job openings there
are" stories again?

~~~
nodefan
I am not sure if you read the whole text. But it clearly says in the first
paragraph "This article will examine JavaScript and Node.js/JXcore and view
them from a business standpoint". It is not trying to be a technical article.

------
lucio
pure JavaScript has too many ways to introduce subtle bugs into large
projects, which also become a nightmare to maintain. From a hacker
perspective, node.js and js are great. js is a beautiful and extremely
powerful lang. From a "business" perspective -even more if your business data
better fits a RDB-, IMHO, javascript, node.js+ a LARGE business project are a
recipe for disaster. (If you add ORM to the mix, you're doomed).
[http://blog.codinghorror.com/object-relational-mapping-is-
th...](http://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-
of-computer-science/)

I believe a compiler-to-js like Typescript makes using JavaScript+node in a
large business project more manageable (disclaimer: I've not tried Typescript,
but I've coded my own compile-to-js lang out to frustration with medium-to-
large js projects:
[https://github.com/luciotato/LiteScript](https://github.com/luciotato/LiteScript)
)

TL;DR: My two cents: Not a good business case for a business IF a classic RDB
fits your business data.

