181–190 of 216 posts
I may complain about Swift/iOS/macOS breaking things every year but they seem like bedrock compared to many JavaScript environments and frameworks. Come to think of it, even many Java apps seem to be built on a quicksand morass of constantly changing frameworks.
But I think you can have fairly stable JavaScript if you write primarily vanilla JS and don't rely on the latest bleeding-edge features in Chrome, etc..
Earlier quoted context omitted.
Bash scripts don’t break, when left unattended for months/years. Python scripts do.
The recent deprecation warning message of `egrep` is a prime example that bash scripts can break (depending on stderr processing). They will definitely break once the alias is removed.
I'm not sure what you mean by "recent", but this is more longevity than we get in the node/JS world.
I'm primarily a JS (now TS) dev, who also throws bash at things when it makes more sense, but let's not kid ourselves that it's the same.
> 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.
Earlier quoted context omitted.
If some app is not updating - there is not much use for it. That depends entirely on the program. My CD ripper/burner is going on twenty years old and it works flawlessly. Same with my audio recorder and the sensor viewer for my phone. On the occasion I need to make a slideshow or write a document, Office 2007 works just fine with no bullshit, granted I don't view third-party files in it. ES File Explorer Pro is stil…
>ES File Explorer Pro is still by far the best Android file manager despite not being updated in three and a half years. Is there something special about it? I'd typically recommend either Ghost Commander or Simple File Manager from f-droid to someone.
> 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.
There is a solution though - use of nvm and .nvmrc (to control the version of node and npm that you use), and use of npm ci (which installs packages as they were at the time, rather than installing newer versions than specified in package-lock.json (because too many devs rarely ever pin versions) instead of npm install / npm i).
nvm (Node Version manager): https://github.com/nvm-sh/nvm npm ci: https://docs.npmjs.com/cli/v6/commands/npm-ci
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…
And you write that some publicly available third-party libraries written for use with .NET change less often and/or do not introduce incompatibilities and breaking changes (as often).
Two true statements, which are totally and entirely unrelated to the JavaScript and .net.
> Bringing in libraries shouldn't mean burdening yourself with so much future incompatibility.
I agree, but it does, and the more active the library, the worse.. If you don't believe me, try writing absolutely cutting edge stuff in C, using whatever the most active and hip libraries you can find..
You'll have better success, not because C is a better language (though, I very much like it), but because stuff moves at a slower pace, even the hip C stuff is not _that_ hip, when you look at the amount of code contributed per unit of time, or the amount of new features implemented per release.
Of course I'm being general, you can certainly find JS libraries that are extremely solid, and you can certainly find C libraries that are very fragile, but in general.. they correlate well to the popularity/activity of the language.. but not with any inherent property of the actual language.
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.
Earlier quoted context omitted.
>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…
There's nothing wrong with making a language part of your identity but Darren is not even doing that, he simply said he loves JS. I don't identify as a Python dev and I don't even work with Python much lately, I know package management isn't great and PyPI registry suffered malicious attacks recently, but I can still say I love Python, I started with it and the syntax is enjoyable. But you are clearly making language…
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 can come back to a go module I write today months later and do a build. `go.mod` specifies exactly what version of what dependency I used, and `go.sum` provides the checksums. Even if the original repo was shut down, there is a good chance the `GOPROXY` I use has it cached, and failing that, if I am really worried about long time availability of dependencies I can always do a `go mod vendor` and check everything in…
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…
Of course it's a JS problem. "Programs" being replaced by JavaScript apps doesn't mean some custom homegrown LTS framework. It means apps that aim to replace what used to be known as "Programs" have some sort of frontend JS component. frontend JS doesn't mean npm.js sure, but it means whatever flavour of bower is hot today, webpack or the other new kids on the block, react or other stuff. There is a reason why these…
I've already explained why it isn't, in detail.