If this article is true, it paints a concerning picture. I don't want to research libraries, understand the pros and cons of them, run into problems, then switch to another library, and so on. I want there to be a default that works out of the box for the majority of use cases. There can be alternatives, as long as there's a default that works out of the box for most people and most use cases.
After a year of using Node.js in production
181–190 of 248 posts
Re: After a year of using Node.js in production
#182Earlier quoted context omitted.
Elixir/Phoenix, Go/ , Rust/ ... should all outperform node.js easily, plus they're actually parallel and not just concurrent AND are much more solid languages to begin with.
But aren't all Node.js deploys fronted by a reverse proxy (like nginx) to multiple node processes? That gives them actual parallelism in practise, right? Or is it remotely common to just have a single node process and never use more than one core?
splitting the load through multiple node processes is fine for simple usecases and in general you're fine if you do mostly IO stuff.
But there are usecases that have to crunch numbers or do other CPU intensive algorithms that can be parallelized on the algorithm level. This is where node.js just falls apart. Additionally, if an algorithm requires quite much memory (multiple gigs), node.js performs very poorly.
Most companies that do actual CPU intensive work have services written in other languages to handle this, and "we're using node!" mostly means that they just serve results or do other IO-Tasks with node. But not the actual work.
Re: After a year of using Node.js in production
#183> You use Grunt!? Everyone uses Gulp!? Wait no, use native NPM scripts! Although couched as a criticism this is actually the community fixing itself. The evolution from Grunt > Gulp > npm scripts is movement away from needless complexity towards simplicity. Npm scripts are effectively just Bash commands that build and manage your project, which sometimes employ small, unixy tools written in Node. This self correction…
And someone needs to pay for the overhead of 'community fixing itself'. And the Promise/A+ spec is so bare-bones, it is laughable. And the actual issue is that not every module is embracing it yet. Sure, it will all be fixed. For freeeee :)
Whether the Promise/A+ spec is bare bones or not doesn't matter, the reference implementation is the ES6 native Promise, which is part of Node and now natively in browsers too. This is concretely what a promise _is_, use a different sort of promise at your peril.
Re: After a year of using Node.js in production
#184The Netflix.com site and webapp runs on Node (and talks to a number of services written in mostly JVM based languages). While we encounter challenges just as we would with any other language -- it works for us and I would argue that it's a pretty big application. There's always a multitude of ways to get something done, and it's up to you to decide what tool will do it best. Don't treat any one language as an end-all…
> There's always a multitude of ways to get something done, and it's up to you to decide what tool will do it best Well said. By the way, what is Netflix's take on Promises vs RxJS?
> By the way, what is Netflix's take on Promises vs RxJS?
We've been doing tons of research into the Netflix methodology and teams are highly compartmentalized (albeit communicate richly). This means that when you ask "What do you do at Netflix?" you should really be asking "What does team X do at Netflix?" or "Does any team at Netflix do X?"
For instance, unless things have changed or I have the story wrong, JVM is used for the streaming because that's the tool which that team chose. The other teams merely communicate with it over an API (regardless of client language).
Re: After a year of using Node.js in production
#185Earlier quoted context omitted.
So somebody found a project somewhere on the internet with an exceptionally complicated build process, and you use it to say npm scripts are broken? Sorry, that's absurd. Looking at that particular build process, I don't think a Makefile could have been crafted to make it much simpler or smaller. In that example, the problem lies with the complexity of what they're having to do, not the tool. Npm scripts are really j…
It's an inflated example of what all npm script projects become, imo. First you just have "test", then you add "build", then you separate your "test" into one for the browser, one for Node, one for CI, then you need scripts that combine those together; then you create different "start" versions depending on environment... It blows up quickly. > Npm scripts are really just shell scripting, which means all the real pro…
Admittedly, my first 2 or 3 npm scripts based build processes did start to get a bit ugly. But I'm much better at writing them now, so they stay pretty sane.
> That's fine, but you're missing critical features that Make provides; make won't even rebuild a target if no files have changed.
WebPack does this for me too. Also my ava tests don't rerun for files that haven't changed while watching.
Genuinely curious, what scenarios precisely do you find this feature of Make useful?
Also, Make isn't truly cross platform ... and since I sometimes work with Windows devs this would be a problem.
Re: After a year of using Node.js in production
#186Earlier quoted context omitted.
Speaking only for myself, a middle-weight .NET dev who was, not too long ago, working desperately to find my footing in all this: 1. I think the learning curve to doing good work with Node is really shallow at first, and then it quickly gets almost vertical. 2. I think that ALL of the other server-side language/framework combos (Ruby/Rails, Python/Django, C#/.NET, PHP/Symfony, etc.) make it significantly easier for a…
> 2. I think that ALL of the other server-side language/framework combos (Ruby/Rails, Python/Django, C#/.NET, PHP/Symfony, etc.) make it significantly easier for a "merely-good" dev to make really good Web applications. All of those frameworks are threaded/synchronous - they are maybe 10 times easier to use and potentially 100x slower (less concurrent) than Node. The ruby equivalent isn't rails, its eventmachine. Mov…
C#/.NET isn't threaded.
It was the first widely used language to feature async-await.
Re: After a year of using Node.js in production
#187I usually don't respond to anything which I feel is just another "language war" provocation, but whenever I see these type of reviews I'm mystified. I've developed in many languages and frameworks, both well known and lesser known - decades of client and server side of C/C++, Javascript, Lua, Java, Python, PHP, Perl, Lisp. Pascal (just to name a few) in projects of all sizes, and not once did I have the thought "this…
You are a lucky person if you have used so many languages and never missed a thing in a language you are using at the moment that is readily available in some other language you have used in the past and that would make everything so much simpler!
For example the OP got fed up with Python and switched to Node. Now he is fed up with Node and switching back. I can say that focusing on the downsides of the tool I am currently using and the upsides of the tool I am not using is a fairly common thought pattern for me too. Of course the way to combat it is to remember that it is very rare for some tool to be strictly superior to others and just focus on the task at hand.
Choice is a very dangerous thing. When reading the book "Coders at work" I was struck by how primitive some of the old computing environments were. But that did not stop those people from doing amazing things with them. I now think that was partially to their advantage because they were freed from choosing the language/framework and so could concentrate on doing, you know, actual stuff.
Re: After a year of using Node.js in production
#188Re: After a year of using Node.js in production
#189Earlier quoted context omitted.
Yes, the Javascript world is quickly evolving both on the front end and backend, and of course that can be exhausting but I have to disagree with both conclusions that (a) this means the tech is immature, and (b) the community's readiness to make changes is "holding it back". The js world is very unique in its ability to evolve quickly and things have improved massively over the last few years. Now, apart from the ch…
The problem I see that in this case "evolving" looks suspiciously like running in circles without going anywhere.
A good example mentioned in the article is the "npm scripts -> grunt -> gulp -> npm scripts" evolution in best practices for building.
Re: After a year of using Node.js in production
#190Earlier quoted context omitted.
The same problems you cite for node.js are the reasons why a lot of devs love node.js. Its much easier to do your own research and find the best module to solve a particular problem you are having then to shoehorn into some larger monolithic framework. Also its a lot more fundamental then that - Node.js has prolly the fastest iteration cycle for any platform out there since its so easy to create your own module - it…
> python doesn't have a good programming model to even begin to address those concerns This isn't even close to true. Anything JavaScript has to express logic in the face of asynchrony, Python has too. There are a half-dozen asynchronous web servers written in Python. There's not as much of a culture of writing APIs that way in Python because it's generally a terrible way to program, and threads/OS processes are good…
> There's not as much of a culture of writing APIs that way in Python because it's generally a terrible way to program
I would love to see evidence for you making that statement. Almost every programmer would put out their fav programming language as the 'right' way to program.
> everything except HTTP servers with absurd numbers of concurrent connection
Once you introduce async operations in your code - you need to follow the execution path through. http request can be async - but then what if the http request results you doing a db lookup or some form of file handling ? you need to make the whole thing event driven.