←back to thread

94 points thepianodan | 3 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 #
actinium226 ◴[] No.45617852[source]
> React is a lot more stable than I think you're giving it credit for.

Hooks are only 5 years old. The docs were revamped 2 years ago and there's lots of dead links to the old docs page which has a scary warning "These docs are old and won’t be updated." Create-react-app was deprecated in February of this year and in their blog post they tell you to use frameworks like Next.js.

And then there's the ecosystem. Next.js introduced app router 3 years ago and lots of docs for libraries still assume you're using pages router. Remix is now react router v7, and I have no idea what's going on with all this Tanstack stuff. There's a new typescript compiler called "Speedy Web Compiler" which just came out in April and as a result Vite now has 4 options for creating a new React project: react, react-ts, react-swc, react-swc-ts

Meanwhile moment.js has had 5 releases in the last 4 years. 3 of them in 2022 and 2 in 2023.

replies(4): >>45618197 #>>45618323 #>>45618483 #>>45620816 #
Octoth0rpe ◴[] No.45618197[source]
> Hooks are only 5 years old

7. Worth saying that React really only took off 9-10 years ago, so hooks are damn near the beginning of time for _most_ react devs.

> The docs were revamped 2 years ago and there's lots of dead links to the old docs page which has a scary warning "These docs are old and won’t be updated.

IMO those are not dead links. A link is 'dead' if it links to a page that doesn't exist. Links to old pages with warnings are appropriate in many cases. Many projects are using older versions of react, and devs need to look up info. Not sure this should be seen as a problem.

> Create-react-app was deprecated in February of this year and in their blog post they tell you to use frameworks like Next.js.

Not sure why this is a problem. A very early tool got deprecated, and the react docs recommend the current paradigm. It's not like they're changing their getting started guidance every month, or even every year.

> Remix is now react router v7

If this is a bitch fest about React, then the react docs and CRA are fair game, but remix isn't IMO.

replies(1): >>45618977 #
actinium226 ◴[] No.45618977[source]
None of these are problems taken separately, but put together they're pretty frustrating. Hooks being 5 years old and being the predominant tool for certain tasks shows that the community only figured out how to solve a particular problem 5 years ago. Compare that, in terms of stability, to Python having coming up with the idea of packages a long time ago, and packages are now a stable part of the ecosystem (packaging is another story which I'll get to shortly).

Revamping the docs is not a problem by itself, but take a look at Python or Django, their docs have the same look and feel for older versions of the code. It's totally a minor problem, and if it were the only one I wouldn't be complaining here, but with the plethora of problems it starts to feel like death by a thousand papercuts.

> Create-react-app was deprecated

Going back to Python packaging, while it's much better than C/C++ packaging, people still love to complain about it! That said, pip is not deprecated. For React to just abandon the idea of helping users to create a project and telling them to "go bother someone else about it" does not seems like something a stable ecosystem would do.

> If this is a bitch fest about React, then the react docs and CRA are fair game, but remix isn't IMO.

It absolutely is a bitch fest about React because I inherited a simple site that should have never used React in the first place and it makes it so hard to do simple things without reinventing the wheel, but anyway, I'd say the ecosystem is fair game now that CRA is deprecated and the docs themselves tell you to go to Next or Vite or React Router or Tanstack.

Anyway, the point is that while React might be relatively stable from the point of view of the larger javascript ecosystem, it's still way less stable than it should be and way less stable than browser APIs.

replies(1): >>45619279 #
1. Octoth0rpe ◴[] No.45619279[source]
> None of these are problems taken separately, but put together they're pretty frustrating. Hooks being 5 years old and being the predominant tool for certain tasks shows that the community only figured out how to solve a particular problem 5 years ago.

Hooks are ~~7~~ 6 years+8months old, almost 7 years. This may not seem like a significant difference, but IMO it puts them 75% of the way back in time to when react took off versus 50% of the way. That is a significant difference. Please stop repeating the 5 year number. It's _provably_ wrong and not a matter of opinion: https://legacy.reactjs.org/blog/2019/02/06/react-v16.8.0.htm...

> does not seems like something a stable ecosystem would do.

I don't think being a 'stable ecosystem' means owning every part of the dev process, or even most of it; nor have they ever intended to do so (they didn't reimplement npm, webpack, etc). CRA existed to fill a particular need for a time (providing a simpler/more stable interface in front of webpack), and when that was no longer needed by the community, they abandoned it. I don't understand why this matters. Better tools emerged, the React docs/guidance reflect that.

> because I inherited a simple site that should have never used React

I'm sorry that you're in that situation. The React community is not really responsible for that IMO, and I don't think the things you've highlighted have meaningfully contributed to making that worse. I stand by the fact that deprecating CRA once great alternatives emerged was the right answer. Next is probably a good answer for many people too. The react team is and should be writing recommendations for the common case for their library, and the fact that your simple site falls outside of an ideal case for React doesn't mean they're not writing the correct recommendations.

replies(2): >>45621290 #>>45622276 #
2. kelnos ◴[] No.45621290[source]
> Hooks are ~~7~~ 6 years+8months old, almost 7 years. This may not seem like a significant difference, but IMO it puts them 75% of the way back in time to when react took off versus 50% of the way.

I don't disagree with your overall point here, but if you're going to be super nitpicky and pedantic about this, then you can't call 6 years and 8 months 75% of 10 years.

3. ricardobeat ◴[] No.45622276[source]
Saying hooks is "seven years old" is just being pedantic. I worked on a major project in 2019 where making the decision to use hooks was a huge leap of faith. It did not become the default way of writing React code until 2020/2021, so five years is more than accurate enough.

- Dan Abramov's first big conference talk was in October 2018

- The official release was in React 16.8, February 2019 - that's six years ago