Ask HN: How does one build large front end apps without a framework like React?

I had a mind-blown-moment when I learnt that Obsidian was built without any frontend JS framework. ( https://forum.obsidian.md/t/what-framework-did-the-developer-use-to-create-obsidian-desktop-application/30724/11 )

The benefits, I can see.

    JS frameworks move really quickly, and when we're working on a large, long-term project, it sucks when big breaking changes are introduced after only a couple of years. Sticking to slow-moving web standards (which are quite mature by now) increases the longevity of a project.

    And the stability also means that more time is spent on delivering features, rather than on fixing compatibility issues.

    There is also the benefit of independence. The project's success is not tied to the framework's success. And it also makes the project more secure, from supply chain attacks and such.

    Because there is no "abstraction layer" of a framework, you also have greater control over your project, and can make performance optimizations at a lower level.

    I feel not using a framework can even make us a better developer. Because we know more of what's going on.

There are benefits to using frameworks too, I'm not here to challenge that.

But this alternative of using none... it seems rarely talked about. I want to learn more about building large (preferably web-based) software projects with few dependencies.

Do you have any suggestions on how to learn more about it? Are there any open source projects you know which are built this way? It needs to be large, complex, app-like, and browser based. I'm more interested in the frontend side.

Thank you!

Show context

Octoth0rpe ◴[17 Oct 25 11:10 UTC] No.45615334[source]▶

>>45615193 (OP) #

> JS frameworks move really quickly

React is a lot more stable than I think you're giving it credit for.

> And the stability also means that more time is spent on delivering features

Frameworks/libs also exist to save you time, thus letting you spend more time on delivering features. And fwiw, the obsidian team seems to agree in principle. Your link goes to a forum post of some kind, in which one may find a link to obsidian's third party deps: https://help.obsidian.md/credits#Third+party+acknowledgement...

These do not include React, but do include:

- i18next - lezer - moment.js

Plus a bunch of others. Why didn't obsidian write their own date lib and chose to use moment.js? Because it saved them time, despite the fact that moment.js does make changes, and many people are moving on from it in any case.

The idea that not using a frontend framework will let you focus on delivering features seems reductive, and the obsidian anecdote doesn't support the idea anyway.

Whatever you're building, it's never a bad idea to deeply understand the tradeoffs that using a library will bring. Obsidian probably couldn't accept the downsides of React due to them needing a bunch of custom renderers for content, which React makes harder. But that is likely a rare constraint for apps in general.

Generally speaking, libs like react exist to save you time and help you focus on delivering features.

replies(4): >>45615472 #>>45615480 #>>45617852 #>>45618677 #

1. mickael-kerjean ◴[17 Oct 25 11:32 UTC] No.45615480[source]▶

>>45615334 #

> React is a lot more stable than I think you're giving it credit for.

That's until you have to use it in a real project, for a long time the go to solution was the facebook maintained CRA which is now deprecated. I have spent a lot more time than I'd like to admit migrating webpack versions when it was considered best practises to use class component with decorator but decorator never was standardised in the browser and was never able to get a clean project where running npm install would not give scary warning our project had high vulnerability that was dependencies of dependencies in CRA to the point that it got me wondered that even if the creator of react facebook can't get their shit together, the whole ecosystem is doomed. I have been outside the ecosystem for a year and looking at the shit show that is nextjs it seems things are even worse than before.

replies(3): >>45615518 #>>45615644 #>>45615862 #

2. Octoth0rpe ◴[17 Oct 25 11:37 UTC] No.45615518[source]▶

>>45615480 (TP) #

These are good points, but many of them aren't specific to React, and in fact likely apply if you're rolling most of your own code. For example, the app that OP used to start the conversation uses webpack (https://help.obsidian.md/credits#Third+party+acknowledgement...).

> running npm install would not give you a dozen high vulnerability package

Yes, this is a serious problem, but mostly an npm messaging problem: https://overreacted.io/npm-audit-broken-by-design/

replies(1): >>45615961 #

3. whizzter ◴[17 Oct 25 11:50 UTC] No.45615644[source]▶

>>45615480 (TP) #

I agree with the Next shitshow, but webpack/CRA was always shaky while Vite's sane defaults (and great reloading) has been a great improvement for us outside of the Next world and functional components now feels like a fairly non-error prone and simple way to work so I don't see that going away for a long time (and has already lasted a bunch of years).

I think the only shaky moving part for us right now is styled components being left behind due to the RSC changes, but there's both mostly source compatible rewrites as well as perhaps even better alternatives (vanilla-extract).

replies(1): >>45620301 #

4. mexicocitinluez ◴[17 Oct 25 12:15 UTC] No.45615862[source]▶

>>45615480 (TP) #

> the go to solution was the facebook maintained CRA which is now deprecated

Not only did they deprecate it, they refused to acknowledge it's existence in the new docs which is wild to me.

It may have changed in the last year, but if you searched for "CRA", it would get 0 results. Again, mind-blowing considering it was the recommended way to build apps with React.

Instead, it was replaced with a section driving you towards adopting Next. Which then had to be whittled away at and updated to include other options all the while the React team acted hostile to any criticism of it. You either used Next or you were shit out of luck.

> I have been outside the ecosystem for a year and looking at the shit show that is nextjs it seems things are even worse than before.

My thoughts about CRA aside, you don't have to use the frameworks (I still don't). And if you remove Next from the equation, things are actually pretty cool. Suspense is cool, and you'll have to rip React Query from my cold, dead hands.

5. csande17 ◴[17 Oct 25 12:26 UTC] No.45615961[source]▶

>>45615518 #

Dubious "regular expression denial of service" vulnerabilities seem like a general issue with the CVE bureaucracy lately. Like, maybe CVE-2020-10735 had a point that Python's default "int" type having unbounded size and a quadratic-time "str()" was a bit of a footgun, but now it's getting to a point where any use of backtracking in any context is just asking for a "high severity" ticket from the regex police.

6. tracker1 ◴[17 Oct 25 18:37 UTC] No.45620301[source]▶

>>45615644 #

Agreed... I quickly ejected from the couple CRA projects I've used and quickly switched to Parcel, then Vite as they matured as it's just a much better experience. Not nearly as bad as trying to update some of the testing frameworks.

↑