Live data from Hacker News

Programs are dead, and JavaScript has killed them

pouria.dev

81–90 of 216 posts

Re: Programs are dead, and JavaScript has killed them

#81
post #73
post #61

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}"

I’ve been bashing for decades and never thought of that. Thank you

Re: Programs are dead, and JavaScript has killed them

#82
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…

Even if you write something yourself, it might not work on a future version of your OS.

Re: Programs are dead, and JavaScript has killed them

#83
post #19

> 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.

because js should never be the first choice in any case...

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…

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: 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
post #69

> 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#,…

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

Re: Programs are dead, and JavaScript has killed them

#86
post #70
post #33

Earlier 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.

> 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

#87
post #12

Earlier 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.)

People always underestimate how stable JS is. I would argue that it is more stable and backward compatible than a lot of backend languages. What is not stable in JS - is a whole ecosystem.

Re: Programs are dead, and JavaScript has killed them

#88

I 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,…

I agree with this view. Any large, complicated project with a large number of dependencies is going to require maintenance over time, regardless of the language or package ecosystem. Keep your simple projects simple, and if you need to use dependencies to get something off the ground quickly, either be prepared to maintain it or to do some additional work to remove the need for those dependencies over time.

Re: Programs are dead, and JavaScript has killed them

#89

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 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
some ways to combat this:

- 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

Post reply on HN