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

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

> React is a lot more stable than I think you're giving it credit for.

A lot of the HN zeitgegist would have you believe React is the opposite, sadly.

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

These are good points, but many of them aren't specific to React, and in fact likely apply if you're rolling most of your own code. For example, the app that OP used to start the conversation uses webpack (https://help.obsidian.md/credits#Third+party+acknowledgement...).

> running npm install would not give you a dozen high vulnerability package

Yes, this is a serious problem, but mostly an npm messaging problem: https://overreacted.io/npm-audit-broken-by-design/

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).

The React ecosystem moves really quickly, and likes to re-invent wheels.

But React core APIs remain relatively stable, I've been using React the same way for many years at this point, and you can ignore the parts you don't like, like I'm ignoring hooks and haven't found a single use case where I needed them.

Could you please tell me how are you avoiding hooks? You're not using useState or useEffects?

I mainly use React via Reagent in ClojureScript, and literally have no use cases where I need to use useState/useEffects for anything.

Turning it around, what exactly are you unable to do without useState/useEffects?

class components (which do not use hooks) are still supported by React with no scheduled deprecation AFAIK.

> the go to solution was the facebook maintained CRA which is now deprecated

Not only did they deprecate it, they refused to acknowledge it's existence in the new docs which is wild to me.

It may have changed in the last year, but if you searched for "CRA", it would get 0 results. Again, mind-blowing considering it was the recommended way to build apps with React.

Instead, it was replaced with a section driving you towards adopting Next. Which then had to be whittled away at and updated to include other options all the while the React team acted hostile to any criticism of it. You either used Next or you were shit out of luck.

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

My thoughts about CRA aside, you don't have to use the frameworks (I still don't). And if you remove Next from the equation, things are actually pretty cool. Suspense is cool, and you'll have to rip React Query from my cold, dead hands.

Dubious "regular expression denial of service" vulnerabilities seem like a general issue with the CVE bureaucracy lately. Like, maybe CVE-2020-10735 had a point that Python's default "int" type having unbounded size and a quadratic-time "str()" was a bit of a footgun, but now it's getting to a point where any use of backtracking in any context is just asking for a "high severity" ticket from the regex police.

When I want to memoize something slightly complex, for simplicity's sake let's say sorting an array of objects based on one of it's keys. I can put that in a useMemo and it won't sort it again when the page eventually rerenders for some reason.

Usually that array is mapped elsewhere and those child components might also re render if the array is recalculated.

useEffects are when I need to call something outside of react, or when the page gets mounted or I need to call a function when something changes.

I'm still fairly new to this, the above examples may scream bad architecture to those more experienced, all criticisms welcome :)

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

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

> Hooks are only 5 years old.

That is a long damn time in this industry, and class-based components still work just fine.

> all criticisms welcome :)

No criticism really. Your useMemo example is the right use. Your useEffect use is fine, but for things like api calls (which 'call something outside of react' may refer to), you're often better leaning on something like react-query, which is of course built on top of useEffect. So still the right tool, but let others handle many of the sharp edges around that problem.

I'm gonna be honest, I've been developing with react for about 9 years across a lot of projects and companies. I've never used next.

Maybe I'm out of touch, but I don't understand why people think it's so tightly could with the ecosystem

I preferred class based components. The pretend functional programming style of hooks is quite imperative when you prick a little beneath the surface, so classes were probably the right abstraction.

Unrelated to the topic, but wow, they're still using moment? I thought it was kind of deprecated and been trying to use other libs.

There is a large amount of what _might_ be described as astroturfing on the part of vercel to push Next. More charitably, vercel/the next community publishes a very large number of good tutorials/boilerplates/etc that are built on top of next.js.

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.

One of the projects I sometimes work on uses class components + mobx; it runs circles around hooks in speed/debuggability/convenience IMHO.

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

I think most of the complaints about moment are that it's really big (because of i18n and timezones). Obsidian isn't a web page/app, so it doesn't need to optimize bundle size too much.

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.

Most of your complaints are about things that are not React. Those are optional. I can still standup a vanilla React stack in an afternoon just as easily as I did 5 years ago and immediately start writing the exact same code and have it "just work".

The problem with classes that hooks helped with was how hard it was to add multiple, reusable bits of lifecycle functionality. In even a medium size codebase I'd find myself having to reason about how to combine behavior A with behavior B in the onComponentWillWhatever methods. Hooks are weird but much much easier to compose and share.

If you check the docs for how to create a react app the first thing they recommend is to use next.js.

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

Oh interesting - I haven't been on their starting page in years. I'm surprised getting started with vite isn't higher up. That takes 5 minutes and doesn't require a full framework.

That said, starting with react router or expo is probably the right call depending on the project needs. Routing is not something you want to do yourself, and react native is pretty unfriendly without expo

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

Thanks. I've started with rtk and saga hence the useEffect. I've since moved to rtk query.

It's unexpectedly mutable unless you've closely read the documentation, been bitten by the mutations, or are doing very simple date manipulations.

It's a great library, but it does need fewer footguns. date-fns is a good alternative.

> I can put that in a useMemo and it won't sort it again when the page eventually rerenders for some reason

useMemo dependency smell. This is almost always because your dependencies are wrong. This can often happen if you put a dependency as [object] instead of [object.field] due to how JavaScript maps objects to memory.