Live data from Hacker News

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

news.ycombinator.com

1–10 of 197 posts

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

#1
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!

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

#2
The frontend of my main OSS work was made is plain es6: https://github.com/mickael-kerjean/filestash

The frameworky code is under 100 lines of code, heavily inspired by what I think is a good idea from React: "components are pure function", the simplest example of the about page beeing visible here: https://github.com/mickael-kerjean/filestash/blob/master/pub...

Since the whole project was migrated over from React, I was able to improve performance to a degree that would have been impossible using React, it's a breadth of fresh air to open the performance and memory tab and to be able to optimise things from there to get 60FPS no matter what whilst preventing massive ram usage because those frameworks runs all sort of code that is out of your control. Also because there is no build system, I was able to introduce plugins to be able to patch frontend code via patch applied dynamically by the server to create features like the recall button to recall data stored on glacier when using S3, dynamic patching of the icons to apply branding and many other things that I would have had to fork entirely before

Anyway, I hope our industry would go more often the vanilla route, es6 is ready for prime time and solve all the pain point we had while internet explorer was still a thing

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

#3
We were building decent apps long before React.

Even pre-web. I remember, how quickly I could create Delphi desktop app with drag & drop UI builder more than 2 decades ago. If we speak about generic ERP, you could make dozens of screens in a day.

You just split your app to layers.

That might be for example:

1. Just UI;

2. UI logic (validations, preloading selects...);

3. Transformation of data between data model and UI model

All of the things above lived on users' computers.

All of the things below were on servers.

1. API gateway (terrible things like SOAP, XML-RPC or completely proprietary formats);

2. Business logic;

3. Database

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

#4
I don’t know how they do it but in general the big thing you need to think about is how to handle reactivity.

There is no reason you cannot implement MVVC/MVC or whatever else on JS for reactivity, it’s just that react et al just abstracts that away for you.

You are effectively choosing some method of implementing and abstracting the observer pattern and handling cleanup since you can easily get into a situation where you have dangling references to objects that are never cleaned up (memory leaks) or pretty nasty GC hangs which can make the UI feel bad to use.

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

#5
JavaScript is a really flexible language and it’s easy to build “just enough” abstractions to get stuff done. It may be hard to believe now but at one point web frameworks were not a thing. People used plain old JavaScript and maybe jquery. I worked on several large web frontends (SPAs) back in the 2000s that were pure JavaScript. I did a project in 2018-19 modernizing one to get it off of IE11.

So yeah, JavaScript is nicer nowadays, and browser apis are more consistent than they were then.

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

#6
> 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.

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

#7
Even if you go back to using react it's still useful and fun to read about how people can implement things like virtual doms to get an idea about what's happening under the hood. From there it's easier to figure out if react is the best choice or other choices might be better.

From there one big question is if everything needs to be dynamic or not. You often have menus and navigation that you don't need a framework for and that even something like jQuery is well suited for. On the other hand a framework would probably slow things down for the writing experience in Obsidian, which is the main draw for me to use Obsidian. Once the writing module is written from scratch, it won't seem like such a big lift to also do all the navigation and controls by hand.

That doesn't mean this is the right way for everyone. A lot of times the speed to releasing new features is more important, while the handicraft of the UI/UX is less important and in those cases using a framework is absolutely the right choice.

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

#10
If a migration of breaking changes seems like a lot of work for you then I suppose that rolling your own framework won't be any better.

With the framework, you have structure. It might not be the best structure to use, but you have one. React lasted really long and is still works today.

Going without framework works if:

- you have a really small project

- you are so advanced developer or have specific use-case that using a framework creates more burden than time saving

- you are creating something so valuable that reimplementing it yourself is worth it

I think that regular website will bleed via maintenance costs in the long-run if you don't use a framework. Instead of paved road with framework migration you would be fixing and debugging bugs in your framework/codebase.

Post reply on HN