Live data from Hacker News

Things I Regret About Node.js [video]

youtube.com

231–240 of 502 posts

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

#231

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…

Please reconcile Dart with Haxe. Why should both exist? https://haxe.org My previous question in 2016 was "Reconcile Dart and Go", the best answer I got was: """This isn't true; they're both general purpose programming languages with strong static type systems and decent async I/O stories. You can write a web app or a server in either language, though Dart has a better ecosystem for frontend development, and Go has a…

> Why should both exist?

In general, I dislike existential questions about programming languages. No one seems to do that for other product categories. "Why should Monet and Renoir both exist?" "We already have Castlevania. Why do we need Metroid?"

I understand languages are a little different because each requires an ecosystem that is fueled by programmer attention. There is an opportunity cost that time developer X spends writing a library for language Y is time not spent writing a library for language Z.

But, overall, I try not to get too hung up on that. I find thinking of things in zero-sum terms stressful and often not very useful. There are enough programmers to support a wide variety of languages. If we're worried about not having enough total nerd capital to support all of those ecosystems, I think there are plenty of other inefficiencies we could focus one. Eliminating the 7,000+ different Node libraries for doing asynchrony would probably free up a few person-decades of effort.

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

#232

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…

> golang tried no centralized package management by using git repo. It didn't end well. What? There's no fundamental problem with it. It will continue. What do you mean?

The go team recognise there's a fundamental problem with it, otherwise they wouldn't have created dep and vgo [1]

[1] https://github.com/golang/go/issues/24301

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

#233

Earlier quoted context omitted.

Depends a great deal on what the application is, I think. If you're doing heavy lifting (or anything a bit complicated) in the client and then need to make similar functionality available to APIs offline it's a godsend. My current hobby project is a kind of REPL/programming language that does all of its compute in the client, and being able to hit a button and export a "serverless" microservice is lovely side-effect…

fiasco? isn't '.mjs' still the path forward for them?

Maybe it is for them, but `node -r esm` is what I'm going to do for now.

I'll probably start webpacking the backend soon instead, but I'm sure as hell not going to rename every single file in my codebase.

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

#234
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…

This issue is not just a lack of learning from past failures, it's an active issue that is systemic to web development, especially node. Everyone wants reinvent the wheel rather than supporting a similar, already existing project. I don't know if it's that everyone wants to be the lead on something or if they all lack group skills, but there is no reason we need dozens of similar, partially functional libraries. I can barely, and I mean sooo very barely get behind the fact that all of these SaaS companies need to create their own versions of frameworks, but it amazes me just how many square wheels there are in the web community. It was one of the major reasons it took me so long to start doing full stack development, just way too many cooks all wanting to make almost the exact same meal, only theirs is more superior.

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

#235

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 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…

This why I love Java so much. Take a look at what Spring Boot does for me:

- Routing is done in two lines of code: @Controller @RequestMapping("/myroute")

- Cookie and body parsing - no need to write any code to do that, I just have method parameters and all of the data flies in. Whant a validation? Only one keyword on a method parameter - @Valid. Custom validators are supported as well.

- Session management. It just here for me and does the right thing by default. I can replace storages with custom implementations but by default no code is required from me.

- MongoDB integration - Spring Data MongoDB and you only need to define interfaces using naming convention. The code to access the actual database is generated for you.

- Spring Security supports multiple authentication mechanisms and gives you neat DSL to configure it.

- File system access kind obvious thing.

- HTTPS and HTTP2 support provided by Spring MVC as well.

- Compressions support - it just "server.compression.enabled=true" in your config

- Logging - slf4j + logback come with Spring Boot and there plenty custom appenders available to put you logs into logstash/splunk whatever

- Referrer spam filter - not sure about that one but CSRF protection comes OOB and enabled by default.

- Multiple tightly integrated template engines to chose from. Zero configuration code as well.

- Static content comes OOB and enabled by default, just put your stuff into resources/static.

I mean yeah, modern webapp is a complicated thing! So whenever I see somebody trying to do anything "not bloated" it means that I end up writing low level code that has been written multiple times again and again.

The other day I was trying to code a simple thing in Clojure because I love Lisp. Well, it's just embarrassing. I got to simple page showing stuff from Postgres and the boilerplate/business code ratio was at about 70%. Manually configure connection pool, manually start it, manually prepare your component systems, manually mention all of the dependencies for components, manually configure template engine, manually enable static resources support in ring, manually configure and enable session support in ring. Then we come to authentication and don't even try to sell me Friend. EVERYTHING is manual. The only good thing was "environ" which did the right thing but again with "bloated" Spring Boot it comes OOB and I don't need to configure it!

If you don't use something "bloated" it only means that you're writing code yourself, again and again.

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

#236
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.

This stuff isn't relevant at all to the talk - he never talks about npm or anything to do with package managers but instead how node does imports etc. But anyways, [2] is at least a problem in many other package repositories. [1] would probably be a problem for many - given legal pressure (vendor your shit, that's the solution). [3] was a bug , not a design issue - no package management system is immune to bugs. The…

> This stuff isn't relevant at all to the talk - he never talks about npm or anything to do with package managers but instead how node does imports etc.

He does have it in his slides.

Slide titled: "Regret: package.json", last 2 points:

> Ultimately I included NPM in the Node distribution, which much made it the defacto standard.

> It's unfortunate that there is a centralized (privately controlled even) repository for modules.

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

#237
post #118

Having worked with Maven, Gradle, Ruby Gems, Pip and the non-existing Go package management I must say I actually really like the Node / NPM combo. I guess artists are their own worst critics. edit: forgot Scala's SBT, admittedly a builder using Maven repo's but still an excellent example of how bad UX in this area can get.

You'll find much harsher critics of Node/NPM in these parts! I thought Ryan did a great job of explaining his regrets without giving the impression that Node was a "mistake", is "inferior", or anything so drastic.

> You'll find much harsher critics of Node/NPM in these parts!

They're ill-informed. GPP is correct that, for example pip is fundamentally inferior to npm [1], and those that insist on throwing shade at npm on HN should be corrected. They're wrong, and insulting a sound, well maintained project, without basis.

[1] https://github.com/pypa/pip/issues/988

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

#238

Earlier quoted context omitted.

This stuff isn't relevant at all to the talk - he never talks about npm or anything to do with package managers but instead how node does imports etc. But anyways, [2] is at least a problem in many other package repositories. [1] would probably be a problem for many - given legal pressure (vendor your shit, that's the solution). [3] was a bug , not a design issue - no package management system is immune to bugs. The…

> This stuff isn't relevant at all to the talk - he never talks about npm or anything to do with package managers but instead how node does imports etc. He does have it in his slides. Slide titled: "Regret: package.json", last 2 points: > Ultimately I included NPM in the Node distribution, which much made it the defacto standard. > It's unfortunate that there is a centralized (privately controlled even) repository fo…

Yeah, I remembered the package.json bit, but that part still had nothing related to the issues/ mistakes mentioned.

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

#239

Earlier quoted context omitted.

Can you explain why you think Lisp is involved here?

Just how easy JavaScript, like lisp, makes it to pass around pure anonymous functions and make good use of closures (if you are willing to tolerate a few brackets). Promises had to ruin it by wrapping functions into stateful objects. Really the best case I found against Promises comes from, believe it or not, the pro promise chapter of a book: https://github.com/getify/You-Dont-Know-JS/blob/master/async... I really d…

I personally prefer promises over callbacks, but kudos to your compelling reasoning. Promises are indeed a beast to tame, they do make debugging very difficult among other things. I think the ecosystem evolved to just agree we should move as fast as possible to using async/await and be done with callbacks AND promises.

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

#240

Earlier quoted context omitted.

> This stuff isn't relevant at all to the talk - he never talks about npm or anything to do with package managers but instead how node does imports etc. He does have it in his slides. Slide titled: "Regret: package.json", last 2 points: > Ultimately I included NPM in the Node distribution, which much made it the defacto standard. > It's unfortunate that there is a centralized (privately controlled even) repository fo…

Yeah, I remembered the package.json bit, but that part still had nothing related to the issues/ mistakes mentioned.

Understood, sorry I wasn't trying to dispute any of your points about said issues/mistakes.

Just trying to clarify that he does actually talk about NPM and his regret about it.

Post reply on HN