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

Programs are dead, and JavaScript has killed them

pouria.dev

Post reply on HN
Print view View original

111–120 of 216 posts

Re: Programs are dead, and JavaScript has killed them

#111

Post by zelphirkalt »

dusted wrote: post #42

This is an article about ecosystems and package managers, not particularly about JavsScript, which is a scripting language around which one can chose to participate in ecosystems and use package managers. The distinction is not as subtle as one would think. It's the same with any program.. dependencies are future liabilities. You pay for fast development now with a future burden of upgrading and incompatibility. That…

Dependencies being future liabilities is one reason why core programming skills are so important. A team with weak core programming skills will quickly make a mess of dependencies, because they will not dare to implement that left pad or that tree recursion themselves. The mess will work, but the cost will be inflicted for as long as the dependencies are in there.

Of course there are some things which getting into is not so recommended, because of high initial time cost. Like writing your own web framework. Or correctly implementing data structures or difficult to understand mathematical algorithms, or cryptography stuff.

Re: Programs are dead, and JavaScript has killed them

#112

Post by gonzo41 »

parasubvert wrote: post #96
cduzz wrote: post #71

Earlier quoted context omitted.

Only use python if you plan on compiling it with something like docker or podman to pickle your resulting stew in epoxy for all time. Otherwise you'll still be in some dependency heck as you run down why your library updated doesn't work (oh, switched to TLS encryption; that's good I guess) or you're thing uses v2 and everything now uses v3. golang, rust, at least, make a static binary out of the gate. In 8 years it'…

It is interesting that the data science and ML folks are willing to weather Python’s dependency mess Vs. the huge momentum Golang and (increasingly) Rust have built around their static binary philosophy. Perhaps this is the future of Kubernetes , to be the only thing brave enough to run epoxied globs of .NET, Java and Python.

Python and docker, with compose is a really good fit. Everything works, everything is boring, everything is stable all the time. And importantly, most problems are easily googled.

Re: Programs are dead, and JavaScript has killed them

#113

Post by nazgulsenpai »

Gibbon1 wrote: post #12
5350-uiop-1130 wrote: post #3

> During the past 5–6 years of my JavaScript experience, every time I wanted to go back to any of my projects—from tiny to big, server-side or front-end—there was always a challenge, a problem to tackle or an obstacle to overcome before I can update or sometimes even just run my program. why i moved mostly from writing node cmd tools to using bash. don't need to go on a bunch of side missions every time i run npm ins…

A month ago I found a bug in command line utility I wrote in C# and hadn't touched in 8 years. I checked out the project and opened it in Visual Studio. And it compiled. I fixed the bug and it just worked. End to end it took half an hour. I feel like there is an advantage to libraries and tools managed by adults with long term skin in the game.

You can also patch most classic .NET (4.8 and below) "binaries" in place with something like dnSpy. One example: I had to update a simple command line tool someone else wrote to poll an API that had undergone some changes. Was able to make the changes directly in dnSpy without having to even open Visual Studio. I haven't tried with any of the 5.0+ versions so I don't know if this is still the case.

Re: Programs are dead, and JavaScript has killed them

#114

Post by cduzz »

gonzo41 wrote: post #112
parasubvert wrote: post #96

Earlier quoted context omitted.

It is interesting that the data science and ML folks are willing to weather Python’s dependency mess Vs. the huge momentum Golang and (increasingly) Rust have built around their static binary philosophy. Perhaps this is the future of Kubernetes , to be the only thing brave enough to run epoxied globs of .NET, Java and Python.

Python and docker, with compose is a really good fit. Everything works, everything is boring, everything is stable all the time. And importantly, most problems are easily googled.

Just be sure to archive your artifacts. Both the ones you make and the ones you use to build output artifact.

Otherwise, your docker build tool will work today and be a screaming mess of broken dependencies tomorrow.

Re: Programs are dead, and JavaScript has killed them

#115

Post by Al-Khwarizmi »

Gibbon1 wrote: post #12
5350-uiop-1130 wrote: post #3

> During the past 5–6 years of my JavaScript experience, every time I wanted to go back to any of my projects—from tiny to big, server-side or front-end—there was always a challenge, a problem to tackle or an obstacle to overcome before I can update or sometimes even just run my program. why i moved mostly from writing node cmd tools to using bash. don't need to go on a bunch of side missions every time i run npm ins…

A month ago I found a bug in command line utility I wrote in C# and hadn't touched in 8 years. I checked out the project and opened it in Visual Studio. And it compiled. I fixed the bug and it just worked. End to end it took half an hour. I feel like there is an advantage to libraries and tools managed by adults with long term skin in the game.

I've been laughed at for scripting in Java, but I have a bunch of such scripts from 15-20 years ago and guess what, they work out of the box like the first day.

Re: Programs are dead, and JavaScript has killed them

#116

Post by xnorswap »

cxr wrote: post #106
xnorswap wrote: post #66

Earlier quoted context omitted.

But there's something very different in the JS ecosystem that makes things worse. In the .net world, even with packages managed with Nuget, it doesn't have the same "constantly breaking" problem. For example being "stuck" on an old version of react, because dependency X version 6.x requires react So you're faced with either being stuck on an old react, or re-writing half your application around the new version of you…

Don't you find it odd that you're willing to distinguish .NET as a concept from e.g. a language like C#, but when it comes to what is, in reality, the NodeJS ecosystem that you have an issue with, you pin it broadly on what you call "javascript" (also a language)? > There's no such thing as "LTS" in javascript. In fact, there is. The language is stable—it's at least as backwards compatible as C# (if not moreso). Ther…

I refer to .net as the language a lot of the time too, they are tied even more strongly together, as described in https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... . I'm probably just not being precise about the language.

I'm happy to pin this on NodeJS but Node is the key reason why javascript is used for any non-web work at all and it's almost impossible to separate that.

The javascript ecosystem and it's breakage is down to Node, but the javascript ecosystem is node. Even if you only do web work now you still need node for the build toolchain, it's essentially impossible to escape it.

You can't realistically develop without it, even projects like react have given up on trying say anything but "just use create-react-app".

Re: Programs are dead, and JavaScript has killed them

#117

Post by cxr »

krapp wrote: post #68
royletron wrote: post #32

Meh, I feel a little like this is dunking on Javascript for the sake of dunking on Javascript. Ever done the same with a PHP app? Go? Python?! They all have issues with versioning and this is why there are a good set of tools to deal with it - pyenv/nvm etc. It's like they've listed all the good reasons to use JS and then kicked it because it's cool to hate on JS. Hi, I am Darren, and I love JS - I will no longer be…

>Hi, I am Darren, and I love JS - I will no longer be ashamed by it. Don't make a programming language part of your identity. It's pathetic. No one is "dunking on Javascript for the sake of dunking on Javascript." PHP, Go and other languages don't have these issues, or at best don't have them at the same frequency, nor are they as catastrophic when they occur. No PHP dev ever woke up to discover the entire universe w…

> No PHP dev ever woke up to discover the entire universe was broken because some rando who owned the function that left-aligned text in terminals deleted their repo in a fit of pique.

You act as if this is something that was forced upon you.

Giving some "rando" the power to "own" a function in your app is a power that you choose to give them. If you don't want that then don't do it.

Sentences like "Other languages vendor dependencies by default" are nonsense statements. Stop saying "language" when you mean "the kind of people I do/don't have a problem with".

> This isn't a JS issue, it's an ecosystem and culture issue.

Right, and when people tacitly insist otherwise—by being sloppy with their words and thoughts—then it makes it harder for people to recognize the problem, see what specifically needs to be fixed, and then proceed with the "okay, let's fix it now" part.

Re: Programs are dead, and JavaScript has killed them

#118

Post by qazxcvbnm »

Tade0 wrote: post #4

I experienced the same issues and to me the main culprit appears to be the dumpster fire that is the ongoing transition to ES2015 modules. Also Node v18, while full of new, important features(like the built-in test runner) feels... kinda unstable? I had to downgrade to v16 because I had segfaults . Also had to make it use jemalloc due to memory leak issues when it used the default allocator. I went into this platform…

Just want to add that node unfortunately gives me segfaults in unexpected places too, often (seemingly randomly) during the first second of execution when I'm trying to debug it by running node under --inspect-brk...

Re: Programs are dead, and JavaScript has killed them

#119

Post by skitter »

Gibbon1 wrote: post #12
5350-uiop-1130 wrote: post #3

> During the past 5–6 years of my JavaScript experience, every time I wanted to go back to any of my projects—from tiny to big, server-side or front-end—there was always a challenge, a problem to tackle or an obstacle to overcome before I can update or sometimes even just run my program. why i moved mostly from writing node cmd tools to using bash. don't need to go on a bunch of side missions every time i run npm ins…

A month ago I found a bug in command line utility I wrote in C# and hadn't touched in 8 years. I checked out the project and opened it in Visual Studio. And it compiled. I fixed the bug and it just worked. End to end it took half an hour. I feel like there is an advantage to libraries and tools managed by adults with long term skin in the game.

That's how it should work. But of course last week I revisited a project I wrote in C# too, this only 3 years old, and apart from dotnet complaining about the target framework not being supported any more, I couldn't get it working again due to the libraries used.

Re: Programs are dead, and JavaScript has killed them

#120

Post by zelphirkalt »

parasubvert wrote: post #89
enjikaka wrote: post #53

Tools like Babel emerged to bridge a compatibility gap between the evolving ECMAScript specification and the browser lacking behind implementing the new features. Then some "smart" people decided Babel would be a good thing to transform anything and thus React, JSX and the like were born. The problem emerged and took foot when we stopped polyfilling and transpiling the compability gap and instead built further on the…

This is terrible advice, on the order of “learn assembly, not C”, or “real geeks compile their kernels with customizations”. It’s a tale as old as time: the “smart” people are actually dumb, I am the smart one, and so I will build my own framework from the ground up of JS, HTML, CSS as part of my work. And maybe eventually I’ll release it to the world. This is why the JS community is the way it is - lots of folks thi…

To compare plain JS and React/stuff with C and assembly, that is a bit much. The comparison of things from so fundamentally different ecosystems is not going to yield a convincing argument.

"Smart" people are actually dump, if they use an overblown framework for something as simple as a switch on a website and thereby destroy normal browser functionality, because most of them do not actually know how to use their hammer.

So once one has carefully considered not using a full blown megabytes sized framework and simply writing a few lines of JS instead, coupled with standard conform CSS and has actually thought about what parts of a website really need to be interactive, then one can still decide point-wise / component-wise, where to use a framework.

The problem in the JS community is a huge load of people, who present their specific solution as a general solution and others who trust them and add dependencies to their project. Putting something like left pad as a package shows what I am talking about. There is no need to have such a simple thing be a package and no harm in writing a single simple function, when one needs it. But in JS ecosystem there are also loads of devs who just started out developing and they are happy to choose dependency after dependency, because it means they can have it now, without having to code it up themselves, even if it should be a simple exercise. That does not lead to being very smart. Smart is, when I can avoid dependencies, due to intelligently coding simple things myself in generally reusable ways, so that it does not impact future development. But with most of the JS ecosystem mentality, people never get there.

Post reply on HN