GitHub Completes Its Acquisition Of The NPM JavaScript/Node.js Package Manager

[ermo]

If you don't like NPM there is Yarn, and if you don't like JavaScript there is TypeScript.

From Wikipedia: "TypeScript is an open-source programming language developed and maintained by Microsoft."

That's a nice bit of irony right there -- "whatever you choose, we're tier1 or even main sponsor of its development. <3 Microsoft."

As an aside it seems to me that Microsoft is outdoing Google when it comes to becoming the backbone of the important internet infrastructure projects with a development focus, thus dogfooding their cloud tech and ensuring that their own development tools and deployment products will have 1st class support for whatever tech they sponsor/own.

Clever strategy which is essentially embrace, extend and ... prosper?

The thing about Open Source is that, since it is generally a meritocracy where whoever puts in the work gets to make the decisions, it also means that -- on a larger scale -- whoever pours in more engineering resource will be the de facto leader of any given project (if you want a high profile example, look at Linux and what RH has done with systemd). Turns out you don't need to have to resort to dead-end proprietary software development methodologies to remain in control of the overall development direction of any given code base.

It would seem that Microsoft (like RH did years ago) has finally woken up to that reality and is now flexing its financial and research division muscle to the benefit of its own bottom line while still miraculously managing to be a good steward and citizen in the Open Source landscape, just like RH has mostly proven to be. Seems to me that Oracle completely missed the point in this regard with its DB and Java acquisitions and Alphabet is busy doing ... whatever it is Alphabet and its subsidiary Google does (to be fair, Google popularised Android, Go, Kubernetes and YouTube and is driving the adoption of Open, non-encumbered video codecs, so there's that).

This is the clash of the titans all over again and this is merely the beginning. At this rate, you would expect IBM to also begin investing strategically in Open Source bedrock technologies that developers rely on in their $DAYJOB in order to remain relevant in the evolving tech sector.

As a corollary to all this, one could easily speculate that it's only a question of time before Rust becomes an acquisition target (or is subjected to a sudden engineering resource influx from your friendly neighbourhood tech giant), given the inroads Rust is making into safety-oriented system-level programming across various code bases...

[Michael_S]

JS is necessary for client-side code, but that should never be the case for server-side code. The whole JS paradigm makes it unsuitable for server-side code - Node.js + JS probably the most environment-unfriendly(*) server-side combo you can imagine at the moment. How many instances would you use to serve github if it was based upon Node.js ? Facebook? How much power would you drain to serve your users and customers? How much would it cost you?

This is even not a good prototyping environment - because prototypes tend to find their way to production way too much often (i.e. always) and this is clearly NOT what you want.

(*) even if you think the climate change is not man-made, you have to agree that this is an avoidable waste of ressources, don't you?

In most of our industry, ease of development matters many times more than efficiency.

Github launched on Ruby on Rails, and that might be their primary code even now - and it's slower than NodeJS. Gitlab also uses Ruby on Rails. Launchpad and Sourcehut use Python, which is also slower than NodeJS.

At work my team costs the company about $100k per month in salary and benefits and the infrastructure that we run costs about $5k per month. If we rewrote everything in C - or Assembly, or C++ - we might get the infrastructure cost down to $1k per month. If we wanted that rewrite investment to pay for itself in, say, 5 years or less, then you're balancing $4k/month * 12months/year * 5 years = $240k savings against the engineering costs to switch to C. $240k savings / $100k engineering budget per month = 2.4 months, so unless we can do the rewrite in 2.4 months or less, it's not worth it. We have over half a million lines of code, we couldn't rewrite our code in any language, even the same languages we're using now, in less than three years.

I understand your frustration. I'm frustrated too. But the problem isn't the tools or the engineers. The problem is the whole market. Doing things the right way gets you nowhere.

[AH88]

In most of our industry, ease of development matters many times more than efficiency.

If what you're doing is a serious, long-term project, it's worth doing efficiently. If what you're doing is some disposable, short-term novelty, it probably doesn't matter much. Most people doing node.js projects fall into the latter category.

[Emmanuel Deloget]

In most of our industry, ease of development matters many times more than efficiency.

Github launched on Ruby on Rails, and that might be their primary code even now - and it's slower than NodeJS. Gitlab also uses Ruby on Rails. Launchpad and Sourcehut use Python, which is also slower than NodeJS.

At work my team costs the company about $100k per month in salary and benefits and the infrastructure that we run costs about $5k per month. If we rewrote everything in C - or Assembly, or C++ - we might get the infrastructure cost down to $1k per month. If we wanted that rewrite investment to pay for itself in, say, 5 years or less, then you're balancing $4k/month * 12months/year * 5 years = $240k savings against the engineering costs to switch to C. $240k savings / $100k engineering budget per month = 2.4 months, so unless we can do the rewrite in 2.4 months or less, it's not worth it. We have over half a million lines of code, we couldn't rewrite our code in any language, even the same languages we're using now, in less than three years.

I understand your frustration. I'm frustrated too. But the problem isn't the tools or the engineers. The problem is the whole market. Doing things the right way gets you nowhere.

I agree with you - economic considerations and immediate RoI are often more important to companies than intelligent architectural and engineering choices. But then, give the very nature of the JS language, you're pretty sure at the very start of the project that the technical debt is going to be huge in the future so if you have any long term plan for the product, you'd better start with a language that allow you to have a tighter control over your code. You see, not only I consider JS to be a bad choice on energy consumption ground, I also consider it to be a bad strategy in the long term (again, server-side ; I'm perfectly fine with JS on client side, given the fact that a CSS spinner is already eating up to 30% of your CPU, sometimes even more ).

RoR and python, while being slow, still have the advantage of being far more controllable languages, with better type systems and a more well-thought structure so it might make sense to use them. But as your user base grows, the limitation of the language will bite you - and if you're serious about serving hundred of throusands of users then at one time it will be cheaper to use a more efficient language than to continue to rely on these. Having more users/customers does not radically change the size of your team, but it changes the number of servers and their cost quite a bit . $5k for infrastructure cost per month is not that much, but imagine $500k. This number just means you grow your user base by a factor 100(*), which is not unprecedented for an Internet-based service. Suddenly, a rewrite that gives you a 10% decrease on the cost of your infrastructure generates $50K per month - and that becomes a viable project.

In the end, you're right: economic considerations are the most important, and planning is king. You should carefully select your server-side language considering your target audience and your expected business plan. Making a choice without considering these is a bit irresponsible.

(*) that's not really that. As your customer base grow, your infrastructure cost grows faster, especially if you own your servers and are responsible for their maintenance. But let's imagine we're in a perfect, linear world for the sake of the demonstration

[Michael_S]

If what you're doing is a serious, long-term project, it's worth doing efficiently. If what you're doing is some disposable, short-term novelty, it probably doesn't matter much. Most people doing node.js projects fall into the latter category.

Look at the state of the world - how many big, successful projects launched as C, C++, Fortran, Objective-C, Rust, or similar? They exist, but they're a tiny minority: kernels, compilers, video encoding, databases, runtimes and interpreters for other languages, graphics-intensive games.

Know any source code hosting sites written front-to-back (save for the client side, of course) in C or C++? How about CMS systems? CRM? Webmail? Social networks? RSS Feeds? Blog engines? Configuration management? Continuous integration servers? Wikis?

(Edit: how about all of the IaaS and PaaS projects?)

Do you know any projects or companies that replaced all of the shell, Perl, and Python scripts in their operating system init process with C programs?

My kids play dozens of games on their Android phones - but they're things with the graphical complexity of Angry Birds, and Candy Crush, and so forth. How many of those use the Android Native Development Kit? Probably none.

From a moral perspective, an engineering perspective, an environmental perspective all software development is "worth doing efficiently". In the world we live, nothing done efficiently outside domains with severe performance constraints survive. They're always beaten by anything - no matter how trashy - that allows more rapid development iteration.

I agree with you - economic considerations and immediate RoI are often more important to companies than intelligent architectural and engineering choices. But then, give the very nature of the JS language, you're pretty sure at the very start of the project that the technical debt is going to be huge in the future so if you have any long term plan for the product, you'd better start with a language that allow you to have a tighter control over your code. You see, not only I consider JS to be a bad choice on energy consumption ground, I also consider it to be a bad strategy in the long term (again, server-side ; I'm perfectly fine with JS on client side, given the fact that a CSS spinner is already eating up to 30% of your CPU, sometimes even more ).

RoR and python, while being slow, still have the advantage of being far more controllable languages, with better type systems and a more well-thought structure so it might make sense to use them. But as your user base grows, the limitation of the language will bite you - and if you're serious about serving hundred of throusands of users then at one time it will be cheaper to use a more efficient language than to continue to rely on these. Having more users/customers does not radically change the size of your team, but it changes the number of servers and their cost quite a bit . $5k for infrastructure cost per month is not that much, but imagine $500k. This number just means you grow your user base by a factor 100(*), which is not unprecedented for an Internet-based service. Suddenly, a rewrite that gives you a 10% decrease on the cost of your infrastructure generates $50K per month - and that becomes a viable project.

In the end, you're right: economic considerations are the most important, and planning is king. You should carefully select your server-side language considering your target audience and your expected business plan. Making a choice without considering these is a bit irresponsible.

(*) that's not really that. As your customer base grow, your infrastructure cost grows faster, especially if you own your servers and are responsible for their maintenance. But let's imagine we're in a perfect, linear world for the sake of the demonstration

If your customer base goes up 100x then it becomes practical to rewrite your project in C - and that's exactly what companies like Google and Facebook do. Youtube was originally written in Python, I imagine they've rewritten it in something else. Facebook was originally written in PHP, they have rewritten a lot of their back end code in C++, written a faster PHP runtime, and I would guess are also incrementally converting the remaining PHP to C++.

But for every project that achieves the infamous 'web scale' and gets a rewrite (or more likely, incremental transition) into something hyper-efficient, there are tens of thousands of projects that never need it.

On the particular topic of NodeJS, I would guardedly agree that from a maintainability perspective it's not as good as Python or Ruby on Rails. But I completely believe thoughtful design and engineering discipline (good practices, code review, unit and automated testing) trump specific language concerns. A great team building a product in NodeJS will make something better than a decent team building a product in Python or Ruby.

And of course Node has two other selling points, which you know: you can use the same language client and server so your 'full stack' engineers have less mental effort to translate back and forth, and there are compile-to-js options. That hurts your performance even more, but you can use almost any language you want on both sides that way.

[starshipeleven]

Because Google is usually the one wasting money on project that they know are going to fail or know beforehand that they will lose interest one day. Sure, there are MS examples of that as well, but less so than from Google.

Not really, I would say they are more or less even, Bing, the VR thing, Windows phones, Windows 8, Windows RT, Windows 10 on ARM, Windows Store, the "limitless cloud storage" for Office 365 that was drastically reduced later, myspaces, MSN messenger, Internet Explorer, Edge (as a non-Chrome reskin), Skype...

[Zeioth]

It's too bad the Node.js version that ships with Ubuntu 20.04 is old. Also the Node.js, npm and node-gyp depends on Python 2 instead of Python 3. 😢

It's too bad that GitHub doesn't officially support GitHub for Desktop on Linux.



If you don't like NPM there is Yarn, and if you don't like JavaScript there is TypeScript. But yeah, JavaScript sure have it wonks and wrinkles.

You really want to work with virtualenvs when you use node. Same as python.

[pal666]

Implementing an API with Node.js is undoubtly far more elegant, less bug prones, and far more productive than with C/C++.

for someone who doesn't know c++

Want to run code in a browser ? You have no choice than using JavaScript.

you even mention wasm below, what is preventing you from using it in browser?

[utopik]

I'm perfectly fine with JS on client side, given the fact that a CSS spinner is already eating up to 30% of your CPU, sometimes even more ).

Cpu usage can be high on Linux during animations, due to missing HW accelerations I guess. That's not inherent to css, on windows it should be HW accelerated. If that bother you that much and you are at ease with C/C++, then what prevent you from reducing energy consumption on Linux by contributing to Chromium/Firefox or any other open source browser ?

[utopik]

for someone who doesn't know c++
you even mention wasm below, what is preventing you from using it in browser?

Why would I code a web application with wasm ? Browsers are optimized to display html + css + JS so I use these languages. If I need to develop a game in the browser, sure, I might use wasm or a game engine which will compile to wasm. If I need to reuse an existing C library, sure I could compile it to wasm and call it from my web application with JS. In order to manager rendering with wasm you will have no choice than using OpenGL/WebGL. I don't see how this would lead to less energy consumption btw, and you can say goodbye to accessibility features.