Live data from Hacker News

Things I Regret About Node.js [video]

youtube.com

311–320 of 502 posts

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

#311

Earlier quoted context omitted.

I believe this is what Microsoft is trying to do with .NET Core. It's been successful so far, though they aren't at feature parity yet.

Yes, arguably the .NET Framework almost did it and is still one of the most productive frameworks available, but .NET Core has definitely improved things substantially. It's fast, well-designed, and full-featured and I expect usage to pick up greatly.

So far the package manager hell has been kept in check because they keep re-doing everything in such a way that you don't intermingle it. So when you're on MVC5 you're on MVC5, and when you're on AspNetCore, you're on that. You're not using 5 of library x and 6 of libarary Y. Likewise the startup and DI stuff has all fully rebooted twice in a few years. But nonetheless, some of that sort of package hell has already seeped in, where you're using different packages that depend on different versions of some underlying thing with breaking changes. I think the choices are either keep rebooting everything or stop making new stuff.

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

#312

Earlier quoted context omitted.

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.

Webpack and Gulp were never meant to be simpler alternatives. Gulp used streams instead of serially processing files like Grunt, which made it faster, but obviously streams working in parallel are more complex than just processing the files one by one.

Webpack pulls dependencies into one file and deduplicates them. This is obviously even more complex since now you have dependency resolution logic as well as dealing with the various module systems JavaScript has invented.

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

#313
post #294
post #264

Earlier quoted context omitted.

It’s because the average dev has less than 5 years of experience according to the StackOverlow survey, and web is the fastest growing field inside software engineering. A large majority of people you’re chiding for not learning from others, don’t even realize those other things exist.

Ignorance is curable, but requires the cooperation and desire of those who lack to achieve the cure. From my vantage the world of software development seems filled with mediocre individuals who all think of themselves as the Jon Galt of software.

On average most people are average, yes. Most above average people are average in most situations, even.

And sometimes it’s just resume building or intellectual curiosity itching.

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

#314

Earlier quoted context omitted.

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.

Here's the original post I responded to:

> > The interfaces between server- and client-side code should be well-defined and language-independent.

> They dont have to be and that is the point. If you write JS/TS front and back you can make everything much simpler with the associated benefits.

That post implies that if you're writing in the same language on the front and back ends, it not only makes writing that language easier, but also somehow makes it easier to marry the two. Since most web services operate through some sort of HTTP interface, which is language agnostic, I can only infer that that poster somehow meant code reuse.

So there's that, plus I've seen countless times before over the years where people explicitly tout code reuse as the primary benefit to using JS on the backend. I'm not buying any of it.

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

#315

Earlier quoted context omitted.

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?

Presumably by reading and understanding their arguments.

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

#316

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.

Isaac S. created NPM based on a Yahoo! internal package manager.

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

#317

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 truth is even sadder. The new generations hear the complaints of the old. They hear, I hate spring, Java is so bloated, XML hell, etc. So they think damn I don't want to touch Java with a ten foot poll.

That's when they go instead with the newer system, that didn't exist long enough to have accumulated criticism. Which is backed by enthusiasts still in the honeymoon period.

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

#318
post #311

Earlier quoted context omitted.

Yes, arguably the .NET Framework almost did it and is still one of the most productive frameworks available, but .NET Core has definitely improved things substantially. It's fast, well-designed, and full-featured and I expect usage to pick up greatly.

So far the package manager hell has been kept in check because they keep re-doing everything in such a way that you don't intermingle it. So when you're on MVC5 you're on MVC5, and when you're on AspNetCore, you're on that. You're not using 5 of library x and 6 of libarary Y. Likewise the startup and DI stuff has all fully rebooted twice in a few years. But nonetheless, some of that sort of package hell has already s…

Yes, but it's rapidly getting better with .NET Standard combining all the libraries into a single definition that can be used on any framework implementation.

MVC5 was never released though, and the changes have been rather minimal from ASP.NET Core v1 to v2 with straightforward migration guides, so it might look messier than it actually is if you were working through all the previews and release candidates instead.

Nevertheless, Microsoft has a long history of having messy v1.0 with most of the stability coming after v2.0, so you can consider the foundation pretty stable now that it's on v2.1 and more.

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

#319

Earlier quoted context omitted.

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.

Here's the original post I responded to: > > The interfaces between server- and client-side code should be well-defined and language-independent. > They dont have to be and that is the point. If you write JS/TS front and back you can make everything much simpler with the associated benefits. That post implies that if you're writing in the same language on the front and back ends, it not only makes writing that langua…

You use what you want, I'll use what I want. No sense even arguing about it. In the end, users don't give a shit what made what, as long as they get something useful from it.

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

#320

Earlier quoted context omitted.

I think Go does this for me for the most part

Go has been out for almost a decade and they’re still working on the package management story.

I’m super bullish on rust. I feel like it was designed with the right intentions.
Post reply on HN