Things I Regret About Node.js [video] • Hacker News Board

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

#141

Post by jessaustin » Wed, Jun 06, 2018, 8:29 PM UTC

k__ wrote: post #113

azylman wrote: post #95

It's interesting to hear him say that npm and node_modules are regrets since lots of complaints about Go packaging from people new to Go ask for something similar...

I think the package system consists of many parts. Some parts of npm are much better than with most package systems, some really suck. Maybe if npm weren't included so deeply into Node, it would make something like Yarn emerge sooner and replace npm without much hassle.

yarn just seems like a set of incremental improvements over npm? Which is great, we're all for improvements. However, the vehement complaints I've seen about npm [0] make it seem that nothing short of a complete re-architecture could be tolerated. yarn does not seem to be that.

I don't agree with those complaints, but I do agree with you that "some parts" are really good. node really figured out the right search strategy for an unscoped import. (e.g. "require 'foo';" rather than "require './bar/foo';") Just look for a directory with the name "node_modules". If you don't find it, go up one directory and try again. So simple! So predictable! So complete! It works so well, all manner of "left-pad" abominations can be supported. Any other system should think very carefully before using a different import search strategy.

[0] with the exception of those related to path depth: I think those are resolved now? I wouldn't know because I stay on an OS that doesn't go out of its way to frustrate me.

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

#142

Post by repsilat » Wed, Jun 06, 2018, 8:31 PM UTC

lloeki wrote: post #92

mrighele wrote: post #82

Earlier quoted context omitted.

Having the same language allows to share some code between frontend and backend. This can be used to prerender your SPA on the server, for example, or to share some logic with the client to enable offline usage.

Being able to share code is really not that great because you don't share that much code between front and back in reality. Being able to share the paradigms , structure , mindset and tooling (like linters, formatters, code generators, packagers, whatever..) is what's awesome. You remove a whole lot of context switches and cognitive dissonance, smoothing the train of thought which greatly eases the expression of idea…

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 of being able to run JS on the server. It isn't exactly "the backend" to my application, more "a headless client exposed to the net," though, I guess.

(As someone new to JS, the frigging Node ".mjs" fiasco almost derailed the whole thing, though... What were they thinking?)

Edit: oh, and "optimistic rendering" is also a big win -- if you can show the result of an action before it has persisted (or preview it before the user has done it) shared code can also come in handy. Though perhaps we're too scared of network round-trip times.

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

#143

Post by jessaustin » Wed, Jun 06, 2018, 8:31 PM UTC

abiox wrote: post #39

emehrkay wrote: post #10

Interesting that he had promises in node that early. Maybe if he kept them, the community wouldn’t had standardized on two space indents Edit: so two space indents weren’t a consequence of “callback hell” ?

i could see nested callbacks favoring two spaces, but overall it's not a style unique to javascript. for example, a lot of ruby i've seen (admittedly it's been a while) used two spaces, and i don't recall it being any more prone to deeply nested code than other languages. that said js code tends to be rendered in a variety of other places like browser dev tools, which may influence this as well.

After getting used to 2 spaces in js I try to use them everywhere now. Except python, which obviously must be 4 spaces...

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

#144

Post by dnomad » Wed, Jun 06, 2018, 8:31 PM UTC

royjacobs wrote: post #121

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 seems; the lack of commercial selective pressure results in the flourishing of lots of poorly researched OS solutions.

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

#145

Post by vanderZwan » Wed, Jun 06, 2018, 8:31 PM UTC

thosakwe wrote: post #21

This was one of the more interesting software talks I've listened to recently. I like that it was very real - there are serious, serious problems with Node.js, and the fact that even the creator acknowledges these problems caught my attention. I'm also a long-time user of Dart, so when he brought that up, and compared TypeScript to its shortcomings, I definitely agreed. That being said, even with the Deno project, I'…

> the fact that even the creator acknowledges these problems caught my attention.

Not to take anything away from Ryan Dahl's ability to reflect and be open about what he considers his design mistakes, but it probably also helps a bit that he walked away for quite a while before coming back. A bit of distance helps in these matters.

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

#146

Post by ricardobeat » Wed, Jun 06, 2018, 8:33 PM UTC

jonny_eh wrote: post #129

Joeri wrote: post #67

Earlier quoted context omitted.

Actually, I can’t think of a single issue that npm doesn’t also have. Possible issues: - trust Not an issue since if you trust an author’s packages on npmjs you should also trust them from unpkg, github, etc... (Aka there is no trust in npm land except trust in the author) - Versioning Put the version in the url instead of some json, same difference. - Lack of ^ for automatic upgrades That’s a feature. Avoids the nee…

Dependencies, especially for dynamic imports?

Going from what he said about packaging, every program/module is compiled into a single file, including dependencies.

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

#147

Post by innocentoldguy » Wed, Jun 06, 2018, 8:34 PM UTC

tnolet wrote: 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.

I've worked with Maven, Ruby's gems, Python's pip, whatever Go's non-existent package management is called, and Node, via npm and yarn. I'd have to say my favorite tooling and package management is found in Elixir's mix utility though. I don't mind the others. They are all decent enough, but I think the Elixir team really nailed it with mix.

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

#148

Post by bronson » Wed, Jun 06, 2018, 8:36 PM UTC

dgreensp wrote: post #117

iamleppert wrote: post #78

He talks about not to add in features you think would be “cute” because they are always a mistake.. Then a few minutes later says “I thought being able to specify URLs in import statements would be cute..” Uhh...Houston, we have a problem with this one.

Haha! Ryan may not have been the best person to design a novel package manager, and while he has some insight into his mistakes the first time around, he still may not be. Neither am I; call me if you need a compiler or a GUI. Everybody has a different set of areas where they have gone deep and developed good instincts.

Yehuda! Calling Yehuda!

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

#149

Post by minitech » Wed, Jun 06, 2018, 8:38 PM UTC

dnomad wrote: post #144

royjacobs wrote: post #121

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…

> Very simple mistakes like immutable, never changing build releases

Can you expand a bit more? Not sure what this means.

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

#150

Post by LargeWu » Wed, Jun 06, 2018, 8:38 PM UTC

overcast wrote: post #139

LargeWu wrote: post #77

Earlier quoted context omitted.

But in what specific way way does it make it simpler? What are the tangible benefits? I've been working in a Node/React environment for the last 2 years and there is virtually no overlap between the code we use on front- vs backend projects.

Because not everyone is using React type frameworks on the frontend? There is old fashioned javascript still, and because I know it on the front end, I know it on the backend.

But I know lots of languages, and just because I'm using JS on the frontend doesn't mean that's the best backend choice.

Whether I'm using React or Angular or Ember or Vue or jquery or vanilla JS on the frontend doesn't have any impact on the code I'm writing on the backend. Because one is concerned primarily with handling UI, and one is primarily for data access. There's just naturally not a lot of overlap between those.