
Why JavaScript Will Become the Dominant Programming Language of the Enterprise - mkrecny
http://readwrite.com/2013/08/09/why-javascript-will-become-the-dominant-programming-language-of-the-enterprise?utm_content=awesm-sharebuttons&utm_source=t.co&awesm=readwr.it_phr&utm_medium=readwr.it-twitter&utm_campaign=
======
octo_t
>> Node.js has over 30,000 modules available

how many of these are over a year old? how well maintained are they? how
battle proven? how well is v8 going to be maintained 10, 15 years from now?
can we buy an extended support contract for v8 from Google?

these are also questions people in enterprise want to know. how well does it
interact with our existing CLR/JVM stack that we've used for the last 10
years?

I have never been convinced by the "writing server side and client side code
in the same language is good" argument, different jobs require different
tools. Someone once said of this:

'you know how to use a knife, so you bring a knife to a modern war fought with
guns, tanks, and missiles while shouting "at least I can use the same tools
when I eat and when I fight! I save so much time!" before somehow managing to
shoot yourself in the foot anyway.'

~~~
pestaa
I like your metaphor up to the point where I manage to shoot myself in the
foot with a knife.

~~~
officialjunk
haha. didn't catch that one. english idioms...

~~~
jamesbritt
I thought it was a deliberate non sequitur.

It comes off as pretty funny that way, and helps make the point.

"He could shoot himself in the foot with a knife."

------
chadrs
No dynamically typed language is going to be "The Dominant Language Of The
Enterprise" anytime soon. When you have hundreds of mediocre developers in
cubicles pounding away at a single, huge, codebase, you're going to want as
much compile time checking as you can get. You're going to want the ability to
refactor and immediately see everything that needs to change, etc.

For a new language to have a shot at it, it should be statically typed and
probably run on the JVM or CLR.

~~~
Eiwatah4
If the enterprise wanted as much compile time checking as possible, why
haven't they adopted something like Haskell years ago? The checks done by the
type systems of the JVM and CLR are laughable in comparison. There must be
some different reasons at play here, too.

~~~
lmm
They're getting there. The leading edge of enterprise is already using scala
or F#, which have a lot of the power of Haskell (in fact I'd argue scala's is
more powerful in some ways, e.g. typeclasses cease to be a special case).

In terms of using Haskell in the enterprise, it isn't standardized enough
(most libraries rely on GHC extensions), the library ecosystem isn't mature
enough, cabal is still a mess (it's too easy to get your dependency tree into
a broken state), there's not enough commercial support, there's not enough
deployment/monitoring infrastructure around. Fundamentally, it was produced by
academics who didn't care about selling it to the enterprise, and the effort
to address these concerns hasn't entirely happened yet. It's getting there,
and I think we'll see more of it as time goes on.

------
wavesounds
Simple learning curve? The thing is its really easy to write bad Javascript
and a lot harder to write good Javascript. For that reason I think it has a
much higher learning curve then most of the current languages used for web
development.

~~~
cliveowen
Exactly, any language that lets you program at the same time in an imperative,
functional and OO fashion is anything but easy to pick up, let alone master.
Personally I still have to get around and learn it, it just seems an extremely
daunting undertaking.

~~~
wavesounds
Check out Douglas Crockfords book "Javascript the Good Parts" and/or his talks
at Yahoo [http://yuiblog.com/crockford/](http://yuiblog.com/crockford/)

------
karlgoldstein
This article is content marketing for Appcelerator. It builds a straw man of
enterprise development that is convenient for Appcelerator's business model
(scaling JavaScript applications), neglecting to consider other concerns such
as stability, maintainability and support.

------
jiggy2011
With large software projects you want a language that is relatively easy to
read. This is the biggest problem with JS, it's pretty easy to write but can
become unreadable pretty easily.

Even best practises as described by "the good parts" are full of nested parens
and functions , .call()s and IIFEs

------
mbesto
Here's my list of why other frameworks have become the language of the
enterprise: (you can draw your own conclusions as to why JS won't fit).

1) Large resource supply - .NET, Java, etc resources are cheap, quick to
deploy and abundant.

2) Pay-for library support - I can pay Oracle and MS gobs of money to support
me when things go wrong. (how quickly they fix things is another question for
another discussion)

3) Supported engine - Enterprise customers pay IBM, HP, MS, etc for support of
JVM's, etc in order for the code to run.

4) Scalability - There is a reason programs at scale are written in languages
that are written for performance. "Enterprisey" languages are verbose and have
to be compiled because they allow for better control of performance at scale
(notice I didn't say they perform better, there is a big distinction)

Lastly, JS _is_ already an Enterprise language, but mainly for front-end only.
So the argument is whether it becomes a back-end language.

------
elorant
Try writing anything larger than 10.000 LoC and JavaScript becomes a pain in
the ass. No matter how many frameworks will appear unless there are
fundamental changes in the language I don't see it making it to the
enterprise.

~~~
cldr
TypeScript really helps with this.

~~~
camus
Enough with Typescript. using a transpiler doesnt make the language better.

~~~
kalms
Why is it worse than using, say Objective-C to improve C? Genuinely curious
here.

------
dpweb
I can't help but attribute all the JS bashing to good old-fashioned tech nerd
snobbery.

A scripting language IS a programming language.

Write code -> some method of compilation -> Computer executes == programming
language.

------
bereft_orange
Saying that something will have the same language on client and server is
misleading: javascript (and most other languages) have very simple syntax -
it's more about the libraries involved. Node.js and the browser environment
are totally different (and I doubt there are many packages written for both
settings).

Even if everyone were working in JavaScript, seems unlikely that you'd be able
to be both an awesome client-side and server-side developer.

~~~
deckiedan
I'm not a node guy, but I thought one of the big advantages was just that...
that you could use a lot of the same code. ORM/object modelling should be fine
on server or browser, also template rendering, data/form validation, etc.

One thing that is a pain in conventional web development is for a lot of these
things having to implement them twice (or write clever automatic converters or
whatever to generate the backbone.js (or whatever) boilerplate models from the
original django/rails/whatever/schema.

------
johnfuller
If we are talking front-end, then Javascript is already the dominant language
for EVERYONE (for the web anyways.)

> Big brand names like GM, Yahoo, Dow Jones, Walmart and Dell have all
> deployed Node.js and are touting its merits.

It's as if the borg is chanting node while it slaves away on its corporate
machine. I bet if I asked Michael Dell what he thinks about Node, he would
probably tell me to F-off.

I googled LinkedIn and the first result talked about how they replaced their
Rails app with a Node app. Right, when I see an article talking about how X
huge corp replaced their Scala app with Node then I might be more convinced.

We don't need to be locked into any one tool though. As we learn how to build
things better we find that we can route our pipes to different boxes which
handed different things rather than having one huge box handling everything.

------
kalms
I love every time an article like this appears. Everyone is immediately on the
fence, bashing JavaScript furiously. Yet momentum doesn't appear to be
declining?

I'm a JavaScript developer mainly, with a background as a front-end oriented
developer (php), but I also dabble a bit with C/Objective-C - especially since
JavaScript got me interested in application development in general. JavaScript
does bring a lot of freedom, a freedom that can hold you back, if you're not
careful (code bloat, callback hell etc). The thing is, JavaScript is just
plain fun to write in, and the responsiveness and full-stack capabilities are
amazing.

I think we just have to accept that JavaScript is here to stay. And should its
popularity fade, I should be ok with that as well. But until then, I'll keep
having fun at work.

~~~
frostmatthew
There's a HUGE difference between "here to stay" and becoming the "dominant
programming language of the enterprise"

~~~
kalms
I'm not saying the article is right either, since it is a rather bold claim.
But it is just as one sided to write it off as stupidity, because JavaScript
is dynamically typed - or whatever. I can't force anyone to like JavaScript,
nor would I like to, but my personal experience does lend some credence to OP
from where I'm sitting.

I think the biggest problem with OP's claim is the lack of true enterprise
software written in JavaScript. I can't think of anyone, besides a few
lightweight SaaS applications.

We're currently building a large-scale application for public schools here in
Scandinavia, but it is augmented by a .NET service backend. I hope we'll get a
swing at a full-stack solution soon.

------
banachtarski
Does anybody actually believe this?

------
blackysky
I like JavaScript and node.js but I simply can't wrap my head around
callbacks. Some people simply love to nest callbacks... Anytime I see that it
drives me crazy....

~~~
SwellJoe
Callbacks are possibly not the best way to solve concurrency issues. Node.js
does it that way, but there's no inherent reason JavaScript should only solve
concurrency problems with callbacks. It would be possible to implement a wide
variety of concurrency models in JavaScript, and I'm sure people have and
will. Node.js happens to be the early winner in that space.

We are still pretty early in the JavaScript story on the server side.

------
jloughry
Steve Yegge has been saying this for the past five years.

------
rayiner
Worse is better.

------
usablebytes
Will?

------
consonants
Enterprise software is about long-term maintainability, compatibility, and
comprehensive support for all included components. Pulling packages from npm
and the like unfortunately will not satisfy those prerequisites.

~~~
WalterSear
A recent nodeup episode discussed how many enterprises aren't using npm
packages unless they wrote them in house, because they don't want/trust any
code they haven't written themselves.

~~~
jmspring
I've also seen other companies who do use third party modules through npm make
sure they have local copies documenting the version, source, source url, etc.
Just in case a particular project disappears.

One thing I wonder about, so far it seems to be mostly doing ok, but will
NodeJS suffer the library versioning problems that plagued Java when I last
used it...frameworks importing 2-3 different versions of Apache Commons for
instance.

