Live data from Hacker News

Things I Regret About Node.js [video]

youtube.com

171–180 of 502 posts

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

#171
post #80

Earlier quoted context omitted.

How? Javascript has a lot going for it from async-everything to conveniences like destructuring. And it works in the browser and has things like Typescript. I have to find good reasons to use another dynamically-typed language over Javascript.

I would argue async-everything the biggest hassle with Javascript. Most of the time, I need things to run synchronously. Do this thing, then do that thing based on the result of the first thing. The need for async is the exception. So what we end up doing is expending extra effort forcing all the async stuff to run synchronously when that should be the default case.

With the callback methods it was really a hassle.

With async/await is so nice now.

await step1() await step2()

That's it.

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

#172
post #80

Earlier quoted context omitted.

How? Javascript has a lot going for it from async-everything to conveniences like destructuring. And it works in the browser and has things like Typescript. I have to find good reasons to use another dynamically-typed language over Javascript.

I would argue async-everything the biggest hassle with Javascript. Most of the time, I need things to run synchronously. Do this thing, then do that thing based on the result of the first thing. The need for async is the exception. So what we end up doing is expending extra effort forcing all the async stuff to run synchronously when that should be the default case.

Thank you for summarizing this so succinctly. The true use case for async in the browser is rare. Sure, you're not blocking the UI while making server calls, but how often do you need to click around while waiting for something on the server to happen?

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

#173

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…

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.

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

#174
post #157

Earlier quoted context omitted.

> Very simple mistakes like immutable, never changing build releases Can you expand a bit more? Not sure what this means.

[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

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

#175

Earlier quoted context omitted.

I've heard this argument several times now and it finally hit me what I dislike about it. If you aren't context switching between your backend code and your frontend code (even when both are JS), you're probably incurring technical debt in your architecture to be paid in even greater numbers of dev hours down the road. When you are writing an all-JS full-stack app, do you really feel like you're only working on a sin…

It's not even likely they're in the same repo when working with Node (although possible). The context switch between apps is one cost you have to pay (surely your backend will differ from frontend in architecture). However, the costs of switching languages is higher. Golang / JS conventions are very different. It is possible to share some common libs front end / back end (lodash, validation logic, etc) and that helps…

> The context switch between apps is one cost you have to pay [...]. However, the costs of switching languages is higher.

Is it? I was working with a system where server is written in Erlang and client (and another server) is written in Python. No problems with switching back and forth.

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

#176
Ryan rightly warns about adding “cute” and unnecessary features to projects. Then he goes and adds the “Load module directly from a URL” feature with all its complexity to Deno.

Ryan; kill that feature now. It’s not needed. It’s just cute.

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

#177

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…

It's always like this.

I'm lucky enough to have been around the industry for a while. I could probably count a dozen or more things that started out "Like X, only without all the BS!" --- only to end up with just as much BS or more than X ever had.

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

#178

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.

All these tools start off as simple alternatives to the existing bloated tools. Then as they gain more and more features to support real-world situations they end up becoming as bloated as the tools they set out to replace.

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

#179
post #157

Earlier quoted context omitted.

> Very simple mistakes like immutable, never changing build releases Can you expand a bit more? Not sure what this means.

[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?

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

#180
post #80

Earlier quoted context omitted.

I would argue async-everything the biggest hassle with Javascript. Most of the time, I need things to run synchronously. Do this thing, then do that thing based on the result of the first thing. The need for async is the exception. So what we end up doing is expending extra effort forcing all the async stuff to run synchronously when that should be the default case.

With the callback methods it was really a hassle. With async/await is so nice now. await step1() await step2() That's it.

I get what you're saying, and yes, async/await is much better. But the entire reason it has to exist (and be used everywhere) is because javascript's default async behavior gets in the way so often. The irony is that when I do want some sort of async behavior, I often have to reach for something like bluebird anyway because I want better control over the Promises. So either I'm circumventing JS's default behavior by using async/await, or using a library that makes promises manageable. Almost never is it preferable to me to use JS's standard plain async behavior.
Post reply on HN