Почему вместо этого сообщения сразу его не задать?)

Понял прошу прощения

const countMemo = React.useMemo(() => ({current: 1}), []);
const countRef = React.useRef(1);
Есть ли разница в этих записях? Поведение как по мне никак не отличается

Разница между хуками принципиальная
Хотя бы в этом:

Вы можете использовать useMemo как оптимизацию производительности, а не как семантическую гарантию. В будущем React может решить «забыть» некоторые ранее мемоизированные значения и пересчитать их при следующем рендере, например, чтобы освободить память для компонентов вне области видимости экрана. Напишите свой код, чтобы он по-прежнему работал без useMemo, а затем добавьте его для оптимизации производительности.

То, что внутри работать это будет совершенно по-другому - тоже понятно
Плюс семантика

Мне нужно просто запомнить число и изменять его без рендера, и какой лучше использовать?

Способ

Я так понял useRef?

А зачем его запоминать если рендер не нужен. Можно вообще за пределами компонента хранить )

Да, если это действительно нужно

Так как лучше?😅

Клади в useRef. Я бред сказал в предыдущем сообщении )

если стоит задача понять фундаментальные основы и принципы работы приложений и фреймворков то могу посоветовать начать с основ - с методов создания и обновления дом-элементов  document.createElement(..), el.appendChild(..), el.style.someProp = ... (это должен знать каждый новичок) и дальше попробовать построить тодо-приложение. Можно начать примерно с такой организации стилей и компонент - https://github.com/bgnx/starter и дальше без всяких реактов уже можно строить приложения но потом самому увидеть или подумать над вопросом  какую проблему решает реакт и другие фрейморки (спойлер - производительность)  и как эту проблему можно решить проще без всяких фреймворков (например вот виртуал-дом хелпер в 22 строчки кода - https://codesandbox.io/s/simple-v-dom-todo-with-comments-fi3te?file=/index.js) и когда стоит применять сами фрейморки а также стейт-менеджеры

ого. Нет, производительность не первая проблема которую решает реакт )

+1, только хотел возмущаться по этому поводу

бывает с фреймворком приходится бороться за производительность 😂😂😂

Точечное обновление руками в любом случае быстрее любого virtual dom))

Ну откуда телега про производительность взята вполне понятно, и доля истины в этом строго говоря есть.
Но это не "зачем нужны фреймворки" а "зачем реакт а не скажем бэкбон эн лет назад"

Не согласен, я без реакта могу построить реальное приложение с таким же удобством разработки как на реакте - точно также декларативно разбивать верстку на компоненты и точно также хранить данные в состоянии и автоматически синхронизировать состояние с версткой (то есть это совсем не тот jquery-like подход когда народ хранил состояние в дом-элементах и синхронизировал все изменения данных с версткой вручную).
И какую тогда проблему спрашивается решает реакт если можно удобно разрабатывать приложения без него? А разница в том что реакт просто ускоряет тормоза браузерного дом-апи. Если на каждый рендер приложение будет собираться из компонент которые в свою очередь будут собирать верстку вызывая document.createElement() то это будет медленно на реальных приложениях а реакт решает эти тормоза тем что вызов document.createElement заменяется на React.createElement который создает легковестный js-объект (а эти объекты можно нагенерировать миллионы за секунду все жс движки оптимизированы под это) после чего рекурсивно сравнивает два дерева объектов и вносит в дом-дерево только те изменения которые отличаются.
То есть первая проблема которую решает реакт это оптимизация скорости создания/пересоздания верстки компонентов через механизм виртуал-дома. Если бы скорость создания дом-элемента через document.createElement не отличалась от скорости создания обычного жс-объекта то реакт был бы не нужен
Ну и собственно вот тут (https://github.com/bgnx/starter/compare/react) можно увидеть что я буквально заменяю только строку document.createElement() на React.createElement() в атомарных компонентах а все остальное приложение (которое уже может быть достаточно функциональным) остается без изменений