
Ask HN: Node.js for complex and long living software? - velmu
Every once in a while I&#x27;ve been wondering is Node and JavaScript feasible to create complex and long living applications?<p>Not only SAP and other behemoths, but complex web applications like online banking and other similar business-critical system. I&#x27;m sure the tech can do it, and the asynchrony pays off in performance in some applications.<p>ES6 is adding classes that will make JavaScript more familiar to developers from other languages. But the field moves so fast that I think even the most skilled JS developers of today are writing something that will be horrid legacy in 2020.<p>Most &quot;Success with Node&quot; case studies emphasise performance and the applications themselves tend to be rather limited in functionality. All technologies move forward, but the JavaScript world seems very unstable at this point.<p>Is there some unique advantage that Node can offer over the more traditional languages like Java, ASP and PHP that are more mature?<p>Or is it just better to leave JS for integrations and other simpler tasks. For now, that is.
======
lollipop25
> is Node and JavaScript feasible to create complex and long living
> applications

If you know how to quench fires like this one:
[http://techblog.netflix.com/2014/11/nodejs-in-
flames.html](http://techblog.netflix.com/2014/11/nodejs-in-flames.html)

> Not only SAP and other behemoths, but complex web applications like online
> banking and other similar business-critical system. I'm sure the tech can do
> it, and the asynchrony pays off in performance in some applications.

Consider using Java instead. There's a reason why Java is still around in the
enterprise, and that it's version (assuming it follows semver), is still at
1.x.

> ES6 is adding classes that will make JavaScript more familiar to developers
> from other languages.

It's just sugar. It's still prototypal inheritance underneath. If you start
thinking that JS classes are like classical OOP classes just because JS now
has classes, then you're in for a lot of hurt.

> Is there some unique advantage that Node can offer over the more traditional
> languages like Java, ASP and PHP that are more mature

Besides the fact that you can prototype apps in half the time and mashing the
keyboard gives you Mona Lisa? Nothing really. If you look closely at the JS
community, they're trying to solve problems that have already been solved in
other languages (streams, module management, socket connections, p2p, better
syntax etc.)

> is it just better to leave JS for integrations and other simpler tasks

Yes. As a JS dev since forever, JS is best suited for quickly prototyping apps
(Phonegap comes into mind), mock servers and API endpoints (express is good on
this one), bots and automation (chatbots are a good example). For other tasks
like banking, security, gaming, business etc, look elsewhere.

~~~
atmosx
> If you know how to quench fires like this one:
> [http://techblog.netflix.com/2014/11/nodejs-in-
> flames.html](http://techblog.netflix.com/2014/11/nodejs-in-flames.html)

Awesome article, thanks for sharing. However, doesn't say much about JS per-
se. The problem was a bug in Express.JS (see here[1] the resume) not in JS :-)

[1] [http://www.infoq.com/news/2014/12/expressjs-burned-
netflix](http://www.infoq.com/news/2014/12/expressjs-burned-netflix)

~~~
lollipop25
Well the point was:

\- At some point, you'll eventually offload most of the JS effort to pre-
exising modules that will more or less have bugs like this. And these kinds of
bugs aren't apparent during development, or on a controlled environment. They
happen on a production setting, which is at times hard to replicate.

\- JS is a terrible language in terms of debugging. There's no "compile time
errors" to kill half of the bugs early. The best that tools at the moment
could do is infer types based on static analysis, but that's it. If code is
written in a very dynamic fashion, then you keep these tools guessing.

------
empthought
Lately I've been working a lot with the Nuxeo[1] document management platform.
Almost ten years ago, they switched their backend from Python/Zope to Java[2].
I'm also working a lot with a Django-based web app. Based on my observations,
I think for "complex and long-living" apps (like the Nuxeo platform),
JavaScript is no better (perhaps worse?) than Python, and if I had to worry
about extensibility and maintainability over a decade, I would make the same
decision that the Nuxeo people made.

In a retrospective[3] from five years ago, Nuxeo claimed:

"In terms of performance, I would say we scale 10 to 100 times more, depending
on the metric you take. In terms of features, it's around 4 times the scope of
what we had. In terms of developer compatibility and ease-of-use, it's about
the same, but with a lot more tooling and experience. We've been able to
double, if not triple, the capabilities we had on the older [Python]
platform."

"When customizing with Nuxeo-based apps, you don't fork the UI to customize
it, you contribute to it using plugins; it's a very open and extensible
model."

Having worked with the "plugin" model they built, I am at a loss as to how one
would realistically accomplish the same thing effectively with either Python
or node.js. The same things that make Python and JavaScript convenient for
small scripts (duck typing, no checked exceptions, minimalist frameworks, lots
of metaprogramming options) make it less convenient for platforms with the
scale, scope, and customer requirements of Nuxeo and its competing products.

[1]: [https://github.com/nuxeo/nuxeo](https://github.com/nuxeo/nuxeo)

[2]: [http://www.infoq.com/news/nuxeo-zope-java-
migration](http://www.infoq.com/news/nuxeo-zope-java-migration)

[3]:
[http://www.infoq.com/articles/nuxeo_python_to_java](http://www.infoq.com/articles/nuxeo_python_to_java)

------
velmu
Here is one comment from Reddit to get you started:

"Express is the most popular web framework, but the repo is stale. Koa.js, the
successor praising itself as "next gen" is a fucking mess as soon as you have
anything more complex than rendering a template. Callback hell has better
error handling than promises and generators, but it's next gen so we use
try/catch for control flow now." \--
[https://www.reddit.com/r/programming/comments/3rrh9z/javascr...](https://www.reddit.com/r/programming/comments/3rrh9z/javascript_is_eating_the_world/cwqozdc)

~~~
icpmacdo
This is a concern for me right now, I have the most experience writing
JavaScript for client side web and Cordova but want to get into the backend
with go looking like the most sane choice.

------
czbond
I think it depends on the job of the software. A client i am working with is
using it successfully in some areas, not successfully in others. API's, web,
some web back ends - it does well. Rock solid, transaction heavy, worker
services - no. We have a back end service that Node just keeps barfing on
(wrong use case), that gets up to 2GB process size due to promises calling
promises. We're replacing it with performant golang microservice.

~~~
czbond
To add more to this, I personally will stop using node - except for in api
endpoints. Our test patterns, timing, and development time have shrunk using
go vs node. JS's flexibility can cause issues. I'm using go for all api
endpoints, microservices, and transaction systems. I use node for
microservices in which the library structure in go isn't "formed enough" \- or
quick services.

------
benologist
Anything you use will be obsolete by 2020 unless you are updating your app to
stay current. If you're preserving your environment it will still function
regardless of your stack or how old/obsolete the code and frameworks are.

