This is... interesting? Based on the description, an apology is unnecessary. Users who would be affected by this are probably too busy avoiding asphyxiation by plastic bag to notice.
Because for a good chunk of the "web developer" or "web programmer" community, Node.js leverages the HTML/CSS/JS skillset they already have honed writing WordPress plugins and themes.
It's easier to get adoption of your platform when it's a syntax one-trick-pony mom and pop "website design" companies understand, because now with some tutorials they can say that they, too, can write server side code.
Forgive me for a blunt reply to your snarky comment, but this is ignorant hyperbole, and I'm surprised you got away with it on HN.
I've never written 'WordPress plugins and themes'. I've worked in C, Java, PHP, Python, Ruby. Yet I gravitate to Node for backends because it makes sense for many reasons over alternative platforms that are still playing catch-up in terms of practical solutions.
One example: Node had solid websockets solutions from close to day one. Several years later, Django just added 'channels' to its org. Rails just added 'action cable'. Both feel very immature.
Also Python and Ruby are slow as hell compared to Node.
>> Remind me again why this is killing Django and Rails for mindshare
Staying specific to package managers (which the article is about), Python's Pip doesn't have a dependency resolver [0] and Python packaging is miserable without using virtualenvs, which is frustrating overhead. Also the setup.py situation is a hot, unstandardised mess.
As far as Ruby goes, (I don't have as much experience here, but ...) Rubygems seems hella slow, and the require story sucks compared to npm. Do I have to require 'rubygems'?, should I require_relative? In my book npm has both beat for 'is fast' and 'just works'.
No. Never. Your code should not expect/require a particular dependency manager.
> should I require_relative?
This has nothing to do with package management, and the answer is again, "no, never" if you're trying to require a gem. This is to require files from within your own projects.
>> No. Never. Your code should not expect/require a particular dependency manager
But there's loads of code out there that does that. So the answer isn't clear.
> should I require_relative?
>> This has nothing to do with package management, [...]
It's to do with the interplay between what you install via package management and what you require. In Node you require a package by the same name as you install it, and there's one `require()`, end of story. In Ruby, it's less clear. That's what I meant.
If you want a further example: Why do I `gem install activesupport`, but `require 'active_support'`?
I'm not sure why publishing modules with the same name as core ones is even allowed. I get that it probably won't be possible to remove stuff like `fs`, `console`, `vm` and others, but maybe worth adding a policy for preventing this in the future.
What does that accomplish? There's an "http" package on PyPI and Py3k adds an "http" package to the standard library. This does not seem meaningful. As I suggested in my downvoted comment, if you're doing `pip install os`, or `npm install --save fs`, your problems are external to the tools you've chosen.
18 comments
[ 2.3 ms ] story [ 50.1 ms ] threadhttps://news.ycombinator.com/newsguidelines.html
It's easier to get adoption of your platform when it's a syntax one-trick-pony mom and pop "website design" companies understand, because now with some tutorials they can say that they, too, can write server side code.
I've never written 'WordPress plugins and themes'. I've worked in C, Java, PHP, Python, Ruby. Yet I gravitate to Node for backends because it makes sense for many reasons over alternative platforms that are still playing catch-up in terms of practical solutions.
One example: Node had solid websockets solutions from close to day one. Several years later, Django just added 'channels' to its org. Rails just added 'action cable'. Both feel very immature.
Also Python and Ruby are slow as hell compared to Node.
Staying specific to package managers (which the article is about), Python's Pip doesn't have a dependency resolver [0] and Python packaging is miserable without using virtualenvs, which is frustrating overhead. Also the setup.py situation is a hot, unstandardised mess.
As far as Ruby goes, (I don't have as much experience here, but ...) Rubygems seems hella slow, and the require story sucks compared to npm. Do I have to require 'rubygems'?, should I require_relative? In my book npm has both beat for 'is fast' and 'just works'.
[0] https://github.com/pypa/pip/issues/988
No. Never. Your code should not expect/require a particular dependency manager.
> should I require_relative?
This has nothing to do with package management, and the answer is again, "no, never" if you're trying to require a gem. This is to require files from within your own projects.
>> No. Never. Your code should not expect/require a particular dependency manager
But there's loads of code out there that does that. So the answer isn't clear.
> should I require_relative?
>> This has nothing to do with package management, [...]
It's to do with the interplay between what you install via package management and what you require. In Node you require a package by the same name as you install it, and there's one `require()`, end of story. In Ruby, it's less clear. That's what I meant.
If you want a further example: Why do I `gem install activesupport`, but `require 'active_support'`?
You probably won't even be able to `require` them without some fancy tricks in newer node versions: https://nodejs.org/api/modules.html#modules_all_together
The tool rejecting to do obviously wrong thing is always nice to have. No matter how trivial the mistake might seem to you.