Live data from Hacker News

Programs are dead, and JavaScript has killed them

pouria.dev

171–180 of 216 posts

Re: Programs are dead, and JavaScript has killed them

#171
post #85
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#,…

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

The recent deprecation warning message of `egrep` is a prime example that bash scripts can break (depending on stderr processing). They will definitely break once the alias is removed.

Re: Programs are dead, and JavaScript has killed them

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

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…

i agree.

.net is a cathedral platform, well manicured by a small trusted force that tries to make eveything fit together, that works semi-cohesively, to produce a manufactured industrially syitable one-solution to everything.

js is a bazaar language, that had many intertwingular existences in different places, doing different in similar things in thousands of different ways. it's innovation & history is chaotic & messy, with many onetime behemoths left by the wayside (jquery, gulp/grunt, backbone, moment, request). everything is a bit messy & organic & grown together, pieces breaking off & advancing one direction then being woven back with another library to work a third way.

> There's no way around this problem but to dedicate hours every month to keep everything on the bleeding edge.

i dont disagree.

work has spent considerable time dragging a couple dozen old fairly complex react apps & services we inherited out from node 6, node 8 this year, freshening things up.

it is however amazing how much stuff did just work. how many deps we could look through the changelog on, say, that's fine, and upgrade, and tests pass & on deployment things keep moving along. did we get bleeding edge? eh, like 50% of the time. in many cases we didnt even bother trying to get current. we checked dependabot vulnerabilities & did what we had to, stayed in the past for now. these apps were all running, live, with traffic... it's amazing how much of this messy organic tangle does work.

we did run into some of the version conflicts & problems, some of the conservative concerns, the reasons for fear & trepidation you cite. it wasnt fun work. no one wanted to be here. but we got through it in quick order, and it ended up being a whole lot less pain than us engineers expected & budgeted for. we were left with the impression of ease. confidence grew.

as others have tried to point out, i dont think your real complaint is with JS specifically. the organic nature of this world doesnt suit your desires. and i think that's a reasonable stance, these arent unreasonable values/complaints. but on the other hand, the organic has, i think, taken over with rightful cause. Azure OS is in huge part React, huge part JS. the tech adapts much faster. not being a carefully staged industrially-focused cathedral, being an organic place that values & cherishes idea & potential, has let us try a lot of things & keep exploring where real value is, and has kept leading us to better places. we understand more through the experimentalness of the process, we see such vistas that the cathedral makers could not have dreamed, find higher heights & ascend. & yes, sometimes as we rise above the clouds, we spy yet higher peaks, and we must decide whether & how long to stay where we are, or to try again, move onwards.

personally this organic world has brough me great joy & a wonderful continual sense of progress. that we have kept honing ourselves, reshaping. it feels finally like we are starting to really settle down more, that we have made finer cuts at iteration. apis are much more stable. the platform has amassed a more solid core, as groups like WinterCG bless & spread more of the much developed web platform as stable trustworthy systems. React has spent years building towards Suspense & it seems uncharacteristically humble, for a framework that had iterated so much & so heavily for so long, & there's little on the radar that gives us a sense there will be a next breathtaking new era. the organic has settled, become over time more like the cathedral you might have hoped for.

Re: Programs are dead, and JavaScript has killed them

#173
post #106

Earlier quoted context omitted.

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

> Does that matter?

Well, yeah—for reasons already explained.

Millions of desktops will boot into Gnome Shell today. Millions more people, including people using Windows and Mac and not Gnome Shell, will open Firefox. There will be no NodeJS process running in the background in order to achieve any of this, nor will there be API-compatible runtime involved.

There's absolutely no reason not to say NodeJS when that's what you mean. There is a problem with blanket generalizations about "javascript" that implicate other software and software developers that have absolutely nothing to do with NodeJS or the any of the NodeJS-specific problems that are well past due (read: should have been solved by now). The world is bigger than the back-end/front-end dichotomy that webdevs spend all day thinking about.

I have no idea how to even respond to your CSS comments. Without even getting into whether it's true or not, it's just totally irrelevant. Painfully so. ChatGPT writes more salient responses.

Re: Programs are dead, and JavaScript has killed them

#174
post #21

We are probably at the tipping point where the JS engine should now be part of the kernel and run in ring 0.

I see you haven't watched this talk about the history of JavaScript between 1995 and 2035 since that's exactly what happened in this future: https://www.destroyallsoftware.com/talks/the-birth-and-death...

I have! It's a very good talk. I wouldn't make any design or technology decisions based on it tho.

What is clear today is that Javascript is on every computer in the world (including phones). It is now even taking over for native desktop apps and native mobile apps. At this point, including a JS engine into all the kernels for apps and browsers to use just seems prudent.

Re: Programs are dead, and JavaScript has killed them

#175
post #39

Earlier quoted context omitted.

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

Why and how?

In my opinion Python modules are rarely "one function" dependencies. And while the ecosystem is certainly enormous, so is the standard library, so for many common tasks, I don't even need to `pip install` a new dependency.

Yes, "virtual environments" used to be kind of messy, and the fact that there are usually 2 competing ways to install modules (via the OS pkg manager and pip) doesn't help either. But since `pyenv` and `venv` exist now, venvs are much less of a hassle than they used to be.

Re: Programs are dead, and JavaScript has killed them

#176
post #43

The only reliable solution to this that I have found is compiling an app into a docker container and ensuring my projects are able to run off a SQLite database. I then save this to my NAS. Otherwise literally everything will break. Running an app that I wrote only 3 years ago will blow up.

I don't understand: if you have fixed dependencies and the same Nodejs version, how can things break? I'm not saying it's a good thing to not update your packages but you seem to imply there's another force messing with your project?

In general it's a hassle when your processor arch, OS version, and node version starts to come into play. NPM doesn't handle this in a great way, especially with native dependencies that need to build, and rely on OS apis. NodeJS isn't particularly stable either.

For example, I used to dev apps on windows, and run them on Ubuntu 16. That worked alright but required minor changes. Moving to Ubuntu 20 on my server required a couple tweaks, and then later moving to deving on Mac required more changes.

Of course keeping old copied of databases is a different story but SQLite is just so convenient compared to backing up full fledged SQL dbs.

These were for old finished projects I wanted to briefly spin up.

Re: Programs are dead, and JavaScript has killed them

#177

My experience is pretty similar for my projects but I think generally we shouldn’t point too many fingers. When it comes to public projects, I’ve found a lot of trouble regardless of its JavaScript-proximity. I think we’ve been blessed by a growing ecosystem of projects that are clean to build, and eschew problematic dependencies. Try building anything Linux and C related and you’re worse than JS because now you need…

Yeah, people are jumping the horse to claim any dev environment is superior and free of issues like this. I've contributed to some open source C++ projects and a lot of js/node projects, and in my experience, every C++ project is an adventure just to get the project compiling (it can be smooth running if the maintainers have a recently-updated guide specifically for your exact OS/distro version and the right versions…

My experience matches this.

If there is a native dependency, then moving major node versions or moving to arm can cause difficulties or straddling the python version the gyp build system is based on.

It's worlds easier than trying to insure your C/C++ build environment is prepped properly to build a binary.

Updating libraries is usually not too bad, even across major versions. But that can be a bit of a wormhole trying to get everything squared away and all versions updated. This seems to be particularly true since all major frameworks I've used have gone from snake case deps (framework-module) to @framework/module.

Re: Programs are dead, and JavaScript has killed them

#178
post #152

Earlier quoted context omitted.

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

> Most of the modern web will be broken on older devices. And the super heavy js websites will work?

Not necessarily.

How old and how backward compatible are you thinking?

- Symbol is 2014-2015

- Map is 2014-2015

- Weak* data structures and their methods span 2014-2021

- WebGL 2.0 is 2017-2021

- Custom Elements are 2017-2021

- Chrome-only non-standards (hardware APIs and a bunch of others) are pumped out at a rate of up to 400 per year

- WebAssembly MVP is 2017-2018

And so on. That's off the top of my head. None of them are backwards compatible. Some of them cannot be polyfilled.

Re: Programs are dead, and JavaScript has killed them

#179

Earlier quoted context omitted.

I was going to say the same but I think you said it much more clearly than I would have. I see this meme a lot. "I hate X, don't learn X, Y is better because Y is fundamental to Z". I have not once seen these same people suggesting "Don't learn the toolkit/framework/control library for your OS, instead use raw WinAPI or X System calls and push raw pixels to build applications". Yet, they push for the same with HTML.…

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.

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

There are no simple ways to build UIs available in HTML5 and CSS3.

It has neither state handling, nor reactivity, nor any APIs that don't make you tear you hair out (or build another lib/framework).

It's a horrendously bad half-low-level half-high-level API with hundreds of one-off solutions and special cases that form no coherent whole.

You still can't reliably animate adding to and deleting items from a list without hacks because even if you so much as look at DOM, it will re-layout and re-draw the entire document.

It still has no collection of well-specified built-in controls beyond a few primitive ones. https://open-ui.org/ is about twenty years too late.

But sure, you can finally put items in grids now. I guess that's nice. But when you need a dialog element you need copious amounts of hacky Javascript to make it properly accessible. Go figure.

Re: Programs are dead, and JavaScript has killed them

#180
post #59
post #45

Earlier quoted context omitted.

> My CD ripper/burner is going on twenty years old and it works flawlessly. This is probably a good example though. The state of the art in CD ripping has advanced significantly over the last 15 years. If you care about bit-perfect rips or even just reliable error correction, it would pay to know about the advances in Exact Audio Copy (Win), XLD (Mac), or Whipper (Linux). All of these have seen releases since 2020. I…

Good to know if I ever hear an error in a track I ripped. Hasn't happened in two decades so far, but you never know.

The odds of it ever being noticeable are indeed quite low.
Post reply on HN