←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.253s | 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
moron4hire ◴[17 Oct 25 11:54 UTC] No.45615676[source]▶
The reality is that DOM is pretty high-level already. It's just not that hard to do. The only things that have improved my productivity over the years are:

  A) getting better at handling graph data structure, 
  B) learning how to use Regular Expressions as a code editing tool,
  C) quit chasing every new thing, and
  D) Typescript.
Having spent the last 20+ years building Web apps, I've only just started using React, due to company policy change. And quite frankly, I think it makes it much harder to maintain a large project. My company switched to React to make apps "easier to maintain for everyone" and in the process I've been the only one that has managed to learn React well enough to be productive in it. Most everyone else is really struggling with getting anything beyond the most basic stuff to work.

JSX encourages sloppy HTML. Props are are overly verbose. Hooks are a nightmare. Contexts are gross. Portals are a stupid hack for the very, very stupid reason of making it nearly impossible for parent elements to read anything about their children. The whole "props down, events up" paradigm is woefully naive and half of React exists to get around it because of that.

So yeah, if all you know is react, you've already been on the hard path.

replies(1): >>45618316 #
rrgok ◴[17 Oct 25 16:06 UTC] No.45618316[source]▶
So, how do you manage reactivity? Manual DOM patching?
replies(1): >>45620822 #
1. moron4hire ◴[17 Oct 25 19:16 UTC] No.45620822[source]▶
Yeah, it's not that big of a deal.

This whole thing about "absolutely everything must be pure, functional reactive code" is just something that people used as a cudgel to get their fellow developers to adopt React. And React isn't even pure, nor does it really do reactivity right! But it makes for cool demos where you can throw together TODO-APP really quickly and never mind that real world applications have much more, cross-cutting complexity that just can't fit into the reactive paradigm.

Yes, managing program state is hard. Full stop. React doesn't actually solve that problem. In fact, I think it makes it worse, because of how top-down, everything-should-be-props it is. Elements should be able to inspect their children. Elements should be able to move them around however they want. And those elements should be written to just take it.

There are major parts of React's modern design that point to the fact that it was clearly taken over by functional programming weenies (not that I hate functional programming, just the kind of people who insist it's the only way).

We only have to look at Hooks to see why. Hooks must only be called at the top-level of a component. But where do Hooks come from? Regular imports that are then accessible anywhere. It violates the open/closed principle. What should be a protected method of a base Component class, so that only implementing child classes can call it, is instead possible to call from anywhere with no indication it's wrong until runtime. That's just bad design, in OOP or FP. Someone, somewhere at Meta, decided "Object-oriented programming is wrong" and went out of their way to avoid it.