Earlier quoted context omitted.
shameless plug If you want to avoid having to write your own args parser everytime or think getopt is a pain, you should check out my little project: https://github.com/andsens/docopt.sh No dependencies, the code is directly inlined into your script, and you write the args parser by writing the help-text.
hey='you can define variables' do_this='without commandline parsing' ./thing #!/bin/sh hey=${hey:='default one'} do_this=${do_this:='default two'} not_that=${not_that:='because getopts is a nightmare'} echo "${hey} ${do_this} ${not_that}"
Programs are dead, and JavaScript has killed them
81–90 of 216 posts
Re: Programs are dead, and JavaScript has killed them
#82This 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…
Re: Programs are dead, and JavaScript has killed them
#83> 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…
Why learn cmd and bash when you can just learn js? Easier to maintain 1 language than 1+. My software in js from 7 years ago still works.
Re: Programs are dead, and JavaScript has killed them
#84> 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…
And let's be clear: this is an *NPMJS* problem, not a *JS* problem. For folks who have read and written lots of JS before and during NPM's reign over programmers' attention and will continue to do so afterward (when NPM as the dominant culture evaporates) and have kept NPM- and NodeJS-inspired "best practices" at arms length precisely for these reasons and more, it's irksome to see people full-on equate JS with what-the-NPMers-are-doing.
Re: Programs are dead, and JavaScript has killed them
#85> 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…
> "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#,…
Re: Programs are dead, and JavaScript has killed them
#86Earlier quoted context omitted.
I left for a couple of years for Windows desktop and Android native development, turns out that the GUI civil wars at Microsoft, and the whole Java vs Kotlin vs AndroidX vs JetPack vs NDK being like a 10% project, are even worse than dealing with Web quirks. So even though I rather do native development, here we are back at the Web and distributed computing.
> the GUI civil wars at Microsoft The wars are done. Look at what Microsoft actually uses for GUIs, not what they recommend. All the new Microsoft apps are written in Electron.
Is this why the new calculator app takes over 5 seconds to show up on screen?
Re: Programs are dead, and JavaScript has killed them
#87Earlier quoted context omitted.
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.
As a counter point: I have simple node scripts, that serve the same purpose to me. And there was also the need to fix something 2 days ago in an 8 year old script. Opened the file, changed the code and running it again. Took 5 minutes and it just worked. I don't use js because it is the hot new thing, but rather because it is simple. (But I avoid messy and obscure npm repositories wherever possible for example.)
Re: Programs are dead, and JavaScript has killed them
#88I think the overlooked lesson is: the more technology you add in to your stack, the harder it is to maintain. Shallow tech stacks - using fewer tools and frameworks wherever possible - are usually a good idea to minimise your maintenance headaches. If you're making a small quick tool, vanilla JavaScript is not a bad choice. You don't have to use npm, TypeScript, and a bunch of frameworks. If you do anyway then sure,…
Re: Programs are dead, and JavaScript has killed them
#89Tools 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…
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 thinking they can do better than the last group. This plays out a few times in mature language ecosystems. Sometimes, occasionally, it’s actually true. In the JS community there have been a LOT of new attempts with “just enough” better ideas to form a sustainable community around them. But most of the time this is a wasteful idea: reskilling, reinvention, endless advocacy flame wars, etc.
But such is the tech world, we used to see this with Operating systems in the 80s and 90s before we settled down mostly on *nix.
Doing it all by yourself from base technology is fine if it’s just you and you’re the boss, but is a recipe for an unmaintainable mess that will be hell to deal with and likely thrown out once you leave whatever organization you inflicted your brilliance on.
The JS community is an example of what Happens when there is no strong central body in control of core library and framework maintainability. There are subsets that are well maintained. Use those.
Re: Programs are dead, and JavaScript has killed them
#90- do you really need to upgrade?
- try to reduce dependencies
- freeze packages to specific versions
- are you sure you need to upgrade?
- if you depend on a simple package that you can't be bothered to write yourself, consider moving it into your project
- try to get more control over how your project is built
- try not to use dependencies that have implicit dependencies on other languages (msgpack written in c++ for example)
- try to choose packages written in typescript first if you're using typescript
- make sure you have a good reason to upgrade