Live data from Hacker News

Programs are dead, and JavaScript has killed them

pouria.dev

71–80 of 216 posts

Re: Programs are dead, and JavaScript has killed them

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

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'll probably be full of hideous out-of-date code and full of security vulnerabilities, but at least you won't have to look at it and feel bad.

If static binaries were good enough for Ultrix, they're good enough for you.

Re: Programs are dead, and JavaScript has killed them

#72
Too much churn is killing me.

JavaScript is really just the tip of the iceberg or maybe the perfect embodiment of modernity.

Looking at it narcissisticly, it's like some kind of divine punishment for younger me who couldn't wait for progress and innovation on basically everything.

Re: Programs are dead, and JavaScript has killed them

#73
post #61

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

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

Re: Programs are dead, and JavaScript has killed them

#74
"your new operating system"?

What does this have to do with javascript? And with javascript evolving too rapidly? Software written for one OS sometimes doesn't work on another OS, or even on a new version of that OS. At least the latter is almost universally recognized as a problem of the OS, but here justifies a rant about javascript?

Re: Programs are dead, and JavaScript has killed them

#77

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…

> The standards are backwards compatible and evergreen.

They are definitely not backwards compatible. Most of the modern web will be broken on older devices. A few of the newer standards couldn't even be properly polyfilled on some older browsers.

And some of them are definitely not evergreen. Marquee is the one that will definitely spring to mind. But then there was Custom Elements V0 that Youtube was rebuilt in and removed when Youtube was rebuilt in V1. And then there's the push by browsers to remove alert/prompt/confirm.

> Your walled garden withers.

These "walled gardens" use the platform as much as your half-baked lib/framework you inevitably end up with. Because there's nothing else to use in the browser but the platform.

And the platform sucks. It offers almost zero functionality for anything beyond a static text page with a few images on it

Re: Programs are dead, and JavaScript has killed them

#78
I don't understand the point of this article. Most Javascript "programs" (lets not glorify them) are being stripped out of prod everywhere that isn't a NodeJS shop internally (and those are being garbage collected left and right by the Covid recession).

If you build your tools with somebody else's entrenched technical debt, you are now paying somebody else's debt.

Re: Programs are dead, and JavaScript has killed them

#79
post #27
post #19

Earlier quoted context omitted.

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.

Exactly. Dependency hell is easy to avoid by avoiding dependencies. Modern JS with modules and classes is really good for simple projects, esp. prototypes that don't have to work everywhere. No framework, no special utilities that all have their quirks. And no packaging either. Much, much simpler this way.

Likewise, concurrency stops being a problem if I avoid threads and async as much as possible.

I'm starting to feel old now that I can no longer pretend I've only got two threads, network and UI, where everything is fine if I wrap the network response with "do on main thread" and crashes reliably and instantly whenever I forgot.

Re: Programs are dead, and JavaScript has killed them

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

Actually not all of them use Electron as such.

Teams is thankfully now using WebView2 (less resource heavy), new Outlook is a PWA.

However I do agree with the gist of your comment, it appears everyone from the GUI civil wars that doesn't want to stay until the end has jumped ship to "Azure OS", or the competition (Amazon/Google), and most UIs are Web based or the classical Win32 ones.

Naturally "Azure OS" applications use the Web as UI.

Only WinDev themselves seem head down on using WinUI, and still don't grasp the competition, not only the WebView2 based stuff into their turf, the other OSes that don't require dealing with COM and C++ for basic stuff like OS widgets.

Post reply on HN