←back to thread

94 points thepianodan | 1 comments | | HN request time: 0.314s | source

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
strogonoff ◴[] No.45615558[source]
It’s always mildly amusing how many engineers believe that React is a framework. I personally attribute it to lack of experience—once you’ve used enough proper frameworks, you’d laugh at that comparison. The fact that React is and always has been literally defined as a library right on its website doesn’t seem to stop them.

Incidentally, many of the issues people have with React are attributable to this mistake: knowing what a framework is supposed to be, one might expect React to take care of everything, and when it turns out you’re on your own and using React in a complex project means (whether consciously or not) coming up with a homegrown React-based framework of your own, or using a collection of disparate extras that fill in the blanks (like CRA), by then it’s already a hairy mess of a codebase in a desperate need of refactoring.

React lacks most of framework traits. The library does reactive rendering and contains a somewhat restricted set of low-level primitives around it. Even its DOM integration is handled by a separate, optional library (ReactDOM).

Someone could complain it feels like with Vercel the direction for React is to become closer to a framework (now with RSC and JSX runtime being part of React), but still it is nowhere near a state where the phrase “a framework like React” rings true—and, in fact, Vercel’s interests are aligned with keeping React more of a library than a framework so that more people use Next and are upsold Vercel’s hosting, and Next is in fact a framework in the full sense of the word, comparable to Django or Rails.

Similarly, Vue, Angular, Marko, Astro, Qwik, etc. are frameworks. They provide you with project structure, scaffolding, and a lot of batteries. The fact that many of them are, in fact, using React under the hood speaks volumes.

replies(2): >>45616424 #>>45617749 #
HumanOstrich ◴[] No.45617749[source]
<https://en.wikipedia.org/wiki/Software_framework>
replies(1): >>45624806 #
1. strogonoff ◴[] No.45624806[source]
Yup.