Business Case for JavaScript and Node.js / JXcore(jxcore.com)
jxcore.com
Business Case for JavaScript and Node.js / JXcore
http://jxcore.com/business-case-for-javascript-and-node-js-jxcore/
4 comments
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.
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.
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/...
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/...
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?
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.
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...
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 )
TL;DR: My two cents: Not a good business case for a business IF a classic RDB fits your business data.
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 )
TL;DR: My two cents: Not a good business case for a business IF a classic RDB fits your business data.
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!