Live data from Hacker News

Programs are dead, and JavaScript has killed them

pouria.dev

161–170 of 216 posts

Re: Programs are dead, and JavaScript has killed them

#161
post #4

I experienced the same issues and to me the main culprit appears to be the dumpster fire that is the ongoing transition to ES2015 modules. Also Node v18, while full of new, important features(like the built-in test runner) feels... kinda unstable? I had to downgrade to v16 because I had segfaults . Also had to make it use jemalloc due to memory leak issues when it used the default allocator. I went into this platform…

Just want to add that node unfortunately gives me segfaults in unexpected places too, often (seemingly randomly) during the first second of execution when I'm trying to debug it by running node under --inspect-brk...

Something is indeed off here. Even Node 0.x didn't have so many problems (granted, the debugger back then, ahem, left one wanting).

Re: Programs are dead, and JavaScript has killed them

#162
post #158

Earlier quoted context omitted.

To compare plain JS and React/stuff with C and assembly, that is a bit much. The comparison of things from so fundamentally different ecosystems is not going to yield a convincing argument. "Smart" people are actually dump, if they use an overblown framework for something as simple as a switch on a website and thereby destroy normal browser functionality, because most of them do not actually know how to use their ham…

> if they use an overblown framework for something as simple as a switch on a website and thereby destroy normal browser functionality Likely not what you meant, but FYI there is no native "switch" control in HTML - you do need to use a CSS or JS framework if you want something like iOS switch control. QED

Your definition of "QED" is quite a funny one.

I don't need a JS framework for a thing, that has 2 states, which can be realized using 2 CSS classes and toggling between them. That's maybe a 3 liner, if at all.

I am not using iOS and have no interest in it, so I have no idea what is so special about an _iOS_ switch control. Since I don't know what is that is, I also cannot really want to have it.

Fairly sure that I could probably find some easy to follow tutorial on how to make something graphically resemble a switch, if a checkbox is not sufficient for whatever reason, if I look for it ... Oh I just found a website which lists 20 of them in pure CSS on the first search query I entered: "plain css js make switch"

Re: Programs are dead, and JavaScript has killed them

#163
post #71

Earlier quoted context omitted.

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

I've been writing tools like this in Python for a very long time and haven't run into anything close to what you're describing. However, if this happened to me and I was annoyed enough to do something about it, I would use a tool (e.g. pip-compile) that creates a requirements.txt file, which specifies all the libraries and dependency version numbers explicitly. If something broke one day, you can stick that script in…

The OCI container is the binary. Docker is a tool to take any existing runtime and turn it into a static binary you can feed to any future linux(ish) kernel.

I on the other hand, have had plenty of situations where some system somewhere is managed with some config management tool (such as puppet) and it is told "make this application with these dependencies" and the application, such as "manage elasticsearch index rotation" uses the system python and does pip install to install all the things. This idiom seems fine, but ultimately ends up with a hideous mess where it worked one day and didn't work a year later, because either the system python is different or the dependencies are all messed up or the pip tool itself on the system python isn't compatible with modern package distribution.

You can (correctly) say "don't do that" but the same idiom in a shell script will almost certainly work across decades regardless of if "sh" is bash or ash or ksh, to some degree of "works" (again, you can _correctly_ say that no shell script ever works correctly).

Re: Programs are dead, and JavaScript has killed them

#164
post #39

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…

> They all have issues with versioning Not on this scale. Let's leave out the versions of the NodeJS for clarity's sake (nvm is not for managing packages, afaik), and focus on packages. You could argue that the complexity is because of JavaScript's popularity, but it's hard to deny that running a seemingly simple `npm install` will net you tons of dependencies, and that's typical regardless of what you're installing.

Python is worse. By far in my opinion.

Re: Programs are dead, and JavaScript has killed them

#166
post #106

Earlier quoted context omitted.

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). Ther…

> 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)?

Does that matter? Both for front-end or back-end you generally use NodeJS now, if you are not using an entire other language (like WebAssembly for front-end and PHP for the back-end). Even if you get rid of javascript for the front-end, you'il still have it likely to compile or minify CSS.

Re: Programs are dead, and JavaScript has killed them

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

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

I think the trick is to not have any dependencies, except Python itself, when writing such command line tools. Python does have a large standard library after all. While Python itself surely could be nicer, it is still easier to maintain such a script than a script of similar size of GNU Bash code.

Re: Programs are dead, and JavaScript has killed them

#168
post #98

Earlier quoted context omitted.

Nope, that is the UWP security container most likely. https://github.com/microsoft/calculator

Is that what causes typing "Notepad" in the search bar take 5+ seconds to show me notepad, sometimes after it showed it just having typed "No..." before deciding it's not sure whether it wants to show me something else instead?

[deleted]

Re: Programs are dead, and JavaScript has killed them

#169
post #98

Earlier quoted context omitted.

Nope, that is the UWP security container most likely. https://github.com/microsoft/calculator

Is that what causes typing "Notepad" in the search bar take 5+ seconds to show me notepad, sometimes after it showed it just having typed "No..." before deciding it's not sure whether it wants to show me something else instead?

No idea, for me search mostly works.

Re: Programs are dead, and JavaScript has killed them

#170
post #153
post #122

Earlier quoted context omitted.

Couple hundred years ago people were still thinking that Earth is in the center of the universe :) Ideas that survived is survivorship bias - everyday life just shifts around.

> Couple hundred years ago people were still thinking that Earth is in the center of the universe :) They were? Were they educated people or just some random people?

Well just read up: https://en.wikipedia.org/wiki/Nicolaus_Copernicus

Couple hundred years ago - this was up to 600 years ago - I was not saying about 100 or 200.

Post reply on HN