The tragedy of running an old Node project • Hacker News Board

Re: The tragedy of running an old Node project

#371

Post by neonsunset » Wed, Nov 20, 2024, 4:24 PM UTC

cies wrote: post #347

leptons wrote: post #296

Earlier quoted context omitted.

It's okay for you to have the opinions you do, but I have zero problems programming very complex systems with Javascript, even without Typescript (before Typescript ever existed). Javascript has always been the easiest language to build anything with for me . And yes, I know a dozen other languages including C, C++, C#, Python, Go, various flavors of Assembly, and more - but Javascript is still my favorite. YMMV.

> It's okay for you to have the opinions you do Likewise. > I know [...] C, C++, C#, Python, Go, various flavors of Assembly That's good. But these are all languages that either lack strong typing and or are themselves rather quirky. Only C# and Go stand out, IMHO, as languages that are recently designed. Even Python did not have user defined classes in the first versions, and some things thus feel off (__len__, __in…

In the last few years C# did away with implicit nulls. Nullable and non-nullable object references are disambiguated with T? and T. There are multiple keywords and expressions to further make it nice to work with these. You would be correct to note that there are "nullability holes" in certain edge-case scenarios, particularly around JSON serialization. But other than that it's a pretty smooth sailing.

If you do use C#, you may also want to add nullable to .csproj too.

Re: The tragedy of running an old Node project

#372

Post by leptons » Wed, Nov 20, 2024, 5:19 PM UTC

cies wrote: post #347

leptons wrote: post #296

Earlier quoted context omitted.

It's okay for you to have the opinions you do, but I have zero problems programming very complex systems with Javascript, even without Typescript (before Typescript ever existed). Javascript has always been the easiest language to build anything with for me . And yes, I know a dozen other languages including C, C++, C#, Python, Go, various flavors of Assembly, and more - but Javascript is still my favorite. YMMV.

> It's okay for you to have the opinions you do Likewise. > I know [...] C, C++, C#, Python, Go, various flavors of Assembly That's good. But these are all languages that either lack strong typing and or are themselves rather quirky. Only C# and Go stand out, IMHO, as languages that are recently designed. Even Python did not have user defined classes in the first versions, and some things thus feel off (__len__, __in…

I prefer Assembly before any of the fringe languages you mentioned. There are no types in Assembly, and I rather like it that way. If you know how to work with data, then there's very little confusion about what you're doing.

And there's a reason practically nobody uses the languages you mentioned, and Javascript is so wildly popular. Most people don't really like or need type nagging systems. Sure, if you're trying to launch a rocket or doing something like building medical equipment or something else that requires covering your ass, then yeah, sure, go ahead and type the hell out of it. But for most programming tasks the languages you mentioned are overkill and frankly too obscure to use.

Re: The tragedy of running an old Node project

#373

Post by itsjzt » Wed, Nov 20, 2024, 5:51 PM UTC

vivzkestrel wrote: post #338

speedgoose wrote: post #39

I would heavily recommend to avoid NodeJS packages that depend on node-gyp. Node-gyp powered dependencies are very seldomly worth the hassle. If you must depend on node-gyp, perhaps use dev containers so at least every developer in your team can work most of the time.

one of the most crucial packages that use node-gyp are bcrypt and argon2. Both are needed heavily for password hashing while implementing authentication and while pure js alternatives are available, they run terribly

Use bcryptjs https://www.npmjs.com/package/bcryptjs

Re: The tragedy of running an old Node project

#374

Post by HeyLaughingBoy » Wed, Nov 20, 2024, 6:03 PM UTC

timrobinson33 wrote: post #203

jonathanlydall wrote: post #164

Earlier quoted context omitted.

C# devs can open decade+ old solutions without issues, maybe this is just "normal" for the JavaScript ecosystem, but there absolutely exist other ecosystems which don't absolutely waste your time in this way.

As it happens I've recently upgraded a 2 year old project with both node and C# It was open much the same in both. If you're happy using outdated and unsupported components with security issues AND you can get hold of the right version of the dev tools and plugins AND your hiding environment still supports the old platform, you can maintain the old version with minimal change. But should any professional developer do…

It depends.

In domains where software is expected to run for years, if not decades, it's common to archive the entire toolset, along with libraries and SDK's in case you need to fix a bug/add a feature 10 years later. Obviously, in this case you can't have dependencies sitting somewhere on a server you don't control.

There are also situations where this is forced by regulation: you need to recreate build xxx.yyy.zzz 7 years after release because a customer reported a serious bug and it needs to be reported to the relevant regulatory agency and investigated.

Re: The tragedy of running an old Node project

#375

Post by tacone » Wed, Nov 20, 2024, 7:19 PM UTC

My take is one should be especially wary of packages that depend on C libraries and need compliation. You get to be extremely bound to what the OS distribution has to offer. If that's the case, docker is probably the safest solution.

Re: The tragedy of running an old Node project

#376

Post by throwaway14356 » Wed, Nov 20, 2024, 8:21 PM UTC

leptons wrote: post #372

cies wrote: post #347

Earlier quoted context omitted.

> It's okay for you to have the opinions you do Likewise. > I know [...] C, C++, C#, Python, Go, various flavors of Assembly That's good. But these are all languages that either lack strong typing and or are themselves rather quirky. Only C# and Go stand out, IMHO, as languages that are recently designed. Even Python did not have user defined classes in the first versions, and some things thus feel off (__len__, __in…

I prefer Assembly before any of the fringe languages you mentioned. There are no types in Assembly, and I rather like it that way. If you know how to work with data, then there's very little confusion about what you're doing. And there's a reason practically nobody uses the languages you mentioned, and Javascript is so wildly popular. Most people don't really like or need type nagging systems. Sure, if you're trying…

only one type :p

Re: The tragedy of running an old Node project

#377

Post by kiru_io » Wed, Nov 20, 2024, 9:46 PM UTC

__MatrixMan__ wrote: post #210

> Two hours of my life gone, just to pick up where I left off. If I had only wasted two hours every time I had to use npm for some reason I'd be significantly ahead of where I am now.

Doesn't that apply to any it-issues you don't know how to solve?

Re: The tragedy of running an old Node project

#378

Post by plaidphantom » Wed, Nov 20, 2024, 11:42 PM UTC

ian-g wrote: post #48

lpapez wrote: post #37

Earlier quoted context omitted.

Delete this comment right now, don't give them ideas.

Too late, we already have react native

And Nativescript.

Re: The tragedy of running an old Node project

#379

Post by cies » Thu, Nov 21, 2024, 12:13 AM UTC

neonsunset wrote: post #371

cies wrote: post #347

Earlier quoted context omitted.

> It's okay for you to have the opinions you do Likewise. > I know [...] C, C++, C#, Python, Go, various flavors of Assembly That's good. But these are all languages that either lack strong typing and or are themselves rather quirky. Only C# and Go stand out, IMHO, as languages that are recently designed. Even Python did not have user defined classes in the first versions, and some things thus feel off (__len__, __in…

In the last few years C# did away with implicit nulls. Nullable and non-nullable object references are disambiguated with T? and T. There are multiple keywords and expressions to further make it nice to work with these. You would be correct to note that there are "nullability holes" in certain edge-case scenarios, particularly around JSON serialization. But other than that it's a pretty smooth sailing. If you do use…

I know it's a bit like Kotlin. I heard though that C#'s move still has some std lib bits that are nullable.

Re: The tragedy of running an old Node project

#380

Post by cies » Thu, Nov 21, 2024, 12:19 AM UTC

leptons wrote: post #372

cies wrote: post #347

Earlier quoted context omitted.

> It's okay for you to have the opinions you do Likewise. > I know [...] C, C++, C#, Python, Go, various flavors of Assembly That's good. But these are all languages that either lack strong typing and or are themselves rather quirky. Only C# and Go stand out, IMHO, as languages that are recently designed. Even Python did not have user defined classes in the first versions, and some things thus feel off (__len__, __in…

I prefer Assembly before any of the fringe languages you mentioned. There are no types in Assembly, and I rather like it that way. If you know how to work with data, then there's very little confusion about what you're doing. And there's a reason practically nobody uses the languages you mentioned, and Javascript is so wildly popular. Most people don't really like or need type nagging systems. Sure, if you're trying…

JS is popular due to it being the only browser lang. Did you forget that?

Also: TS popularity shows that not everyone in the JS community agree with you.

For server side web dev you will find that statically typed langs (Java, Kotlin, C#, Go) are a big chunk of the pie. Sure it also comes down to taste, but if you work in a large team, having stronger types can greatly help to keep the codebase in shape. (better IDE refactor tools, clearer for noob, harder to hide/ check in rubbish to git)

If you are afraid by obscurity, have a look at Kotlin!