Live data from Hacker News

Node v8.5.0

nodejs.org

31–40 of 57 posts

Re: Node v8.5.0

#31
post #6

Earlier quoted context omitted.

I think you could find plenty of people who couldn't care less about the iPhone X (you're speaking with one of them). I took one quick look, saw nothing of major interest, and moved on with my day. Moving back to the linked story, are there any long running issues with Node that are still not yet addressed? Are nearly all common issues resolved?

Which long running issues? All common issues are quickly resolved, almost by definition, in a long-running successful project like node. Lots of people depend on that being the case. It's just not always resolved in core (which is why npm/yarn/webpack and a hundred other awesome derived works exist).

>All common issues are quickly resolved, almost by definition, in a long-running successful project like node. Lots of people depend on that being the case.

Not sure about Node, but regarding other "long running successful projects" you'd be surprised.

Re: Node v8.5.0

#32
post #30
post #15

Any updates about the Node leadership disaster news from the 10 days ago? That left a bad taste in my mouth about node.

What disaster? Just some ranting person(s) taking their marbles and going home. Let's hope the door didn't hit them on their way out. Otherwise, Node looks totally non-impacted and business as usual.

> Just some ranting person(s) taking their marbles and going home

You mean four out of the 13 CTC members leave to make a fork and the project is "totally non-impacted"?

Re: Node v8.5.0

#33
post #2

> add fs.copyFile and fs.copyFileSync which allows for more efficient copying of files. FINALLY. I don;t know how long we could have come with this still being a thing you need a module for, or you have to code yourself. Hopefully we get `fs.mkdirp` and `fs.remrf` somewhere down the line. > Add support for ESM. This is currently behind the `--experimental-modules` flag and requires the `.mjs` extension. I don't like…

Wiuldnt implementing those be trivial? They are hardly going to be "too slow" like file copy might be, and with the JS love of small packages this should already be a solved problem.

There most certainly are already packages that do this, as well as countless projects with a util.js file implementing a hodgepodge of such functions that are standards in many languages. But as a programmer I would say my biggest complaint against JS is the miserably small standard library. Thus every project has its own set of dependencies that have their own APIs. Two projects from different JS ecosystems are as different as projects in different languages altogether.

There are trade offs to be sure, but I prefer the languages (and in this case platforms) that have batteries included.

Re: Node v8.5.0

#34
post #28
post #2

> add fs.copyFile and fs.copyFileSync which allows for more efficient copying of files. FINALLY. I don;t know how long we could have come with this still being a thing you need a module for, or you have to code yourself. Hopefully we get `fs.mkdirp` and `fs.remrf` somewhere down the line. > Add support for ESM. This is currently behind the `--experimental-modules` flag and requires the `.mjs` extension. I don't like…

> I don't like the `.mjs` extension, but I understand the need for it, and I'm just glad that modules are finally here. I read that a lot. Why do people don't like the new extensions? Seems like the most elegant and programmatically more performant and less hassle free, solution to the issue. Everything else looks like a terrible kludge.

> I read that a lot. Why do people don't like the new extensions?

Probably because you'll end up with .mts, .mjsx, .mts, .mtsx.

Re: Node v8.5.0

#35
post #20

Earlier quoted context omitted.

tl;dr > On Tuesday, the thirteen-member steering committee came together to vote on whether to remove Rod Vagg, a TSC member and Node.js contributor, over his controversial statements on Twitter and GitHub that prompted complaints. They also voted on whether to ask Vagg to resign.

I am always curious about what the statement was. When it comes to SJWs they usually do not want to display that because it is often such silly things.

IDK what they were but I find it irritating that having unpopular ideas can get you in trouble like this. His views are probably opposite of my ones, but still, I cant stand the hypocrisy in these situations and how easily these supposedly smart people are successfully pushed to go witch-hunting.

Re: Node v8.5.0

#36
post #30

Earlier quoted context omitted.

What disaster? Just some ranting person(s) taking their marbles and going home. Let's hope the door didn't hit them on their way out. Otherwise, Node looks totally non-impacted and business as usual.

> Just some ranting person(s) taking their marbles and going home You mean four out of the 13 CTC members leave to make a fork and the project is "totally non-impacted"?

It's probably even better without those members on board.

This is from the Ayo "GitHub":

"For the time being, simply by mirroring them to preserve drop-in-ability. Eventually, I have no interest in retaining compatibility with Node Core at all, because that would involve participating in and interacting with a community with deeply dysfunctional governance."

Yeah, good luck with that.

Re: Node v8.5.0

#37
post #34
post #28

Earlier quoted context omitted.

> I don't like the `.mjs` extension, but I understand the need for it, and I'm just glad that modules are finally here. I read that a lot. Why do people don't like the new extensions? Seems like the most elegant and programmatically more performant and less hassle free, solution to the issue. Everything else looks like a terrible kludge.

> I read that a lot. Why do people don't like the new extensions? Probably because you'll end up with .mts, .mjsx, .mts, .mtsx.

So? If they are different types, it makes sense to have different extensions (e.g. if mts implies typescript module).

Re: Node v8.5.0

#38
post #25

Earlier quoted context omitted.

More a controversy than a disaster. The last commits [0] are only about governance model, discord link... There are some rebase but that's it. Nothing will probably come from this fork. [0] https://github.com/ayojs/ayo/commits/master

I find it ironical that people who take up pitch forks and accuse others of being a hazard to the health and growth of a project would, in lieu of having their demands met, do one of the worst actions possible against what they were "protecting": splitting the code base and the community with a fork.

How is forking the codebase "the worst possible thing"?

The open source landscape is filled with forks of projects that diverged for a variety of reasons.

A fork means the people involved are still contributing code and it can potentially be merged upstream.

The alternative is they don't fork, and contribute nothing because they're unhappy with the original project.

Re: Node v8.5.0

#39

Earlier quoted context omitted.

Wiuldnt implementing those be trivial? They are hardly going to be "too slow" like file copy might be, and with the JS love of small packages this should already be a solved problem.

There most certainly are already packages that do this, as well as countless projects with a util.js file implementing a hodgepodge of such functions that are standards in many languages. But as a programmer I would say my biggest complaint against JS is the miserably small standard library. Thus every project has its own set of dependencies that have their own APIs. Two projects from different JS ecosystems are as d…

> Thus every project has its own set of dependencies that have their own APIs.

Yes, this means that if your project depends on ten other projects, and all ten projects implement their own copy-file routine, your project will end up with ten copy-file routines.

Re: Node v8.5.0

#40
post #2

> add fs.copyFile and fs.copyFileSync which allows for more efficient copying of files. FINALLY. I don;t know how long we could have come with this still being a thing you need a module for, or you have to code yourself. Hopefully we get `fs.mkdirp` and `fs.remrf` somewhere down the line. > Add support for ESM. This is currently behind the `--experimental-modules` flag and requires the `.mjs` extension. I don't like…

Wiuldnt implementing those be trivial? They are hardly going to be "too slow" like file copy might be, and with the JS love of small packages this should already be a solved problem.

As Larry Wall said, "Easy things should be easy."

When working on a project and you need to copy something for the first time, you shouldn't have to do:

  * Ok I need to copy...  What npm package does that again?
  * search NPM for copy
  * figure out which package is "best"
  * npm i some-copy-package
  * require("some-copy-packge")
  * do thing
The first 4 steps should be unnecessary.
Post reply on HN