Live data from Hacker News

Programs are dead, and JavaScript has killed them

pouria.dev

141–150 of 216 posts

Re: Programs are dead, and JavaScript has killed them

#141
post #35

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…

most python modules do not have so many dependencies, and tend to have a stable api. Bugs happen but it's by no means a constant thing.

Python has a completely different issue and that is that its dependencies on c extensions makes cross platform or cross version packaging a terrible thing.

This is why I get a bit puzzled when people complain about the Java build system. It's so much saner in comparison to the scripting languages, and arguably better than Go or Rust (though I'll take any of the three over Python or JS).

Re: Programs are dead, and JavaScript has killed them

#142
post #68

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…

>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 hate part of your identity.

(BTW I'd actually thank JS for TS, if they added types natively they'd probably be limited like Python's and we'd be stuck with it, but they didn't so now we have a new language with a great type system that evolved beyond JS with variations that compile into WASM and such.)

Re: Programs are dead, and JavaScript has killed them

#143
post #132

Earlier quoted context omitted.

> I'm not sure what "your own version control system" means. Me neither. Where did that come from? I didn't write it. (It's not in my comment, just yours.)

Ah apparently my brain inserted `own`, looking back you said "just using your version control system". OK, I think I'd write the rest of my comment the same still; does it mean putting all your dependencies (source/binary) in your version control (eg) git?

Yes—using your VCS/SCM to version control the source code.

Re: Programs are dead, and JavaScript has killed them

#144
post #130

Earlier quoted context omitted.

> the javascript ecosystem is node It's not. NodeJS is NodeJS. JavaScript is JavaScript. The James Webb Space Telescope isn't running Node LTS or pulling in left-pad. If you want to make a lateral move and draw comparisons elsewhere: the Java ecosystem is not Sun/Oracle's mobile platform—which never took off, while Android thrives. Languages are absolutely separable from the big loud noisemaker (and the problems they…

But when I say "javascript ecosystem", I'm talking about Node, and that's clear from my writing. I don't care for pedantry about what it might also refer to, I'm talking about NodeJS, npm and the problems with it, and that's clear because that's also what the original article is talking about.

> when I say "javascript ecosystem", I'm talking about Node

Can you change your habits?

> I'm talking about NodeJS, npm and the problems with it

So how about just saying that?

> and that's clear

It's not. A person doesn't have to go all in on Sapir–Whorf to recognize that this is fraught with peril.

The original article that you fall back on for support doesn't even agree with you; the argument that the author makes (explicitly, even) is that this actually is a JS-and-not-just-NodeJS problem.

Nor do your earlier remarks agree; you're ignoring now the pushback on your earlier remarks that escape is essentially/almost "impossible". Feels like you're going for a motte-and-bailey here (a type of bait-and-switch argument; see https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy>).

Re: Programs are dead, and JavaScript has killed them

#145
As I am preparing to update a 10 year old project done in backbone/coffeescript this whole thread hits hard. Likewise a react prototype done in 2018 that is all class based that is going to be next to revive.

Maybe I should just write my own framework... quick, to the name generator sites!

Re: Programs are dead, and JavaScript has killed them

#146
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'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 a directory with a venv and just run it from there. There's no need to resort to compiled languages like Go and Rust which will very likely give you a large raft of other unrelated problems (slower development velocity, comparatively limited libraries, etc.). Going through all of that just to have a binary in hand doesn't seem remotely worth it from my perspective (YMMV).

Re: Programs are dead, and JavaScript has killed them

#147

Earlier quoted context omitted.

The difference is, that JS, CSD and HTML are evolving. They now offer way more than they used to. We can do so much with HTML 5 and CSS 3 already. The argument is to not use React or similar, when a simpler way using standard conform means is available. It is hard to take a comment serious which compares not using React to not being able to do anything productively. It looks like a very junior React-only dev comment.

> The argument is to not use React or similar, when a simpler way using standard conform means is available. Please show me which part of any current or future proposals show a declarative UI + state + input + template binding mechanism which React or even something like handlebars provide. If you're going to mention three or four different API's and explaining combining them together, then you've just reinvented a w…

You can buzzword all day long, but that doesn't make the typical React component any more declarative than the next script. Components reyling on internal state, querying that state and then munging some JS code into some HTML-like template and mutating the state again, when a user interaction happens -- That's hardly a declarative UI. It also does not become more declarative due to using an angle bracket notation for components.

One can look at some Prolog code to get an actual idea about what declarative means. In React you are not writing down constraints and logic rules, according to which React automatically figures things out. You are not working with relations, which need to be kept true. React is far from a configuration only kind of framework.

To claim something like one cannot be productive without using React or similar framework is really a silly thing to claim. Most websites do not even need to use any such framework, because in their nature, they are not interactive. They show information and that is it. Then there is a set of websites, which has here and there some small interactive widget, which one could argue to use a framework for, in parts, not for the whole friggin website. This still allows for people, who merely want to retrieve the information and leave without interacting. The third and smallest category is then the set of websites, which actually need interactivity and state in the frontend everywhere, where such a framework can be justified.

Re: Programs are dead, and JavaScript has killed them

#148
post #138
post #85

Earlier quoted context omitted.

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

It can’t break if it were never correct in the first place. Bash scripts are always chock-full of bugs, and only work when everything in its environment is the same. That folder now has two files instead of one? Now it just stops working.

In my experience, they don’t have more bugs than Python scripts. That’s assuming they’re shorter than 50 LOC. Long before my scripts reach this size I convert them straight to Go. That’s the most problem-free strategy.

Re: Programs are dead, and JavaScript has killed them

#149
post #98

Earlier quoted context omitted.

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

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?

Re: Programs are dead, and JavaScript has killed them

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

That's how it should work. But of course last week I revisited a project I wrote in C# too, this only 3 years old, and apart from dotnet complaining about the target framework not being supported any more, I couldn't get it working again due to the libraries used.

This makes no sense. If you upgraded your libraries, thats in you to fix it tho.
Post reply on HN