←back to thread

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

94 points thepianodan | 1 comments | 17 Oct 25 10:50 UTC | HN request time: 0.202s | 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
iliaznk ◴[17 Oct 25 12:46 UTC] No.45616121[source]▶
They will write their own framework of sorts in any case.
replies(1): >>45616240 #
thomasikzelf ◴[17 Oct 25 12:58 UTC] No.45616240[source]▶
I don't think this has to be true. If you think of a framework as a piece of code that calls you where you sort of supply it with configuration you could do that when writing vanilla js but you don't have to.

When I write vanilla js I don't have a seperate file called framework.js. There is very little code needed to manage state. Almost all functions in my codebase are doing concrete things.

replies(1): >>45617599 #
iliaznk ◴[17 Oct 25 15:02 UTC] No.45617599[source]▶
I mean in a complex enough application you'll have to come up with some abstractions that will make you life easier anyway. I doubt that you will manually add and remove classes, or add and remove nodes via direct DOM API calls every time you need to do that. You know what I mean? A set of such abstractions is what I call a framework. It doesn't have to be a separate file called "framework.js". It may even be more of a library than a framework. But I believe you will inevitably come to that to centralize certain things and make them easier to do.
replies(1): >>45620900 #
1. thomasikzelf ◴[17 Oct 25 19:22 UTC] No.45620900[source]▶
I do use abstractions to make my life easier. The main abstraction is a function called tag:

    const tag = (tagName, props, ...children) => {
        const el = document.createElement(tagName)
        for(let k in props) el.setAttribute(k, props[k])
        for(let child of children)
            el.appendChild(typeof child == 'string'? document.createTextNode(child) : child)
        return el
    }
This makes the construction of new elments a bit more concise. The rest is just functions, manually adding or removing classes and adding or removing nodes via the direct DOM API.

The main advantage I think React brought is breaking the concept of "separation of concerns" (keeping css, html and js in different files even when they change together). Keeping stuff that belongs together in the same file and mostly pure is what gives the most benefit. You don't need complicated frameworks for that.

    const createSpecialButton = text => tag("button", {style: "background: purple"}, text)
When something becomes a framework is a bit blurry. I consider this more of an utility function. It is only 7 lines long. You call it, it does not call you. It gives you back a concrete element, not some abstract intermediate value. It is completely optional. The amount of these utilities you need in a big project is still tiny.

I wrote a figma clone (see other comment) with couple of these utility functions. It looks a lot like a regular react project really. Mostly functions (which you might call a component if they return HTML), mostly pure or local state.