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

101–110 of 216 posts

Re: Programs are dead, and JavaScript has killed them

#101

Post by hobs »

yakubin wrote: post #85
csmpltn wrote: post #69

Earlier quoted context omitted.

> "why i moved mostly from writing node cmd tools to using bash" You literally moved from one unmaintainable mess of an ecosystem (Node), to what is arguably an even worse unmaintainable mess of an ecosystem (bash). Glad to hear it wasn't Perl though. For self-contained little tools or hobby projects that can run cross-platform, use Python. For anything beyond that - use a proper strongly typed language (C, C++, C#,…

Bash scripts don’t break, when left unattended for months/years. Python scripts do.

Pin your versions. Also - to make the equivalent safe bash program compared to a typical python implementation is ... a lot of work. Enough that imo the python version is worth the maintenance.

Re: Programs are dead, and JavaScript has killed them

#102

Post by robinsonb5 »

cxr wrote: post #84
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…

It's funny. The issue described (inability to replicate the conditions to build and/or run the original program using NPM) is something that gets brought up a lot, but people will appear who are downright adamant that it's not a problem. Not just that it's not prevalent enough to be concerned about, but that they've literally never seen it happen ever. We're living in completely separate worlds. And let's be clear: t…

You're right that it's not the language per se, but I'd argue that it's not specifically NPM either - the same problems afflict any rapidly-moving not-yet-fully-mature software ecosystem. The whole tale definitely reminded me of the pain of trying to build projects in C and C++ from source in the early 2000s, with GNU Autotools everywhere, and before pkg_config was common. I've had similar "side quest" frustrations (I really like that description from the parent post!) more recently when python's involved.

But I guess NPM's particularly prone to it due to the sheer number of interdependent packages. I can't quite wrap my head around there being one npm package for every 6,100 human beings on the planet.

Re: Programs are dead, and JavaScript has killed them

#103

Post by GrabbinD33ze69 »

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…

> don't need to go on a bunch of side missions every time i run npm install

Lol what a great way to describe what running a simple "npm install" entails.

Re: Programs are dead, and JavaScript has killed them

#104

Post by dncornholio »

The solution is very simple. Lock your versions in package.json. Everyone stays happy. The only thing to keep track is, is what version of NodeJS you are using. It will happily keep working for years!

Do I get a super long list of deprecated and warning messages? Yes, they are also meaningless. You can ignore them and just build the feature.

Re: Programs are dead, and JavaScript has killed them

#105

Post by FeistySkink »

AgentME wrote: post #97
Zpalmtree wrote: post #58

Earlier quoted context omitted.

Most of these are 'gotchas' that rarely happen in real code because they're all due to implicit type conversions

Yeah, nothing there affects regular programs even a tenth as bad as say quoting rules and space handling affect average Bash shell scripts.

Wouldn't shellcheck catch most of these?

Re: Programs are dead, and JavaScript has killed them

#106

Post by cxr »

xnorswap wrote: post #66
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…

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). There are even very stable platform APIs available outside the language core, e.g. the non-experimental stuff that the WHATWG/W3C standardizes. What you're doing though is opting for an opinionated, incompatible, vendor-specific fork (NodeJS), then experiencing the ensuing pain that comes with that decision.

Maybe if you like the stability of .NET and you find yourself having to use JS, you should rally for a JS-for-.NET cause instead of tacitly feeding the ongoing JS-with-NodeJS hegemony even though it keeps hurting you.

Re: Programs are dead, and JavaScript has killed them

#107

Post by constantcrying »

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…

>JavsScript, which is a scripting language

It clearly is not. Whatever it was supposed to be, or might have been in the past JS is not a scripting language.

Re: Programs are dead, and JavaScript has killed them

#108

Post by yurishimo »

_ubs3 wrote: post #95

Pro tip: unless it's a trivial app, and if you don't dislike "difficult" languages, use Rust for the logic. It tends to be backwards compatible and interfaces nicely with Javascript with WASM, and you can share it with other frontends like native apps.

Most of the time when JS stuff breaks, it's in your core business logic. It's some frontend dependency someone included because they didn't want to write their own date picker calendar component.

Re: Programs are dead, and JavaScript has killed them

#109

Post by Gys »

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…

> I love JS

That is the problem. You love a hammer and see nails everywhere.

Re: Programs are dead, and JavaScript has killed them

#110

Post by onionisafruit »

robinsonb5 wrote: post #102
cxr wrote: post #84

Earlier quoted context omitted.

It's funny. The issue described (inability to replicate the conditions to build and/or run the original program using NPM) is something that gets brought up a lot, but people will appear who are downright adamant that it's not a problem. Not just that it's not prevalent enough to be concerned about, but that they've literally never seen it happen ever. We're living in completely separate worlds. And let's be clear: t…

You're right that it's not the language per se, but I'd argue that it's not specifically NPM either - the same problems afflict any rapidly-moving not-yet-fully-mature software ecosystem. The whole tale definitely reminded me of the pain of trying to build projects in C and C++ from source in the early 2000s, with GNU Autotools everywhere, and before pkg_config was common. I've had similar "side quest" frustrations (…

This article reminded me of my days as a sysadmin in the 90s. It seemed like every new system had a fresh issue with getting some shared library right.
Post reply on HN