whatever your stack is, if I cannot just build and run your app in 20 years with the same ease as you're doing it now, your stack is trash.

this is a part of the reason I don't use any tools to build my frontend now and just use simple files.

What HN App is this?

@jonas-w I read nothing news online. Neither reddit nor HN nor anything else. This pic was sent to me by a friend.

This is why I don't use React, Gatsby, next.js and other trash like that. Projects using them are impossible to build after just one year of abandonment, let alone 10 or 20

@kiki To be honest, I use vuejs for making a website.

(I plan to make a new one using angular just for fun)

But my vision on those are that once they are made, nothing will change.

By the time it needs to be changed, there will be probably a new next 'thing' and it will be faster to remake it.

(Same goes with corporate websites : Oh we don't like this page... let's ask a quote for an entire new website)

Yes true story and has happened where I work twice in less than 3 years.

This article is about OS/2 - it doesn't mention anything about the software stack used to build the app that runs on the OS. So the gist basically is: Find a vendor too big too fail, keep paying a premium for very very long term support, and hope that the vendor lockin doesn't end up killing your project. sure, you can do that if money doesn't matter at all. The NYC subway, being owned by the city, probably has the budget...

Completely unrelated to that, you are right though: Software "stacks" did became way too obese and dependency trees became way too tall and brittle.

But only maintenance can actually keep a project alive and compatible for twenty years, no matter what. The NYC subway does run a sortof isolated system with only few very well defined interfaces to the outside world. And they did actively maintain and update their software during that twenty years. They didn't just built the thing and then forgot about it.

@Grumm they do change. I had a case with Vite that my entire react setup ended up being dependent on a single package-lock.json file of one of my framework's dependencies.

Frameworks are huge. Someone messes up semver — boom, now if you delete your lockfile, everything you worked on will be reduced to ashes. Tool's popularity unfortunately doesn't really matter here. You can't be banking on others forever.

To me, it seems like the only winning move is not to play. Sure, I might need some dependencies like three.js or d3, but I will never build my app itself on top of a dependency, like some framework.

This is why I build on top of the language itself. I use Web Components. I don't use bundlers and transpilers. ES modules with imports work out of the box already in the browser with <script type="module">. Browser support is excellent.

@Oktokolo heard about antville?

@Grumm also, bear in mind the psychological aspect. Imagine being hired just to see the codebase in Knockout.js or some other ancient shit. This is what will happen to your vue and angular, inevitably so.

I'll never go back to using a framework. No matter how nice their twitter is (I don't use twitter), no matter their OpEnSoUrCe marketing, dan abramov, all that hype. I don't care. It's all temporary, it comes and goes.

Features of the language themselves will outlive any framework out there right now. They are to be relied upon.

@jonas-w The app is called Materialistic

@saucyatom 413 issues on github and no commit since 3 years lol

@kiki I can imagine the horrors.

Maybe it is my luck that I will be the first one to create the new stuff here.

Again, the website was only a quick solution from me. If the company wants something else, they should probably hire some actual web developers who can do the job.

My best work/biggest don't use fancy stuff but plain c# and the library for writing nfc tags. (I hope futur proof but you never know these days)

@kiki Nope. But it looks like a framework for blogs that depends on Helma, which itself is a framework written in Java and Javascript. Why anyone would combine a very dynamic messy language with a static formal one, i don't know. Normally devs for one of these languages hate the other. that dependency honestly looks like a death sentence to me. It may work now, but good luck keeping such a clusterfuck maintained. Their documentation link already goes to the webarchive...

Was this meant as an example of what shouldn't be in dependency tree?

@Grumm oh, you use C#? If you're not a web dev, but merely need to do some rudimentary UI for your app, and do it quickly, Vue is fine.

But if your speciality is frontend, it is not.

@Nanos are you okay? it is not related to your answers, I'm just asking in general. I remember you were going through some tough shit last time we spoke

@Nanos I send you virtual hugs. I wish you the best 🥰

@kiki I write mostly desktop software.

The only website for the company was a simple project and wanted to make it somewhat interesting for myself and to know what was all the fuzz about those new frameworks using javascript.

Me, crying in Xcode 🥲

Unlike most apps, the subway scale is in a huge part defined by the scale of the railway. It’s not expanding that fast for most systems. Ridership is a hard limit by the number of trains running. I imagine a lot of subways get away with deferring upgrades

all these frameworks ship with crypto miners anyways