Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I Regret About Node.js [video]

youtube.com

Post reply on HN
Print view View original

301–310 of 502 posts

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

#301

Post by ChicagoDave »

thecrazyone wrote: post #265
ChicagoDave wrote: post #152

Earlier quoted context omitted.

I'm not a huge NodeJS developer, but have done enough (and other development) to think this is not a good solution to the packaging/dependency problem. My experience with npm issues were usually that some dependency had its own build process. There are so many inconsistencies in how JS libraries are packaged and downloaded. I think scripting in general leaves the whole dependency thing out in the wind. Now. If we cou…

Well, packages are testable. You can test the api of a package today. Having people write said tests is the tough part. Did you mean to say something else?

I meant more like a binary compiled object. So many libraries have a highly varied set of folders and files. It’s just messy.

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

#302

Post by bschwindHN »

pan69 wrote: post #190

I've said it before and I say it again; NodeJS is an infrastructure component, not a general purpose application runtime environment. I totally recognise the IO problem in our connected world and NodeJS really does solve the problem around the "many simultaneously persistent connections", something that would be really hard to do without something like NodeJS. In essence (and in my humble opinion) NodeJS is basically…

> NodeJS really does solve the problem around the "many simultaneously persistent connections", something that would be really hard to do without something like NodeJS

What part of it is really hard to do without NodeJS? You can do this easily in Go, Elixir, C++, Rust, etc.

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

#303

Post by nimchimpsky »

sidlls wrote: post #296
p2t2p wrote: post #235

Earlier quoted context omitted.

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…

No, Spring Boot is one of the best examples of the worst kind of terrible patterns in the land of Java development. The bloat in that framework is awful, and the gods help you if something goes wrong in the annotations-everywhere code for anything but the most trivial of applications.

I agree, but it seems we are in a minority

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

#304

Post by tgtweak »

always_good wrote: post #204
pan69 wrote: post #190

I've said it before and I say it again; NodeJS is an infrastructure component, not a general purpose application runtime environment. I totally recognise the IO problem in our connected world and NodeJS really does solve the problem around the "many simultaneously persistent connections", something that would be really hard to do without something like NodeJS. In essence (and in my humble opinion) NodeJS is basically…

I'd say your intel is far out of date. Async-everything + async/await makes Node more elegant than the same programs in Ruby/Python. Even little things like "make these two database requests in parallel and wait on them both" or "process these urls but only have 8 requests in flight at a time."

I'm always impressed at what one thread can do with non blocking io. I think node strikes a decent balance on parallel programming without the pitfalls of threading. GO is undoubtedly better at lightweight threading, but it's not as simple to grok (or debug)

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

#305

Post by arenaninja »

One takeaway from this is how Microsoft is killing it currently:

* Much-beloved TypeScript

* Much-beloved VSCode

* Much-beloved GitHub

If they hire Ryan to flesh out his vision for deno we'd probably need a new acronym, MAFANG

On a more serious note, I wonder if deno could support a lower level construct like Observables. As much as Promises are perceived to be an improvement over callbacks, they still have major flaws (only one of which is mentioned in this talk), this is something that Observables can address

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

#306

Post by mieseratte »

BigJono wrote: post #245
jrochkind1 wrote: post #219

Earlier quoted context omitted.

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…

Not everything that gets added is stuff that people reasonably need, either. If you cater to everyone's needs, then you'll end up with 10 solutions for the same problem, because every one of your users has their preferred one. I think Javascript suffers from this quite a bit. ES6 "classes" should never have made it in, for example. Not only did they add an extra level of abstraction for beginners to learn, but the on…

> but the only reason for doing so was "my code doesn't look like it does in other languages"...

As much as I beat the FP drum these days at work, I find the class syntax a much nicer way of organizing solutions to certain, pardon the pun, classes of problems.

Whether or not you find this to be semantic diabetes is a matter of taste, I suppose. I'm curious what, specifically, you find to be the major issue that makes you say they should have been left out.

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

#307

Post by weberc2 »

jrochkind1 wrote: post #219
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…

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, but not all applications need that complexity either, so slim, simple tools are often really useful.

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

#308

Post by overcast »

LargeWu wrote: post #181
overcast wrote: post #159

Earlier quoted context omitted.

That's awesome you know lots of languages, well done. It's not necessarily about what's the best backend choice, it's about getting shit done as efficiently as possible. For the vast majority of projects, you're never going to reach any type of limitation in Node performance, that you may or may not be suggesting. I'm not sure why you're so hung up on the front impacting the back, it impacts MY workflow. I don't have…

I'm not talking about overlap in simple language features, I'm talking about actual code reuse. It's often touted as the reason to use JS on front and backend, but it's a pipe dream. It almost never works in practice. If I'm trying to get things done as efficiently as possible, I'm not using Node because the ecosystem is pretty terrible compared to other languages like Ruby and Python. Sure there are lots of librarie…

I'm not sure where it's touted code reuse is the reason to use the same language on both sides. The reason is because it's the same language, and you're not going back and forth between different ones.

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

#309

Post by overcast »

eckza wrote: post #211
overcast wrote: post #125

Earlier quoted context omitted.

You don't see how having to know only one language, is easier/faster than having to know two languages? A lot of people are doing both front and backend work. Often times it's a single person running the show. I'll tell you right now I use node for ALL my web projects, because I only have to focus on a single language. When I wear every hat managing the domain, server, databases, mail, user questions, and everything…

When the only thing you have is a hammer, everything looks like a nail. You’d be surprised at how well screwdrivers work on those funny-looking nails with the threads and the slotted heads. Snark aside: learning a second language is not really that hard, and will make you a better user of the first language in ways that you couldn’t possibly have predicted.

I know plenty of languages, it doesn't mean I want to use more than one for a single project. I don't know what the argument is here. It's not like we're discussing why some no name language is being used, Javascript is prolific to say the least. It's backed by two of the biggest companies on the planet. As much as some wish it would, it's not going anywhere.

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

#310

Post by megaman22 »

TheOtherHobbes wrote: post #62
rb808 wrote: post #46

Interesting that he's unsure about Go. Would be nice to hear about why. One huge strength about Node (&Deno) is having the same language and tools on the front end and back end. Its a huge benefit to have a team on one language, even if it might not be the optimal choice. I'm not sure if that is the problem he had with Go though.

I've never understood why this is a benefit when the one language is - let's say - suboptimal in many ways. The interfaces between server- and client-side code should be well-defined and language-independent. You don't want the same people writing both, because it's harder to check that your API is working to spec if it doesn't get fully independent testing. There's also a lot of useful server-side optimisation and s…

Too bad SOAP was such a buggy, incompatible, painful mess to use in practice.

I've liked protobufs the little that I've used them. Maybe that could be a solution, but I don't think it'll happen.

A huge portion of my pain in web development is how amorphous and ill-defined the client-server interface inevitably is.

Post reply on HN