←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.209s | 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
austin-cheney ◴[17 Oct 25 11:26 UTC] No.45615437[source]▶
The reasons I avoid large frameworks like React, Angular, Vue, and even jQuery is that they are aren't necessary. They are code decoration that slows things down. Here is what you can expect without these:

* greater flexibility

* faster execution, My current application produces a large single page application that fully renders visually and executes state restoration in about 105ms localhost or under 200ms across a network

* faster maintenance, I can do massive refactors that touch most files in the application in about 2 hours thanks to thorough use of TypeScript interface definitions

---

Here is how I do it:

1. Just start building your application. Realize that for any significant application the front end UI is probably only about 20% of the application code, or less.

2. Start the UI by writing static HTML. Reserve JavaScript, in the browser, only for handling events and state restoration and execute state restoration only on page load.

3. I prefer to use WebSockets over HTTP as much as possible for absolutely everything I can get away with. WebSockets are full-duplex, where HTTP is not, and have far less overhead. That will substantially reduce the complexity around messaging in and out of the web browser.

4. Everything after that is just execution, planning, refactoring, and feature addition.

5. You can do absolutely all of it in TypeScript now without any compile step. Node.js now executes TypeScript directly, but the browser does not. To solve for the web browser just include the browser code into your Node application using ES6 module import. If the imported code is a function you can convert it directly into a string for transport, and otherwise use JSON.stringify for objects/arrays.

replies(3): >>45615736 #>>45615888 #>>45615988 #
mexicocitinluez ◴[17 Oct 25 12:18 UTC] No.45615888[source]▶
> and even jQuery is that they are aren't necessary.

JQuery was never considered "necessary". It's just a much prettier wrapper around the native dom apis. Arguing against adopting a more readable api (and codebase), is gonna be a tough sell.

replies(1): >>45616833 #
austin-cheney ◴[17 Oct 25 13:51 UTC] No.45616833[source]▶
Nobody worries about fashion when buying a shovel. Your users don't care about your code fashion. These things are clear when an outside party can observe your developer habits and inform you where your priorities are as opposed to what you state they are.
replies(1): >>45617043 #
1. mexicocitinluez ◴[17 Oct 25 14:14 UTC] No.45617043[source]▶
> Nobody worries about fashion when buying a shovel.

Huh? Are you implying the code will never get read by another developer or possibly modified? Are you arguing there is no reason to make your code more readable?

> These things are clear when an outside party can observe your developer habits and inform you where your priorities are as opposed to what you state they are.

What?