Why Node.js is becoming the go-to technology in the Enterprise • Hacker News Board

Re: Why Node.js is becoming the go-to technology in the Enterprise

#51

Post by awj » Tue, May 13, 2014, 5:39 PM UTC

twerquie wrote: post #45

jerf wrote: post #37

Earlier quoted context omitted.

But... if you're going to bolt on an "async" library, bolt on threading, and bolt on strict typing, why not use something that starts with that stuff? And ends up doing it better since it was actually created with that stuff in mind, instead of aftermarket bolt-ons? Saying that those things "fix" Node amounts to an admission that you shouldn't have started with Node in the first place.

Because bolting reusable libraries together is 90% (meaningless number alert) of what we do when assembling modern applications. And in this respect, Node is perfectly suited to the job, boasting a) A small core API instead of a sprawling standard class library b) A highly composable export and require mechanism, better in some interesting ways than what exists in other systems (1) c) The fastest growing and soon to…

Bolting reusable libraries together is great for some things, not so much for others. How much of that large package repository uses different (or worse, conflicting) solutions for abstracting async programming? Some batteries really are better off being included.

Re: Why Node.js is becoming the go-to technology in the Enterprise

#52

Post by awj » Tue, May 13, 2014, 5:40 PM UTC

yid wrote: post #49

yid wrote: post #19

It's a little tiring to see some of the same old fallacies about Node repeated ad infinitum in this thread. I suspect a lot of the complaints stem from poor development practices or not understanding norms in JS. JS isn't without its flaws, but can we at least put a few fallacies to rest: > callback hell There's no reason to be in callback hell if you use an asynchronous control flow library and stick to the standard…

Sigh...commenting on a Node thread on Hacker News, what was I thinking?

Instead of flippantly dismissing the comments, maybe you should think about what people are saying.

Re: Why Node.js is becoming the go-to technology in the Enterprise

#53

Post by [deleted] » Tue, May 13, 2014, 5:41 PM UTC

mantrax5 wrote: post #5

The real reason is quite simple. And I'm not trying to be bitter or anything, rather think like a businessman. The reason is... it's full of JavaScript kids out there, and because they're so many, they're all replaceable, and cheap. Like the commodity hardware servers they're programming. It's neat to cast this as "easy to attract and retain talent", but "rapid innovation" and "developer happiness" (especially consid…

[deleted]

Re: Why Node.js is becoming the go-to technology in the Enterprise

#54

Post by twerquie » Tue, May 13, 2014, 5:45 PM UTC

awj wrote: post #51

twerquie wrote: post #45

Earlier quoted context omitted.

Because bolting reusable libraries together is 90% (meaningless number alert) of what we do when assembling modern applications. And in this respect, Node is perfectly suited to the job, boasting a) A small core API instead of a sprawling standard class library b) A highly composable export and require mechanism, better in some interesting ways than what exists in other systems (1) c) The fastest growing and soon to…

Bolting reusable libraries together is great for some things, not so much for others. How much of that large package repository uses different (or worse, conflicting) solutions for abstracting async programming? Some batteries really are better off being included.

Different yes, conflicting no.

ES6 standard promises have landed in v8 (https://code.google.com/p/v8/source/browse/trunk/src/promise...) so it's only a short matter of time until the "batteries included" solution is available.

But that doesn't mean people will be forced to use them.

Re: Why Node.js is becoming the go-to technology in the Enterprise

#55

Post by wwweston » Tue, May 13, 2014, 5:46 PM UTC

I'm currently a tangential part of a project that just went from being a Java backend/middleware project with a Flash front end, to a Java backend with and HTML/JS/CSS frontend with a node-ecosystem build/package tools.

Two weeks ago I complained that we have two build tools (ant and grunt) and three package managers (ivy, bower, and npm) involved... but doing a build/deploy is a 5-step manual process that results in dependency errors.

This week things have improved -- the first build is a dozen manual steps, subsequent builds are only 2-3 steps, and though the deployment seems to be botched, there are no dependency errors.

Not sure how I feel about enterprise node.js.

Re: Why Node.js is becoming the go-to technology in the Enterprise

#56

Post by yid » Tue, May 13, 2014, 5:48 PM UTC

awj wrote: post #52

yid wrote: post #49

Earlier quoted context omitted.

Sigh...commenting on a Node thread on Hacker News, what was I thinking?

Instead of flippantly dismissing the comments, maybe you should think about what people are saying.

The whole point is that nothing new is being said here. Node is obviously a polarizing issue, and if you look at my comment, I was careful not to make the claim that its good for everything. "JS isn't without its flaws," I said.

And yet, I see "platitudes", "if you can't bother to do basic research", "can only induce laughter", "pile flawed layers on top of each other", and "amounts to an admission that you shouldn't have started with Node in the first place".

And the meaningful comments have the "reply" link disabled for me, so...

Re: Why Node.js is becoming the go-to technology in the Enterprise

#57

Post by smokeyj » Tue, May 13, 2014, 5:50 PM UTC

beering wrote: post #9

These stories about switching to node are pretty funny: "I switched from a dump truck to a motorbike and now I can drive way faster!" Node.js isn't really faster than most other popular languages with an evented library, but if switching to Node involves scrapping years of enterprise cruft, then maybe it's worth it. By the way, enterprise adoption of Node is surely a sign that we need to jump ship. Glad I got out of…

We see more apps being developed for the web with heavy javascript UIs. I've worked on a number of "enterprise" apps that are simply rest client SPAs. I could see a huge benefit to having a unified build/CI process for the UI and backend which makes a javascript runtime particularly unique.

Re: Why Node.js is becoming the go-to technology in the Enterprise

#58

Post by awj » Tue, May 13, 2014, 5:52 PM UTC

wasd wrote: post #4

> The old story of linkedin where moving to Node.js from Rails > for their mobile traffic, reducing the number of servers from 30 to 3 >(90% reduction) and the new system was up to 20x faster. It isn't as simple as that. There was a great article from a former linkedin engineer about why the original API server was so slow. [0] [0]: http://ikaisays.com/2012/10/04/clearing-up-some-things-about...

Yeah, of course the thing was faster. I would be upset if you didn't get this result after rewriting from a crufty old system that was never intended for the purpose it's serving into new code that uses appropriate technologies and benefits from all of your experience.

Other than Rails vs. Node as an appropriate platform for proxying slow api requests, the technology involved is basically irrelevant here.

Re: Why Node.js is becoming the go-to technology in the Enterprise

#59

Post by rdtsc » Tue, May 13, 2014, 5:52 PM UTC

yid wrote: post #19

It's a little tiring to see some of the same old fallacies about Node repeated ad infinitum in this thread. I suspect a lot of the complaints stem from poor development practices or not understanding norms in JS. JS isn't without its flaws, but can we at least put a few fallacies to rest: > callback hell There's no reason to be in callback hell if you use an asynchronous control flow library and stick to the standard…

I view async style wrappers not really getting away from callback hell. Calling it async doesn't make it better.

Python's Twisted has been around for ages with world class "async" and it is a pain to work with in large code base. Callbacks and async does work for demos and toy projects, which is I think one reason they got some adoption.

Representing concurrency contexts as a chain of callback functions or promises/futures/yields I posit is usually worse than a green thread or actor that gets and sends messages. It doesn't mean it cant' be done but if feels like why go through that pain when there are real threads/goroutines/tasks/Erlang processes.

> you can always just use the child_process library [3] to access spawn() and fork(). Remember those? Processes are a more nautral match for distributed computing than threads anyway.

I can do that with regular OS processes what does Node.js give me then? I can spawn processes from C, Python, anything.

> lack of strict typing

Weak typing is insane. This is 2014, there is not reason to silently turn "5"+[]+5 into anything except an exception. This isn't about a better developer, this is about sanity. Now I like use dynamic typing a-la Python and Erlang. But those have strong types. Adding a 5 to a string will blow up.

Re: Why Node.js is becoming the go-to technology in the Enterprise

#60

Post by brickcap » Tue, May 13, 2014, 5:58 PM UTC

gss77 wrote: post #27

beering wrote: post #9

These stories about switching to node are pretty funny: "I switched from a dump truck to a motorbike and now I can drive way faster!" Node.js isn't really faster than most other popular languages with an evented library, but if switching to Node involves scrapping years of enterprise cruft, then maybe it's worth it. By the way, enterprise adoption of Node is surely a sign that we need to jump ship. Glad I got out of…

OpenResty consistently handles 5 times more connections than Node.js, without requiring any of the continuation passing nonsense. As usual, popularity doesn't reflect upon quality at all -- Node.js is the Kim Kardashian of web frameworks.

I discovered openresty a few weeks back and I must say that I am very impressed by it. I think it is one of those frameworks that can be immediately useful to everyone who is already using nginx as it provides a better way to work with nginx than the default configuration rules.

And the best part is it is 100% compatible with nginx config file. So all your default locations and blocks that already work with nginx are going to work with open resty. You can now organize and program it better.