Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The tragedy of running an old Node project

abdisalan.com

Post reply on HN
Print view View original

321–330 of 412 posts

Re: The tragedy of running an old Node project

#321

Post by NohatCoder »

peutetre wrote: post #106
graypegg wrote: post #43

Earlier quoted context omitted.

I truly believe some flavour of "Javascript Classic" (some future state of JS before some big shift in syntax/mass migration to something else), C and x86 instructions will follow humanity for the rest of time. There will be javascript somewhere aboard the interstellar spaceships of the future, and we will still complain about it.

JavaScript will be killed off by WebAssembly. Zombie JavaScript will be reduced to being glue code and then not even that.

The Webassembly dev experience is awful, and it needs to be glued together with JavaScript anyway. 99% of web code doesn't care about the performance difference, and anything GUI is wasting more time jumping back and forth to JavaScript to save any time at all.

Re: The tragedy of running an old Node project

#322

Post by em-bee »

peutetre wrote: post #106
graypegg wrote: post #43

Earlier quoted context omitted.

I truly believe some flavour of "Javascript Classic" (some future state of JS before some big shift in syntax/mass migration to something else), C and x86 instructions will follow humanity for the rest of time. There will be javascript somewhere aboard the interstellar spaceships of the future, and we will still complain about it.

JavaScript will be killed off by WebAssembly. Zombie JavaScript will be reduced to being glue code and then not even that.

only after they make DOM access easier. see previous discussion here:

https://news.ycombinator.com/item?id=41955585

https://news.ycombinator.com/item?id=41955488

Re: The tragedy of running an old Node project

#323

Post by shepherdjerred »

uludag wrote: post #14

The worst part isn't just that it's nearly impossible to run/update an outdated JS project, but that this process will repeat itself ad infinitum. On the flip side, anything that uses vanilla JS without a build will most likely run just fine, probably till the end of human civilization.

This nearly impossible task took the author two hours

Re: The tragedy of running an old Node project

#326

Post by shepherdjerred »

jollyllama wrote: post #182

For sure. This is the number one reason I am switching as many projects as I can to HTMX. https://dubroy.com/blog/cold-blooded-software/ Sibling comments say in so many words, it's no big deal bro, just update. But it is a big deal over time if you have dozens of cold-blooded projects to deal with.

Gatsby and htmx have approximately zero overlap

Re: The tragedy of running an old Node project

#327

Post by j1elo »

regularfry wrote: post #238
j1elo wrote: post #186

Earlier quoted context omitted.

My not so heretical opinion is that PIP should behave like NPM by default, and work under a local environment subdirectory, just like "npm install" already creates a "node_modules" directory where to put all files, without the user needing to specify how and where and which env tool to use.

Ah, but that would require that the python interpreter look first in the local directory in case there's a virtualenv there, which would mean your system could break depending on which directory you ran bits of it from. Less than ideal. It's better all round to just assume that unless you're building something to be a part of the system itself, that the system interpreters just aren't for you. There's a special case…

That's the idea, yes. Do you have by any chance any experience with Node.js? Running a JS script is usually done in two steps:

  1. npm install
  2. node my_script.js
First one downloads and installs all dependencies listed in a package.json file into a node_modules local subdir. This is equivalent to creating a pip venv, activating the venv, and running pip install against a requirements.txt file.

Second one runs the interpreter with the script file and against the locally downloaded dependencies.

I.e. the local env dirs in Node.js are not a suggestion that you need to learn about, make choices, and actually use; they are just how the tool works by default, which makes the experience of using Node.js with NPM by far much better and less confusing than the default experience of using Python with PIP.

Re: The tragedy of running an old Node project

#328

Post by shepherdjerred »

Etheryte wrote: post #151

Can't help but feel that this is a massive nothing-burger. You wouldn't generally expect your Java project to run if you use an incompatible version of the JVM, nor would you generally expect your C++ project to build if you swap one compiler for a different one. Etc, always specify what your project relies on, whether it's in the readme or in the dependency tree.

People love to hate on frontend/Node

Re: The tragedy of running an old Node project

#329

Post by peutetre »

NohatCoder wrote: post #321
peutetre wrote: post #106

Earlier quoted context omitted.

JavaScript will be killed off by WebAssembly. Zombie JavaScript will be reduced to being glue code and then not even that.

The Webassembly dev experience is awful, and it needs to be glued together with JavaScript anyway. 99% of web code doesn't care about the performance difference, and anything GUI is wasting more time jumping back and forth to JavaScript to save any time at all.

> The Webassembly dev experience is awful

It really isn't. Wasm is just a compilation target now.

Re: The tragedy of running an old Node project

#330

Post by jcelerier »

LamaOfRuin wrote: post #206
elashri wrote: post #197

Earlier quoted context omitted.

Apps that rely on OS provided Webview and electron apps are totally different situation. This is exactly what I said. And no, they don't use any standard nodejs installation like python. And they are different as I said. so this is still apples to orange comparison.

>Apps that rely on OS provided Webview and electron apps are totally different situation. No, they're not. I'm talking about core apps and services that are essential to a functional operating system. This is exactly the same situation. The difference is choices made by the OS and language ecosystem about how to manage dependencies in various use-cases. It is an apples to oranges comparison because of those decisions…

Which apps would that be ? I'm pretty sure there's zero node server running on my desktops & laptops at the moment
Post reply on HN