Live data from Hacker News

Things I Regret About Node.js [video]

youtube.com

221–230 of 502 posts

Re: Things I Regret About Node.js [video]

#221
post #144

I think it's quite interesting to see that originally node.js was presented as a bloat-free alternative to "enterprise languages" like Java, C# or even Python or Ruby. A lot of complexity was subsequently added in an ad-hoc way which has resulted in (for example) a package management system that's wildly out of control. It's very popular of course, so I'm definitely not arguing that metric. However, the stuff that wa…

Watching the Javascript poorly reinvent the wheel has been very disappointing. Very simple mistakes like immutable, never changing build releases that Java developers understood 15 years ago are become recent front page news in this community. Ironically, even though all the code is open-source pre-existing knowledge does not get leveraged in the open source world. There's a kind of market failure at work here it see…

I like the energy around the javascript everywhere movement. So what if they reinvent the wheel, sometimes you find a better wheel and break the rules along the way.

There is something exciting about developers using a language in ways it was never designed. Then having the language change to support the changing ecosystem...

Re: Things I Regret About Node.js [video]

#222

Earlier quoted context omitted.

Why not just: require("fs").readdir(".").then(console.log)

It can potentially break things. There are legacy code that assume that calling `readdir` will yield undefined, and will have just passed that result to a function, that alters its behaviour based on whether a parameter is undefined.

Interesting. Seems like a great opportunity for a major version bump.

Re: Things I Regret About Node.js [video]

#223
post #157

Earlier quoted context omitted.

[1] https://en.wikipedia.org/wiki/Npm_(software)#Notable_breakag... , [2] https://www.csoonline.com/article/3214624/security/malicious... , [3] https://news.ycombinator.com/item?id=16087024 And the list goes on and on IMO. What's disappointing is that these were lessons learned a long time ago and now they're being re-learned.

More frustratingly, at least for me, is that some of us have been warning about these things for absolutely years without many paying any mind, only for them to keep in happening again. Eg. https://news.ycombinator.com/item?id=16090120

The problem is, how do we know that those shouting warnings are not false prophets?

Re: Things I Regret About Node.js [video]

#224
post #157

Earlier quoted context omitted.

[1] https://en.wikipedia.org/wiki/Npm_(software)#Notable_breakag... , [2] https://www.csoonline.com/article/3214624/security/malicious... , [3] https://news.ycombinator.com/item?id=16087024 And the list goes on and on IMO. What's disappointing is that these were lessons learned a long time ago and now they're being re-learned.

More frustratingly, at least for me, is that some of us have been warning about these things for absolutely years without many paying any mind, only for them to keep in happening again. Eg. https://news.ycombinator.com/item?id=16090120

I've found that some people tend to take a ton of pride in the assumption that they have to make mistakes to learn from them, but you almost always want to learn from other peoples' mistakes first. Probably overlaps quite heavily with those people who desperately want to tread on new paths.

Re: Things I Regret About Node.js [video]

#225

Earlier quoted context omitted.

I think the problem with "bloat-free" is it's a fine ideal until you try to solve any kind of reasonably complex problem, and honestly it starts to creep in even when you're solving something that isn't particularly complex. Here's a concrete example. Your classic node.js or express.js sample app is something fairly simple like a hello world, or an IM server. A more complex sample probably looks something like that v…

It's interesting that you mention gulp and webpack when those tools too are now considered too complex and set to be usurped by something like Brunch. It's a shame these tools keep being rewritten because there are definitely good ideas in all of them, but for some reason they can't seem to be unified.

> It's interesting that you mention gulp and webpack when those tools too are now considered too complex and set to be usurped by something like Brunch.

While Webpack is a little dense, it appears to strike the right balance between complexity and customizability (and probably more important for longevity, library buy-in). It doesn't seem like anything on the horizon is going to unseat it anytime soon... certainly not Brunch.

Re: Things I Regret About Node.js [video]

#226

Earlier quoted context omitted.

What the others say. And also, golang tried no centralized package management by using git repo. It didn't end with people go getting from moving masters. Of course they did. And in an area of finally accepting lock files, do you really want to go back in middle age ? Lock files are not a constraint. They are a god saver. You want lock files. You don't want to have either vague dependencies or pin pointed ones. You n…

You are imagining the worst possible execution of these ideas. Nobody is proposing that you should start using libraries that pull in code from random domains, unless you have some specific need to. Whitelisting sources is such an obvious step, given the security focus, that you should really have applied the https://en.wikipedia.org/wiki/Principle_of_charity in your speculation.

[deleted]

Re: Things I Regret About Node.js [video]

#227
post #157

Earlier quoted context omitted.

[1] https://en.wikipedia.org/wiki/Npm_(software)#Notable_breakag... , [2] https://www.csoonline.com/article/3214624/security/malicious... , [3] https://news.ycombinator.com/item?id=16087024 And the list goes on and on IMO. What's disappointing is that these were lessons learned a long time ago and now they're being re-learned.

Sounds to me like the list has one item: “the npm registry once allowed users to delete packages”. [2] and [3] have nothing to do with immutability. None of them have to do with reinventing the wheel, either, unless you wanted Node to use Maven for package management?

They don't mean immutable as in language form, but immutable packaging system is the general form where you can add but not remove packages to it so as to not break things, which is the common form among most maven/cargo/hunter/etc.../etc... dependency packaging systems. It's generally considered that npm supporting deleting packages was a major mis-design, which became very public when a popular tiny package got deleted, which then broke so many things, so they learned that the hard way instead of learning from the systems that came before (obviously not cargo, but you get the drift ^.^).

Re: Things I Regret About Node.js [video]

#228

I think it's quite interesting to see that originally node.js was presented as a bloat-free alternative to "enterprise languages" like Java, C# or even Python or Ruby. A lot of complexity was subsequently added in an ad-hoc way which has resulted in (for example) a package management system that's wildly out of control. It's very popular of course, so I'm definitely not arguing that metric. However, the stuff that wa…

I think this is a story that gets repeated lots of times in our world of open source software dev. 1. X is SO bloated and poorly engineered full of bad legacy decisions. 2. We can totally do better let's invent a new thing, Y! 3. Wow, Y is so clean and fast and understandable. 4. But it doesn't do this thing a bunch of people reasonably really need... let's add it. (repeat 3 and 4 a few hundred times) 5. Y is so bloa…

Yes, because the loop never solves the original problem. It's about organization and bloat, not pure speed and leanness.

Rebuild from scratch but also recreate all the existing functionality in a much better standard library and finally the chain can be broken. But nobody wants to do that.

Re: Things I Regret About Node.js [video]

#229
post #122

Earlier quoted context omitted.

I'm on the Dart team (but I don't speak for the entire team here). Dart had two initial goals: 1. Get a native Dart VM into Chrome and eventually other browsers. 2. Get a significant number of client-side web developers that were using JavaScript to move to Dart. It's probably not obvious, but these goals are in tension with each other. In order to motivate adding a giant new VM to a browser, you need to make the lan…

How would you characterize the positioning of Dart with respect to Go? Dart is for client-side, Go is for server-side? I'm also curious if you see having separate languages for these roles as desirable or just incidental.

> How would you characterize the positioning of Dart with respect to Go?

I think it's easy to over-estimate how much "positioning" Google actually does with projects like this. We are a very big company and different parts work fairly independently of each other.

Your description is how I think of the two languages, but you might get different answers from different people. I like classes and object-oriented programming in general, and I think it's a fantastic fit for UI applications. So I think Dart is an easier fit for that domain.

Meanwhile, Go's concurrency model and nice standard library seem to be a good fit for servers.

Given the breadth of software people write today, I think there's plenty of room in the world for lots of languages.

Re: Things I Regret About Node.js [video]

#230
post #158

Earlier quoted context omitted.

Can you share some sources? I tried to process simple CSV files in a very straight forward (but async) way and got reading 200mb CSV and just splitting it to columns (with simple split by comma) takes ~10 seconds. Also simplest HTTP request in express is handled in several ms and that's A LOT in my opinion.

I don't really have any explanatory sources at hand, just the source code here: https://github.com/potree/PotreeServer/blob/redo/src/Regions... Points of interest: Schedule files to be loaded. This will usually load around 1000 files: https://github.com/potree/PotreeServer/blob/redo/src/Regions... Whenever a file is loaded, iterate through the points in it, do the filtering and write the results to the output file: h…

The project is private.
Post reply on HN