Live data from Hacker News

Programs are dead, and JavaScript has killed them

pouria.dev

121–130 of 216 posts

Re: Programs are dead, and JavaScript has killed them

#121
post #84

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

It's funny. The issue described (inability to replicate the conditions to build and/or run the original program using NPM) is something that gets brought up a lot, but people will appear who are downright adamant that it's not a problem. Not just that it's not prevalent enough to be concerned about, but that they've literally never seen it happen ever. We're living in completely separate worlds. And let's be clear: t…

Of course it's a JS problem. "Programs" being replaced by JavaScript apps doesn't mean some custom homegrown LTS framework. It means apps that aim to replace what used to be known as "Programs" have some sort of frontend JS component. frontend JS doesn't mean npm.js sure, but it means whatever flavour of bower is hot today, webpack or the other new kids on the block, react or other stuff. There is a reason why these big companies hire unlimited amounts of frontend devs. If you leave a react apps dependencies half a year and then try to update it none of it will work. It's "less" bad than it was 2 years go, but it's extremely cost-intensive to maintain nonetheless.

But it's not like backend js is any better. Most people run express.js in some shape of form, but then people roll their own (or use any of the existing 50) input sanitizing libraries and then half of those projects run into the same authentication bugs that Rails fixed almost a decade ago. There's a reason why people don't ask for JavaScript experience, but instead ask for Node.js experience in resumes.

Re: Programs are dead, and JavaScript has killed them

#122
post #26

I have a bit different view. If some app is not updating - there is not much use for it. Just like houses - yeah you can have 100 years old house but if you did not invest in it and expect to be just as good as new you are in world of pain. Same with cars - 10 years and you really have to change quite some parts. Applications are ideas - we expect that ideas don't "wear out" - well most of ideas wear out rather quick…

> well most of ideas wear out rather quickly and are not useful for centuries I'm not a religious person, but already a couple thousand years ago the bible folk rightly identified that there is nothing new under the sun. Or as BNL eloquently puts it, "it's all been done before." I don't know how we could ever quantify it or qualify it, but I would guess that most ideas stick around.

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.

Re: Programs are dead, and JavaScript has killed them

#123

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…

Learning React, Node.js, and Tailwind doesn’t mean that you’re not learning HTML, JS, or CSS…

Oh in theory you are correct, but in practice once people are given a hammer, everything starts to look like a nail, especially since they do not yet have the basics down well enough and it does lead to them not really learing the basics, because "it also works with React" (no matter how shitty and with how much overhead)

Re: Programs are dead, and JavaScript has killed them

#124

Earlier quoted context omitted.

Learning React, Node.js, and Tailwind doesn’t mean that you’re not learning HTML, JS, or CSS…

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.

Re: Programs are dead, and JavaScript has killed them

#125

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…

> Do NOT learn React, Node.js or Tailwind. Learn HTML, JS and CSS. How exactly should I use html and css to replace nodejs?

You don't do server side code in JS and then you don't have a need for Node.js. Easy.

Re: Programs are dead, and JavaScript has killed them

#126
post #92

There's no free lunch. JavaScript has the largest package ecosystem in the world. It's great for finding "free" UI components or server libraries for projects, but you pay for it in maintenance costs. That said, I don't think it's as bad as this article makes it out to be. There's this kind of maintenance in a traditional server-rendered Django/Rails app, too, on both ends. You can self-host your JS scripts or fetch…

I've got perl web apps that haven't been touched for 15 years (aside from a single change from a flash to in the template) that still perform their function perfectly well

Sure - if you don't need rich UI interactivity, you can get by with a lot less. Plenty of sites don't and should.

What I like about Node, though, is frameworks like Next.js that are the best of both worlds. You can do traditional server-side rendering using React components, so you can easily add as much/as little client-side JS as you need.

With Next you use the same package manager for the front end and back end. And you get code sharing and access to that huge ecosystem of libraries.

But needs and skillsets change the equation, definitely.

Re: Programs are dead, and JavaScript has killed them

#127
post #94

Earlier quoted context omitted.

nvm is my solution to this It isolate and pins npm installs so that the environment is the same in the future without messing up your main system Your projects also need to consider pinning their dependencies to a specific version Other languages/frameworks with package managers have similar concepts

> Your projects also need to consider pinning their dependencies to a specific version At that point, you should consider just using your version control system to handle versioning instead of trying to route around it, poorly.

As a long-time ruby user where bundler has done version pinning for decades, I think this is a core feature of any dependency management system, not some kind of "routing around it."

I'm not sure what "your own version control system" means. Checking all dependencies into (eg) git? I'm not sure how you deal with indirect/second-level dependencies, but any kind of roll your own like that to me is what I'd call "routing around" the failures of your platform dependency management system.

Correct dependency pinning also allows you automated ways to upgrade dependencies, resolving requirement trees, within stated bounds specified per-dependency (like keep to same major version). It just happens when you want, not every time you install or deploy.

Re: Programs are dead, and JavaScript has killed them

#128

The solution is very simple. Lock your versions in package.json. Everyone stays happy. The only thing to keep track is, is what version of NodeJS you are using. It will happily keep working for years! Do I get a super long list of deprecated and warning messages? Yes, they are also meaningless. You can ignore them and just build the feature.

This is exactly my feelings throughout this thread. We have apps in prod that haven't been touched in years that don't break and handle average to high req/s. We add a line here or there as we need to for bug fixes but we don't have any dep problems randomly breaking the app.

Pin your deps and everything keeps working how you want.

Re: Programs are dead, and JavaScript has killed them

#129

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

Nim is great for this use case.

Re: Programs are dead, and JavaScript has killed them

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

I refer to .net as the language a lot of the time too, they are tied even more strongly together, as described in https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... . I'm probably just not being precise about the language. I'm happy to pin this on NodeJS but Node is the key reason why javascript is used for any non-web work at all and it's almost impossible to separate that. The javascript ecosystem and…

> 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 bring with them).

As for build toolchains: even taking the comment that "if you only do web work now you still need node for the build toolchain" charitably, we could understand it to mean that NodeJS-based toolchains save you time, rather than that you strictly need them in a literal sense. Even that argument is dubious. It's worth considering, if people spent half as much time working on the drudge work that these toolchains are ostensibly supposed to be saving them time on, instead of dealing with the dysfunction that comes with these tools, where might they be? Ivan is doing a-okay with Photopea despite repudiating basically everything about NodeJS.

In practice, those toolchains have proven to be a false economy for many circumstances where they end up being (mis)used. More honestly, they're shiny distractions that people put at the forefront of their attention because that's what they like doing—and they're willing to lie to themselves by saying they're doing something essential.

> You can't realistically develop without it

Sorry, bud, this is wildly exaggerated. It's simple bullshit. I won't concede to such an argument that doesn't have a firm basis in truth.

Or, if you want a pithy rejoinder, here's one: "You can't realistically develop with it!"[1]

Firefox is one of the most advanced early codebases that made extensive use of JS for serious use—and still more serious than many of the things that people are writing in JS today—and there was no use of NPM—because neither it nor NodeJS (nor V8!) even existed yet.

1. https://news.ycombinator.com/item?id=24495646>

Post reply on HN