5 ms·

Ask HN: Node.js for complex and long living software?

• velmu 11y ago
  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/javascript_is_eating_the_world/cwqozdc https://www.reddit.com/r/programming/comments/3rrh9z/javascr...
  • icpmacdo 11y ago
    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.
• benologist 11y ago
  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.
• czbond 11y ago
  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 11y ago
    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.
• empthought 11y ago
  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
• lollipop25 11y ago
  > 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 11y ago
    > 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 11y ago
      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.