←back to thread

94 points thepianodan | 1 comments | | HN request time: 0s | 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
Octoth0rpe ◴[] No.45615334[source]
> 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.

replies(4): >>45615472 #>>45615480 #>>45617852 #>>45618677 #
mickael-kerjean ◴[] No.45615480[source]
> React is a lot more stable than I think you're giving it credit for.

That's until you have to use it in a real project, for a long time the go to solution was the facebook maintained CRA which is now deprecated. I have spent a lot more time than I'd like to admit migrating webpack versions when it was considered best practises to use class component with decorator but decorator never was standardised in the browser and was never able to get a clean project where running npm install would not give scary warning our project had high vulnerability that was dependencies of dependencies in CRA to the point that it got me wondered that even if the creator of react facebook can't get their shit together, the whole ecosystem is doomed. I have been outside the ecosystem for a year and looking at the shit show that is nextjs it seems things are even worse than before.

replies(3): >>45615518 #>>45615644 #>>45615862 #
whizzter ◴[] No.45615644[source]
I agree with the Next shitshow, but webpack/CRA was always shaky while Vite's sane defaults (and great reloading) has been a great improvement for us outside of the Next world and functional components now feels like a fairly non-error prone and simple way to work so I don't see that going away for a long time (and has already lasted a bunch of years).

I think the only shaky moving part for us right now is styled components being left behind due to the RSC changes, but there's both mostly source compatible rewrites as well as perhaps even better alternatives (vanilla-extract).

replies(1): >>45620301 #
1. tracker1 ◴[] No.45620301[source]
Agreed... I quickly ejected from the couple CRA projects I've used and quickly switched to Parcel, then Vite as they matured as it's just a much better experience. Not nearly as bad as trying to update some of the testing frameworks.