Comments 135
Ерундой не страдайте..
Учитывая, что типичный $mol разработчик перформит в несколько раз быстрее Реакт разраба, а если брать качественный код (насколько этот термин вообще применим к Реакту), то на порядок быстрее, - могу констатировать, что вы не владеете информацией. Помедитируйте над этим постом и не говорите глупостей.
Я 2 раза интересовался $mol, два раза у меня переставала работать документация, страница просто падала. Она на $mol ?
* это без иронии, мне действительно интересно - на каком этапе всё пошло не так. Спасибо)
Сколько разработчиков на $mol было оценено для получения профиля "типичного"?
Вопрос, ответ на который может реабилитировать мол (по крайней мере в моих глазах) - А есть посмотреть пример большого, поддерживаемого проекта на мол? Ну так чтоб бизнес логика какая-то внутри, пара лет развития и поддержки, новые фичи раз в несколько месяцев, баги правились, вот этот весь скучный энтерпрайз...
На реакте (с помощью next js) сейчас можно делать полноценный SSR. И плюсом, opt-in в CSR когда нужна сложная логика на фронте
Я помню, когда сайты делались на жиквере и была статичная верстка + ее оживление на js. Код был ужасным спагетти, даже в простых ситуациях были сотни граничных случаев, которые приходилось обрабатывать в ручную. Реакт очень много этой боли убирает. Если HTMX это решает, то ок. А так — осуждаю
Мы не говорим про то, что это единственное и правильное решение. Статья находиться в разделе «Мнения». Мы любим реакт, но против того, когда его пихают на простенькие сайты и веб-приложения. HTMX много боли решает, посмотрите их документацию, попробуйте написать простенькое приложение. Технология очень крутая их спонсоры гитхаб и джетбреинс, возможно это о чем-то говорит.
Мы даже написали небольшую библиотечку в основе которой HTMX
https://github.com/halt-stack/starter-kit
У вас точка отчета — это ПХП. То есть, когда вы думаете про сайт, вы думаете «вот есть ПХП, а все что сверху — это надо подумать надо ли». А у меня точка отчета реакт, я про ПХП вообще не думаю, даже не знаю его, я думаю сразу как на реакте сделать
Поэтому для меня вопроса «стоит ли пихать реакт, или разобраться силами ПХП» не стоит даже
Эта та самая система, в которой основной подход к программированию меняется так часто, что эту частоту перемен уже в пору мерять герцами?
Не смешите мои помидоры. Никто ничего не сказал про то, сколько это всё добро будет стоить в поддержке, когда у 8% всех пользователей на андроиде отвалится кнопочка "оплатить" и ловить этот баг будут всей командой целую неделю.
Иван, а у вас хорошее чувство юмора (я серьезно, хорошо шутите)
В какой то момент надо понять, что если ты не начнёшь шутить по поводу всей той каки, которая происходит с тобой в жизни, то тебе станет очень плохо.
Я считаю, что сохранил рассудок и очень позитивное отношение к жизни после 25 лет программирования именно потому что умел шутить по поводу всего этого. Поверьте, с 2000 года я насмотрелся на фреймворки и подходы, которые меняются каждые 2 недели. А история с кнопкой - это просто уже личный опыт.
Можно сколько угодно изливать желчь по этому поводу, но лучше смачно посмеяться. А когда вылезает очередная тема про самый лучший/худший фреймворк, то тут в пору звонить Куелачёву и Полунину одновременно: на сцене в комментах вам покажут трагикомичную клоунаду с элементами порнографии и заглатыванием котов целиком. Вы на месяц вперёд наберётесь аргументов для выигрыша в бесполезном споре и с большой вероятностью сможете даже переспорить нейросеть Жириновский.
В последний год слушал как все новые проекты все заводили на next js, при этом когда спрашивал, вам реально нужно кэширование и SSR? Оказалось, что 90% даже об этом не думали. И вот, буквально неделю назад, бывший джун уже со своей командой решил пилить новый проект, ну и конечно кто-то решил взять next, я попросил их взять день на раздумье, почитать про next, сравнить с другими подходами, и они свою админку для внутреннего использования решили пилить на ангуляре (так как была экспертиза, а на next никто никогда ничего не писал).
Поэтому, если можно решить ваши задачи с помощью более простого рендеринга на сервере, мы применяем именно его.
Тут есть неявное предположение - вы великолепно понимаете их задачи. React как-то более future proof выглядит.
Господа гусары,
Никто не говорит Flutter.
Может вы просто не умеете быстро и хорошо писать на реакте том же?!
А вы умеете? За сколько сможете хорошо реализовать, например, такое не хитрое приложение?
и что там должно быть? тупо черный экран
Поздравляю, вы нашли багу. Так за сколько вы на Реакте запилите без багов ну или хотя бы без тормозов?
Неужели разработка на Реакте такая непредсказуемая, что даже дать оценку времени разработки такая проблема? Я же даже не прошу это реализовать, хотя функциональности там с гулькин нос (поиск с подсветкой, меню с фильтрацией, экспорт в csv). Или давать оценки трудозатрат в приличном обществе не принято?
Ну если я правильно понял что это просто список с тремя полями и фильтрацией.... ну за вечер. Скажем часа четыре по ставке 50$ в час. Это если с бакендом но без деплоя. (Но для вас ставка х4, потому что вы очевидно токсичный клиент).
Ток оно у вас багованое: на мобиле фличерит, в старой опере не запускается, прокрутка странная. Так что если баги повторять то плюс неделя, надож разобраться как вам это удалось.
(Зря вы конечно это принесли, я раньше думал что мол просто эзотерическая технология имеющая право на жизнь, теперь думаю что это эзотерическая хтонь на которой даже ее создатель не умеет писать)
Это если с бэкендом, без него и за часа два можно, из которых процентов 60 уйдет на верстку в соответствии с тем, что в том тестовом приложении....
Да там не нужен бэкенд - просто статичный json показывать. Вёрстка любая опрятная адаптивная. Баги повторять не нужно, свои тоже не надо изобретать. Про подсветку найденного, экспорт, навигацию не забыли? Ну и тормозить на большом списке не должно.
У вас же нет большого списка? Там менее 800 записей за два года. Из них полезных десять штук, из них актуальных примерно две.
Чем хорош реакт там под каждую стандартную задачу есть готовый отлаженный компонент. Нетормозящих виртуальный скроллов десятки готовых: https://coreui.io/react/docs/components/virtual-scroller/
При этом они отлажены, нефличирят, не тормозят и не ведут себя странно (ваш - ведет), у него маркер прокрутки отстает от мышки, причем сильно, в результате чтобы прокрутить всю страницу надо вверх-вниз елозить мышью. Понимаю, фича.
Ну раз бакенд не нужен то держите, 37 минут во время обеда. (Думал в полчаса уложусь, но нет, верстка и хайлайт сожрали прилично времени)
Код:
Hidden text
import React, { useLayoutEffect, useState } from 'react';
import { FixedSizeList } from 'react-window';
import TextField from '@mui/material/TextField';
import Drawer from '@mui/material/Drawer';
import ListItem from '@mui/material/ListItem';
import { debounce } from 'lodash';
import Box from '@mui/material/Box';
import Typography from '@mui/material/Typography';
import ListSubheader from '@mui/material/ListSubheader';
import List from '@mui/material/List';
import ListItemButton from '@mui/material/ListItemButton';
type Item = {
title: string;
text: string;
category: string;
};
const categories = ['react', 'angular', 'vue', 'mol'];
const generateRandomItem = (id: number): Item => {
const randomCategory = categories[Math.floor(Math.random() * categories.length)];
return {
title: `Item ${id} - ${randomCategory}`,
text: `Description of item ${id} in category ${randomCategory}`,
category: randomCategory,
};
};
const generateRandomItems = (count: number): Item[] => {
return Array.from({ length: count }, (_, index) => generateRandomItem(index + 1));
};
const App: React.FC = () => {
const [filter, setFilter] = useState<string>('');
const [selectedCategory, setSelectedCategory] = useState<string | null>(null);
const [items, setItems] = useState<Item[]>(generateRandomItems(10000));
const [listHeight, setListHeight] = useState<number>(500);
useLayoutEffect(() => {
const updateListHeight = () => {
setListHeight(window.innerHeight - 160);
};
updateListHeight();
window.addEventListener('resize', updateListHeight);
return () => window.removeEventListener('resize', updateListHeight);
}, []);
const filteredItems = items.filter((item) =>
(item.title.toLowerCase().includes(filter.toLowerCase()) ||
item.text.toLowerCase().includes(filter.toLowerCase())) &&
(selectedCategory === null || item.category === selectedCategory)
);
const handleFilterChange = debounce((event: React.ChangeEvent<HTMLInputElement>) => {
setFilter(event.target.value);
}, 250);
const handleCategoryClick = (category: string) => {
setSelectedCategory(category);
};
const highlightMatch = (text: string, match: string) => {
if (!match.trim()) {
return text;
}
const regex = new RegExp(`(${match})`, 'gi');
return text.split(regex).map((part, index) =>
regex.test(part) ? (
<span key={index} style={{ backgroundColor: 'yellow' }}>
{part}
</span>
) : (
part
)
);
};
return (
<Box sx={{ display: 'flex' }}>
<Drawer
variant="permanent"
sx={{
width: 300,
flexShrink: 0,
'& .MuiDrawer-paper': {
width: 300,
boxSizing: 'border-box',
},
}}
>
<List
subheader={
<ListSubheader component="div" id="nested-list-subheader">
Categories
</ListSubheader>
}
>
{categories.map((category) => (
<ListItemButton
key={category}
selected={selectedCategory === category}
onClick={() => handleCategoryClick(category)}
>
{category}
</ListItemButton>
))}
</List>
</Drawer>
<Box component="main" sx={{ flexGrow: 1, p: 3 }}>
<TextField
label="Filter"
variant="outlined"
onChange={handleFilterChange}
sx={{ mb: 2 }}
/>
<FixedSizeList
width="100%"
height={listHeight}
itemCount={filteredItems.length}
itemSize={70}
>
{({ index, style }) => (
<ListItem style={style} key={index}>
<Box>
<Typography variant="h6">
{highlightMatch(filteredItems[index].title, filter)}
</Typography>
<Typography variant="body2">
{highlightMatch(filteredItems[index].text, filter)}
</Typography>
<Typography variant="caption">
{filteredItems[index].category}
</Typography>
</Box>
</ListItem>
)}
</FixedSizeList>
</Box>
</Box>
);
};
export default App;Картинка:
Hidden text
На планшете в хроме сайт не осиоил смасштабироваться по ширине и добавил горизонтальную прокрутку.
Вот вроде и идея неплохая, но предлагать не пользоваться плеером из-за того что разработчики из украины и есть баннер с просьбой поддержки, или не играть в хогвартс легаси из-за того что нет русского языка... Нутакое
Хороший рекомендательный сервис адекватных компаний сделали, спасибо за вашу работу. Я вот только не понял почему в названии "toxic", это такая ирония?
Я не фронтенд разработчик (хотя по комментариям понятно что ваш mol - УГ), поэтому вопрос не в тему. Зачем вы собираете данный список (еле открыл его, работает странно конечно)? Так, конечно, спасибо за работу по составлению данного списка, приятно удивлен что некоторыми пользуюсь, значит надо будет продолжать. И еще вопрос. Вы сами теперь не используете софт из данного «токсичного» списка?
Спасибо за ваше мнение и предположение. Скорее всего у вас другой опыт и взгляд на эту ситуацию, мы запустили более 60 проектов и нам есть с чем сравнить.
При этом мы можем быть не правы и иногда стоит советоваться с вами.
60 проектов - это ни о чем вообще, на проекте, на котором работаю, только микрофронтендеровских приложений в несколько раз больше.
Так что вполне допускаю, что для 5-10 страничных сайтов или лендингов это вполне применимо, вот когда проект вырастет до размеров энтерпрайза, тогда всё равно придется переписывать, но уже гораааздо больше и за совсем другие деньги.
Взять хотя бы https://zoobizoo.ru/, что Вы сами в тексте привели. Вы его тестировали на слабом 3G? Вы отдаете себе отчет, что нажав на рубрику в каталоге 5 (ПЯТЬ!!!) секунд ничего не происходит вообще???! Без ограничения задержка значительно меньше, но всё равно ощутима. Я, конечно, извиняюсь, но это мало похоже на взрослый сайт в 2024 году...
Статья пересекается с https://vas3k.blog/notes/indie_vs_corpo/#small-korporat.
Тоже мне новость. Половина годных Хабровских статей приходит на Хабру с Вастрика, просто потому что там очень жёсткие правила модерации, и никто не позволяет развонить ботнеты для накрутки голосов и плюсиков. Более того, их система рейтингов позволяет посту бесконечно много раз выходить в топ.
Там просто писать приятнее, удобнее и веселее, хотя тебе за это не платят, а как раз наоборот.
Я уже не раз говорил, что Хабра, если не возьмётся серьёзно за модерацию постов, свалится чёрт знает куда. Что, собственно говоря и происходит.
А 1 человеко-месяц react+nodejs разработчика стоит столько же как htmx+python/lavarel?
Первых сейчас пруд-пруди любых уровней, а где вы берете вторых в нужном количестве, взращиваете сами, а потом удерживаете зарплатой в +20% к рынку?
Они удерживают потом заказчика: найти тех, кто потом будет это саппортить, гораздо труднее, чем тот же react+nodejs. Неплохая бизнес-модель, пока заказчик не захотел переписать на что-то более распространенное.
htmx элементарная технология, фронтендер миддл+ сможет в ней разобраться за 1 день, почитайте документацию
Я в курсе, что такое htmx и с чем его едят. Я же о проектах, а не о технологии. Какой-нибудь проект на 1М+ LOC, не верстки, во много раз будет проще поддерживать на том же реакт или вью, а вновь нанятым сотрудникам не надо учить новую технологию. Старт, возможно, будет дешевле на htmx, всё остальное будет дороже.
ИМХО, главный плюс технологии htmx в том, что в ней за день разберётся и бэкендер миддл+.
А писали бы на PHP -- понадобилось бы несколько школьников плюс пара ящиков дошика.
Как не знающему почти ничего про web-программирование, мне до сих пор непонятно, почему рендерить (вплоть до пискельной картинки, которую видит пользователь?) на сервере лучше. Умный клиент на то и умный, чтобы снять часть нагрузки с сервера. Не спорю, но выражаю "непонятки", которые статья не прояснила.
В контексте веба слово «рендерить» означает не вывод непосредственно картинки, а генерация HTML-разметки.
Но чем лучше-то?
Снижает нагрузку с клиента. Не нужно лишний код на клиенте хранить.
Хранить? На современном РС трудно хранить и исполнять JavaScript и прочее? Серьёзно? Вв не помогли развеять непонятки)
А на современном сервере отрендерить HTML вместо JSON сильно трудней?
Не все клиенты это PC (да и те не все современные). Мобилок становится всё больше (при чём не сильно мощных). А эти данные ещё и передать надо, что увеличивает скорость загрузки страницы (а интернет ещё не везде быстрый). И далеко не все клиенты зайдут дальше главной страницы. И вот для чего им эти лишние мегабайты себе грузить?
Вся идея толстого клиента в сокращении трафика и cpu затрат на сервере за счёт ресурсов клиента. А тут получается наоборот. Какой-то неправильный протокол и вообще эта технология)
Вся идея толстого клиента в сокращении трафика и cpu затрат на сервере за счёт ресурсов клиента.
Это вы сами так решили?
Ну и на сколько сокращаются затраты на CPU? И откуда экономия по трафику, если клиент увидит только стартовую страницу (если ещё дождётся) и закроет (ваш жирный бандл будет бесполезен)?
Статику вам отдавать в любом случае придётся, но в одном случае - только необходимую. А данные отдавать в любом случае придётся, и вот тут затраты на CPU будут посущественней, чем на генерацию HTML вместо JSON.
Какой-то неправильный протокол и вообще эта технология)
Что за протокол и почему он неправильный?
Как вы можете об этом судить, если почти ничего не знаете про веб-программирование?
Определение толстого клиента - это взятие части работы с сервера на клиент. И чем выше уровень общения (например, не пиксельная картинка, а геометрические объекты или бизнес-объекты), тем меньше трафик и нагрузка на сервер. Это просто определение. И если какой-то протокол приводит к обратному, то это неправильный протокол.
Ну, что такое, по вашему, рендеринг?
Грубо скажем, рендеринг это отрисовка страницы.
Когда у вас CSR, вы отдаёте клиенту пустой html. Он вызывает какой-то набор CSS и js. Они вызывают картинки, шрифты, получение каких-то данных от API.
Следовательно вы нагружаете сервер на открытие коннекта под каждый фаил, на всевозможные выборки из БД. Вы тратите время на сетевую передачу. Плюс этот код собственно собирается у клиента.
Как вы думаете, что рендерят все эти люди? Какое-то уникальное, кастомизированное веб приложение или в большинстве случаев это одно и тоже?
Следовательно возникает вопрос - а нафига делать кучу раз то, что можно сделать 1 раз?
На этот вопрос возникает примерно 2 родственных ответа - SSG и SSR.
SSG говорит "возьми все файлы, собери из них готовый HTML и отдай клиенту". Подход особенно хорош, если нет динамики.
SSR делает примерно тоже самое, но обычно там добавляется всё же какие-то запросы к бекенду. Вот, собственно, сервер идёт 1 раз к бекенду, собирает в приложение все возможные запросы (ну, кроме прямых) и точно так же отдаёт потом готовый HTML файл.
Ну, конечно, я упрощаю очень сильно, не вдаюсь в синхронизацию состояний и всё такое, но в любом случае мы занимаем меньше ресурсов на рендеринг (по сути делаем это 1 раз), тратим меньше ресурсов на открытие соединений, передаём меньший объём данных.
Ну так собери все нужные файлы и запроси все данные из бэкенда, собери все это а сжатый архив и передай клиенту, и пусть он собирает html, исполняет скрипты, рендерит и прочее. Не?
Мы тоже так думали, пока не добрались до оптимизаций и метрик CWV.
Нет конечно. Начнём с того, что клиент, он очень разный. Большая часть клиентов, это вам не люди, у который системник с 32 ядрами и 4090, с воткнутой напрямую гигабитной оптикой. Большинство ваших клиентов, это даже не люди с ноутбуками на приличном железе, сидящими под дождём из Wi-Fi 6E.
Абсолютное большинство ваших клиентов, это люди, с бюджетными и среднебюджетными смартфонами, часто не первой свежести. Или с ноутом на i3 десятилетней давности. Или на маке Late 2012, таких тоже полно.
Следовательно первые с вами взаимодействуют далеко не всегда через 5G. Вообще в реальности чаще всего ваши клиенты, это 3G или не очень стабильный LTE, с полосой пропускания, которая скачет ну в районе 4 МБс.
А вам, я напомню, надо передать бандл, ну пусть даже 10 мб, если сайт простенький, а скорее это 60 мб.
Т.е. клиент должен сделать первую серию запросов, установить соединение, обменяться ключами, начать шифровать и дешифровать траффик. Дальше он должен получить ваш архив, дешифровать его, собрать чанки в кучу, распаковать, а потом отрисовать DOM на вашем экране, а потом ещё исполнять байт-код js в реальном времени.
А вас ведь тоже не всё и всегда статично, верно? Может меняться. Вот при гидрации вы отдаёте чанки, а в вашем случае вы что будете отдавать? Новый архив? Или инкремент архива? Или что? Т.е. вам надо делать всё тоже самое, только вы предлагаете делать это менее удачным способом.
Я уж не лезу в дебри того, что js бывают разные и не все с вашего источника.
Ваш клиент будет вас ненавидеть и перестанет пользоваться.
Да, конечно, для мобилок более толковый вариант это приложение, где уже скачана большая часть ассетов, надо бегать только с json к бекенду и можно пушить изменения частями, но тут сорян, мир он такой, какой есть.
Я ещё в 2007 году уходил от SSR через собственный движок типа Angular, поскольку требовалось рендерить куски страницы, а не всю целиком. Что теперь уходим в 2000 год, Active Server Page??
Проще взять Remix, Nuxt, Next, чем заниматься такими велосипедами.
Призыв выкинуть реакт и юзать htmx - поддерживаю. А вот противопоставление SSR и CSR - это ерунда какая-то. Одно другому не мешает и никак не противоречит. Можно использовать гибридный подход, как все нормальные люди сейчас и делают.
А можно просто взять обычный php и будет тотже сераерный ренлеринг
Осрбенно если речь идет о статическом контенте.
@maximwhere
Если вы умеете в Го, я порекомендую супер мощное комбо под названием Templ go + Htmx тогда
https://github.com/a-h/templ
Это классная библиотека статик типизированного теймплатирования нашего Html, с удобный написанием и html и css, и использованием golang кода в ходе этих функций.
По сути это... очень сильно смахивает на JSX реакта, но только в данной ситуации это обычная библиотека именно теймплатирования нормально работающая с сервер сайда (и удобная в том числе для статик сайт генераторов)
Шикарно как раз и работает с Htmx
P.S. меня терзают сожаления что этого нету в иных "бэкендовских" языках. Такая прекрасная штука.
Нечто похожее на мой взгляд предлагает ElysiaJS, где можно писать JSX, который будет рендериться на сервере
Но не пробовал Templ go, могу ошибаться ?
А оно динамически может работать с DOM? Немного почитал Доку если это просто генератор старики то как бы Окээй, но go для такого немножечко как бы овер инжиниринг для среднестатистического веб разработчика.
А я вот не понял, чем реакт так уж плох?
Так-то можно и на голом html + css творить или к php откатится. Благо там не с разработчиками не с кодом проблем нет. И думаю по дешевле по производительнее всего будет. CSR же помимо всяких анимашек и т.д разгружает сервер, в бэке достаточно отдать порцию сырых данных, а там уже пусть клиентское устройство разбирается, как все это рендерить.
И в принципе это не плохо. А сам реакт, ну что, html на стероидах, в разработке удобно. А основные затраты времени все равно будут на верстку, а не на сам react. Зато поддерживаемая история в которой мухи отдельно, котлеты отдельно.
В итоге получается так, что можно сэкономить и на серверах и на поддержке проекта. По времени и по цене разработки плюс минус одно и тоже. Разработчиков node + react, как выше заметили, тоже предостаточно. И на этом, подозреваю, тоже можно сэкономить.
В общем я не критикую, но влазить в SSR я бы не стал.
Хм. Сложилось впечатление, что у автора недолюбит к JavaScript) Думаю, большинство предпочтет рендерить на клиентской стороне.)) у js сейчас куча возможностей. Он диветч развивается и прекрасно себя чувствует. Так что да, к отдельных моментах возможно использовать сторону сервера. Но не в большинстве.
Переизобрели pjax
А так, ребят, если б хорошо знали Laravel, то юзали бы livewire, или inertia
Пример — рендеринг на сервере в браузере или на стороне клиента.
Вы сами поняли?
Ещё можно от эффективных менеджеров отказаться и тоже нехило сэкономить
Серверный рендеринг — маст‑хэв для бизнесов, которые хотят запуститься быстро. Секрет высокой скорости — более простой код и меньшее количество багов.
Вау. А где связь?
Статья о том, как лендинги на реакте - это оверхед и админки для сбора звонков перестали покупать в вашей веб-студии?
В целом, рендеринг на сервере — идеальный вариант для проектов со статичным контентом. Как правило, на подобных сайтах возможности React и Vue не используют на полную мощность. Получается, заказчик переплачивает за CSR там, где можно сэкономить.
для статики есть ssg, ssr тут не нужен.
Реакт и вью используют не потому, что они "мощщщные", этот аргумент вообще безоснователен в рамках всей статьи в целом.
У нас нет цели взять как можно больше денег — и ради этого посадить дорогостоящих специалистов отрабатывать часы
Верю. У вас есть цель взять как можно больше денег, продав время работы джунов как сеньорское, потом написать статью как вы не смогли в <имя_технологии> и налить водички, корявенько себя порекламив, т.к. пройдя даже по сайту, который вы привели в качестве примера, и без профилирования виден layout shift, и как уже после загрузки страницы даже с кешем к кнопкам применяется css :)
Успехов вам, в любом случае.
Все зависит от прямоты рук и откуда они растут. А не ваши вот эти непонятные сравненения.
Если разработка сервиса ZooBiZoo обходилась клиенту в 700 тысяч в месяц, то мне, если честно, всеравно на чем он был написан.. Я просто склоняю голову перед тем, кто сумел продать такую залепку за такие деньги... ...и это же не один месяц получается....
Раз уж мне тут слили карму, и я не имею возможности отвечать на каждый вопрос отдельно, то держите меншены:
@sumdy-c Да, у нас всё на $mol. А "падала" - это что конкретно происходило?
@Metotron0 Я оцениваю по паре десятков разработчиков самой разной квалификации.
@Aniro Бизнес логика на $mol занимает не так уж много места. Самый крупный проект, наверно, портал самого фреймворка (https://mol.hyoo.ru/), куда мы засунули десяток "микрофронтов" и распределённую субд. Надо бы ещё студию (https://studio.hyoo.ru/) туда заэмбедить, а то она пока живёт отдельно.
@Egor3f Обычно сначала пара недель нужна, чтобы пройти все стадии принятия, а потом в мозгах что-то щёлкает и человек понимает, почему всё сделано именно так, и почему нельзя было иначе. После этого возвращаться на Реакт очень больно - поэтому уже есть много проектов от разных людей, по реализации хоть какого-то подобия для него, чтобы не так сильно страдать в рабстве у капиталистов.
@PrinceKorwin Багрепорты без версий хрома и "простого андроида" довольно бесполезны. Не могу знать, что у вас пошло не так. Обидно, прекрасно понимаю. У моей мамы на "просто андроид" мобильные приложения от Тинькова вообще не ставятся. А веб версия написанная на Реакт настолько тормозит, что пользоваться этим просто не возможно. Тем не менее, обещаю направить все заработанные с лично вас 0 рублей на улучшение поддержки "просто андроида". Я же не многомиллионная корпорация с многотысячным штатом. Мне не сложно.
@n0ne Спасибо за багрепорт, это была несовместимость с гридами. Завтра раскатится на все приложения. Теперь не мерцает?
@Aniro Скроллбар отстаёт по простой причине: высоты элементов не известны до рендеринга, поэтому для резервирования пространства используется сильно приблизительная оценка. Можете взять ваш распрекрасный виртуальный скроллер стоимостью по 10килорублей на разработчика и засунуть в него строки с разным количеством контента. Результат вас неприятно удивит. Я подробно рассказывал об этом всём в этом выступлении: https://mol.hyoo.ru/#!section=docs/=gjboo1_xhyrnq
Ну а то, что вы наваяли за 37 минут.. Я правильно понимаю, что вы это считаете образцом хорошего кода, который не стыдно выпустить в прод? Ползователь точно будет счастлив получить захардкоженный фейковый контент и вырвиглазный дизайн на незнакомом языке без возможности поделиться ссылкой на результат фильтрации и скачать его в виде таблички?
@Dolios Вообще, это концепция буклетного дизайна (https://mol.hyoo.ru/#!section=docs/=xthcpx_wqmiba), так что обрезание и скрытие дополнительных страниц - неизбежное ограничение доступного на экране пространства. Обратите внимание, что основная страница влезает в любой экран.
@green_fenix Это информационное приложение. Что делать с этой информацией вы решаете сами. Но лично я бы не стал пользоваться софтом, разработчики которого подвержены массовой истерии, под влиянием которой они могут наделать мне неприятностей. И лицезрение баннера - самая малая из них. Покупать игру, не переведённую на мой язык, я бы тоже не стал.
@Sigest Эту базу данных составлял не я, а русскоязычное сообщество, которое столкнулось с токсичным поведением некоторых слабых на голову разработчиков.
Концы веток обсуждений ищите сами. Вы же этого добивались, @Boomburum?
Это информационное приложение. Что делать с этой информацией вы решаете сами.
Может тогда стоит воздержаться от фраз вроде "Лучше не пользоваться этим плеером"?
Вообще, это концепция буклетного дизайна (https://mol.hyoo.ru/#!section=docs/=xthcpx_wqmiba), так что обрезание и скрытие дополнительных страниц - неизбежное ограничение доступного на экране пространства. Обратите внимание, что основная страница влезает в любой экран.
Слева слова меню все обрезаны посередине были и присутствовал горизонтальный скролл. На 10" планшете с разрешением 2к по горизонтали. Если это концепция такая, то я её не очень понимаю.
Раз уж мне тут слили карму
За агрессивное навязывание своего фреймворка по любому поводу и без. Но вы решили продолжить...
Концы веток обсуждений ищите сами.
Уже бегу!
Карму, молодой человек, Вы слили, фактически, себе сами своим агрессивным и безапелляционным поведением и манерой общаться. Избрали бы другую форму общения, то возможно, подчеркиваю, возможно, у $mol появился хоть какой-то шанс. На данный момент всё очень печально: сайт - ужасен, чудовищно ужасен, документация - недалеко ушла от сайта. Никто в здравом уме, кроме самих авторов, пользоваться этим не будет. Откройте рядом два окна с документацией по $mol и хотя бы упоминающийся тут htmx: невразумительный вырвиглаз в сравнении с лаконичной простотой. Про документацию реакта или вью вообще молчу. Выбор очевиден.
P.S. честно хотел дать шанс: поиск по сайту 'graphql' дал ровно ничего. Теперь вообще без шансов.
P.P.S. Вот, блин, Вы на полном серьезе считаете ЭТО серьезным продуктом, если я открываю сайт "фреймворка" и вижу вот что:
Ну а то, что вы наваяли за 37 минут.. Я правильно понимаю, что вы это считаете образцом хорошего кода, который не стыдно выпустить в прод? Ползователь точно будет счастлив получить
Нет конечно, это не продакшин код, но он лучше вашего "продакт решения" - он не глючит. Пользователь будет счастлив получить работающее решение, выполняющее его задачу, так ведь?
В общемто для этой задачи, даже в таком виде решение удовлетворительное - оно работает, оно поддерживаемое. А в одну страницу оно ради того чтобы выложить под спойлер на хабре. Сколько вы думаете займет разбить его красиво на несколько файлов если надо, и напихать ссылок на телеграм, как у вас?
А да, еще выгрузка в csv, как я мог забыть - сделать вам ее за пять минут, или так поверите?
Так-то по честному функции этого "приложения" лучше всего выполнил бы просто опубликованый текстовый документ, раз уж вы его все равно руками редактируете. Серьезно. Плюсик ведущий на телеграмм вместо формы добавления в вашем "продакшин реди" приложении потряс меня до глубины души конечно, я когда первую оценку давал, предпологал что он форму добавления записи открывает, а где-то там еще админка прячется.
Можете взять ваш распрекрасный виртуальный скроллер стоимостью по 10килорублей на разработчика и засунуть в него строки с разным количеством контента.
Вот только требования на лету менять не надо. Сказано было - "Любой аккуратный дизайн, не тормозящее". Выбрано было решение оптимальное требованиям. Так-то в react-windows есть не только FixedSizeList, можно легким движением клавиатуры заменить его на List и добавлять туда все что угодно. Но пихать в виртуальный скролл элементы разных размеров без острой необходимости - дурная фантазия. Вон у вас оно приводит к проблемам со скролом, а ведь необходимости нет, дизайнеру настучать по ручкам чтоб так не делал.
Результат вас неприятно удивит.
Я вас умоляю, что там может удивить. Я этих листов наклепал за карьеру десятки штук, включая отображение импортированных таблиц на 100к строк и 100 столбцов с адаптирующимися под контент ячейками или отображение дереревьев на 1кк нод во времена ие7 и что я вам скажу - реакт некритично отстает от очень хорошего ванильного кода по производительности, но при этом сильно ускоряет работу. (Это если вы умеете готовить и то и другое) Но понятно, что оптимизированный ванильный код будет всегда быстрее чем любой фреймворк, по очевидным причинам.
Вообще это ваше "приложение" - выглядит как задача на неделю для разбора на курсах для вайтишников которые вообще не бум-бум или один стори поинт в этерпрайзе. Что вы ожидали, что вам скажут что ее на реакте две недели делать?
хром 122.0.6261.112.
захожу по https://mol.hyoo.ru/
прожимаю "энциклопедия"
по центру появляется контент с кнопками с выпадающим меню.
начинаю раскрывать пункты меню и подпункты - моргает экран.
в реакте такое обычно, когда 1 suspense на всю прилагу(условно)
Круто что вы правите баги. Зашел на портал, потыкал разедлы. Скролл ужасен везде, поправьте. Я как пользователь хочу чтобы если я прокручиваю скролл до конца, я попадал в конец списка. У вас же чтобы до конца докрутить нужны нехилые услилия. Это же не рокет сайнс. (пардон, не в ту ветку ответил - это для @nin-jin)
@green_fenix Это UGC.
@Dolios я вам ссылку для того и дал, чтобы вы что-то поняли.
@n0ne Вот если бы вы думали головой, оценивая технологии, а не эмоциями, то знали бы, что GraphQL - та ещё хрень. Подробнее я рассказывал тут: https://page.hyoo.ru/#!=uhgyst_zfa8t3 и тут ещё есть немного: https://github.com/nin-jin/HabHub/issues/21
@Aniro Вопрос был не в том, чтобы наговнякать на коленке сомнительную демку, а в том, сколько времени у вас займёт сделать полноценную поддеживаемую альтернативу на Реакте. На Vue (https://toxic-repos.ru/) ребята мучались минимум несколько дней. Но я верю, что вы справитесь быстрее. Так за сколько? Когда же мы услышим заветный эстимейт?
Если вы сделаете все строки одинакового размера (как и сделали ребята на Vue), то получите косяки двух видов: в ряде строк большие дырки, а в ряде вложенные скроллы. Очень странно, что столь опытный в виртуализации разработчик, этого не понимает.
А я, как автор текстов, хочу, чтобы вы их читали с начала, а не проматывали сразу в самый конец. Так что завязывайте теребонькать скроллбар и возьмитесь за ум. Например, почитайте про scroll anchoring, зачем он нужен, и как влияет на позицию скроллбара.
@Gary_Ihar прям весь экран моргает? Звучит очень странно. Можно скрин? Есть ли какие ошибки в консоли?
Вопрос был не в том, чтобы наговнякать на коленке сомнительную демку, а в том, сколько времени у вас займёт сделать полноценную поддеживаемую альтернативу на Реакте. На Vue (https://toxic-repos.ru/) ребята мучались минимум несколько дней. Но я верю, что вы справитесь быстрее. Так за сколько? Когда же мы услышим заветный эстимейт?
Ну так вы озвучьте требования нормально. Пока я вижу примерно три дополнительные хотелки - экспорт в csv, прикуртить роутер чтобы была ссылка на раздел и фильтр, и нескучный дизайн, на каждую из которых мне надо не более ~10 минут. Из них самая сложная сделать дизайн, что к фреймворку вообще не имеет отношения. Накинем 10 минут на непредвиденные обстоятельства, итого 80 минут суммарно.
Фишка в том, что в данном случае демка адекватна задаче. Для этого приложения ничего другого и не требуется. Оно работает. Оно работает хорошо. Оно поддерживаемо любым реакт джуном. Когда надо будет функционал наростить, оно за те-же полчаса переделывается во что-то большее.
Посмотрел https://toxic-repos.ru/ - оценка таже. Ну если выкинуть из моего решения mui и написать с нуля все визуальные компоненты и стили - два часа. Я честно не понимаю чего вы хотите доказать. Это очень простая задача, практически ноубрейнер, он фигарится просто без включения мозга неприрывным набором на клавиатуре. В ней нет ничего, что может вызвать затруднения, вообще.
P.s. Нашел еще функционала - переключатель между светлой и темной темой, еще +1 минута на переключатель и 10 минут прописать стили. Еще что-то?
Казалось бы, опытный профессионал должен знать базовую функциональность любого приложения, о которой даже упоминать неприлично.. Ну да ладно, держите полное ТЗ:
Сервер выдаёт вам JSON с данными - их все надо показать пользователю.
Реализация сервера - не ваша забота, мы говорим про фронтенд.
Ответ сервера валидируется и нормализуется. В частности, дата показывается в удобном для пользователя виде.
Данные выводятся отсортированными по дате (свежие сверху).
Есть опциональный фильтр по категориям.
Есть полнотекстовый поиск по контенту.
Найденные вхождения подсвечиваются.
В тексте как минимум распознаются ссылки, а как максимум - поддерживается маркдаун.
Нет уязвимостей типа XSS.
Нафильтрованный список можно выгрузить в CSV.
Нафильтрованным списком можно поделится через ссылку.
История переходов работает корректно.
Интерфейс поддерживает локализацию.
На время загрузки данных показывается индикатор ожидания там, где ожидаются данные.
В случае ошибки загрузки показывается ошибка там, где ожидались данные.
Вёрстка удовлетворяет базовым требованиям доступности: адаптируется к размеру экрана, освещённости, типу устройства ввода.
Дизайн опрятный (всё выровнено по направляющим, соблюдается ритм).
Цвета достаточно контрастные (в соответствии с a11y), но не вырвиглазные.
Грузиться всё быстро (не дольше пары секунд полная загрузка).
Работает всё отзывчиво (задержки не заметны на глаз, скроллинг не лагает и тд).
Лайтхаус показывает зелёные результаты (90+) по всем критериям даже в мобильном режиме.
Код хорошо структурирован и разложен по файлам (не лапшой в одном файле).
Код соответствует лучшим практикам используемого фреймворка.
Код легко поддерживать, отлаживать, улучшать и расширять.
Код статически типизирован, в том числе композиция компонент и стили.
Настроен пайплайн автоматической сборки и деплоя при пуше.
Подведём промежуточный итог, чего из этого вы уже добились:
Есть фильтр по категориям, но он не опциональный.
Есть полнотекстовый поиск по контенту.
Найденные вхождения подсвечиваются.
На это вы потратили 40 минут, написав 150 строк кода и получив бандл размером не менее 140КБ в ужатопережатом виде. Всё остальное вы планируете сделать за оставшиеся 80 минут? Пожелаю вам успехов и крепкого здоровья.
Для сравнения, реализация на $mol, которая удовлетворяет всем требованиям занимает 230 строк кода, выдавая при этом бандл в 63КБ даже без минификации. От идеи до прода оно прошло за 2 часа, не спеша, во время завтрака.
Это UGC.
Хорошо, вопрос снимается. Хотя конечно лучше добавить гайдлайны в форму добавления, что стоит воздержаться от подобных изречений.
Вы специально туда фото под полупрозрачный фон поставили, чтобы читать было тяжело?
К слову про скролл, вот это на ваш взгляд нормально?
Если бы Вы вообще бы хотя бы иногда думали, то возможно когда-то пришли бы к выводу, что есть инструменты, которые решают определенные задачи, а не "во всех бочках затычки". Если не умеете пользоваться каким-то инструментом, это не значит что он плохой. База.
Во-вторых, Вы - САМАЯ худшая реклама и без того убогого $mol. Никто в здравом уме не станет использовать эту поделку после прочитанного здесь.
Ну и в-третьих, Ваше "экспертное" мнение самым прямым образом нашло отражение в слитой карме. Вам бы стоило задуматься, но не судьба, видимо.
Хотел написать под прошлой публикацией про кроссовки, но там уже нельзя. Делали его дизайн (до вас), разработчик не от нас, жаль что дальше все умерло. Как-то грустно стало, когда выпускали в тестфлае его, потому что даже с точки зрения UI это было уже не совсем то
Странно, что ноду хоронят не те люди, которые ей пользуются, а те, которые ей не пользуются, и, следовательно, не знают, почему её выбрали те, кто пользуются. Вернее, они, может, и знают, но для них это не существенно. Однако те, кто всё же взял ноду, видимо, по-другому не могут, или для них это слишком напряжно. Давайте ещё всех с автоматических коробок передач пересадим на механические, ведь так в теории можно экономить бензин. Правда, придётся открывать школы эффективного вождения и загонять туда людей, тратя их время и деньги, но кого же это волнует?
Да, есть айтишники, которым нужно просто сделать, чтобы работало, не упарываясь в производительность. Не все занимаются хайлоадом. Обучиться новому языку с новым фреймворком иногда дороже, чем просто скопипастить готовое решение. Пусть даже кому-то оно кажется шурупом с молотком.
querySelector — это не аналог $(), аналогом будет что-то вроде Array.from(element.querySelectorAll()), где в роли element может быть document. Но я предполагаю, что дальше идёт не .each() с обработкой DOM-элементов, а другие функции jQuery, которые, конечно, можно реализовать на чистом JS, но телодвижений больше. А если jQuery уже подключен ради чего-нибудь, то почему бы им не воспользоваться? У нас бэкендеры в каждый сайт на битриксе его суют, поэтому можно гарантировать, что он подключен независимо от желания фронтендера. По-моему, у них какие-то древние шаблоны построены на jQuery, поэтому он им нужен.
И на сервере Javascript делать тоже нечего, т.к. даже автор Node.JS признал, что нода была фатальной архитектурной ошибкой и перспектив в ней никаких давно уже нет.
Слышал звон, да не знает где он. Потому что этот же автор ноды запилил другой проект, учтя все ошибки. Ну и есть альтернативы всякие.
социокультурный феномен
Так и про HTMX можно сказать.
Вы вот много проектов запилили на фронте? Сколько из них на современном чистом JS/CSS? Сколько на HTMX? Может вы не очень понимаете, что все эти приколы с реактом/ангуляром/vue/webcomponents/итд пошли не от недостатков старого js. Потому что фреймворки решают немножко другие проблемы. Например, абстракция низкоуровнего DOM API, решение проблемы композиции сложных UI элементов, инкапсуляция, унификация и т.д.
Серверный рендеринг был давно, но в какой-то момент люди ушли от массового aspx/jsx/jsf. И не потому что некий "социокультный феномен" случился. Как раз таки появились новые инструменты, помимо молотка, люди их попробовали, и сюрприз-сюрприз, иногда они лучше подходят под задачу но иногда надо и гвоздь забить.
Покажите пример своего проекта на htmx, со сложным графическим интерфейсом с кучей зависимых полей, мультиформ, с реактивностью
Мне правда интересно
На офсайте есть ссылка на, https://github.com/rajasegar/awesome-htmx для начала.
100 тудулистов на разных языках. Действительно, сложный графический интерфейс.
Теперь понятно, вы просто не занимались сложными проектами со сложными интерфейсами. Тогда речь ни о чем.
Htmx это уровень мелких поделок, сайтов лендосов.
И раз вы все равно генерируете код на сервере, вам и htmx /pjax /ajax не нужен. Зачем вам вообще это.
Я также думал как и вы, зачем все эти фронтовские фреймы напридумывали, не понимал, ведь гораздо проще на js/jquery лепить ))
Жаль что вам не попадались сложные интерфейсы в информационных системах. У вас примеры примитивы типа 9000 страниц crud, какие-то интернет магазины типа Али, лк от необанков. Там действительно не нужно вся эта чепуха с js.
А конкретика - информационные системы типа b2b торгов, трейдинговые платформы, ИС МФЦ, АСУ, и прочие проекты из Бигтек. И я имею ввиду не клиентские части, которые с 4 вкладками и 10 полями, доступные непосредственно клиентам системы. А именно админки по настройке, управлению информационной системы, где каждой роли свой кусочек интерфейса.
И честно, вам правда не нужен даже htmx, все прекрасно работает и без js
Я же правильно понимаю ваш посыл, графики и свечи постоянно рендерить на серверных мощностях и отдавать готовый html в браузер клиентам?
Вы считаете это адекватно использовать и нагружать сервер чтобы рендерить графики и свечи ?
Я в курсе как работает pjax) там рендер кусочка html на сервере происходит и с сервера прилетают готовые html кусочки (вы считаете адекватно нагружать сервер рендерить такие куски данных ?)
Потому и спросил
Как обычно, это как? Как Htmx авторизовывает sse/websocket/ соединение? (По тз показываем графики только авторизованным клиентам и сессионная кука может стать не валидной, забаненной, как обработать на htmx такие случаи?).
Дальше что происходит? От sse/ws приходят только json? Чей код апдейтит графики и свечи? Ваша писанина как-то при входящем data вызывает bar.update()? или htmx умеет апдейтить графики автоматически ? Рядом с графиком еще куча фильтров с селектами, которые зависят от других селектов, (которые должны подставляться в запрос чтобы приходили новые обновы по новым фильтрам), как сформировать новый url для автоматического фетча через htmx? А через ws?
Допустим используем чью-то либу для графиков, которая рендерит график по своим темплейтам и js. Нужно чтобы по клику на свечу отображалась еще таблица по стакану. Htmx тут поможет ? получится ему навесить свои хендлеры на чужие html элементы постоянно меняющиеся, обновляющиеся?
Вижу, что у вас опыта разработки серьезных информационных систем на htmx еще не было, сейчас у вас в уме все предельно легко
Вы не заметили вопросов с подвохом, т.к. если бы делали раньше такие системы, то ответ был бы другой
например, про куки и хедеры в ws,
или про клики на свечу (в svg-разметке свечи к примеру не будет никаких уточняющих данных что за свеча, за какой промежуток времени, или либа вообще на canvas)
и самое ужасное в вашей парадигме это напрягать сервера (которые в хайлоаде итак еле дышат) рендером html-разметки.
хорошо что Озон и прочие бигтеки разрабатывают не такие разработчики как вы :)
искренне желаю вам поучаствовать в разработке настоящих сложных информационных систем уровня бигтек (а не простых поделок на htmx)
люблю когда люди не имея опыта утверждают что разработать интерфейсы бигтека на htmx просто
особенно позабавило ваше утверждение что pre-junior справляются с такими задачами (тоже заметно что у вас нет опыта работы с pre-junior). Тоже самое и про ChatGPT - видно что вы ниразу не внедряли его в процессы разработки сложных ИС, поэтому у вас в уме все предельно легко :)
я тебе привел примеры тех проектов, где я участвовал, а тему графиков со свечами ты уже сам подхватил, и посыпался на них, все твои утверждения про htmx даже в таких темах не имеют подтверждения.
у себя в голове я уже тысячу раз разработал проекты уровня озон и янго, ничего сложного, и по твоей логике тоже могу утверждать, что обычного js там достаточно, никаких фреймов и htmx там не нужно
фильтры и гриды - это весь твой уровень? там htmx справится.
PWA так вообще смешно :)
нам джуниорам конечно не понять ваш сеньорский уровень типа htmx
Запуск идеи стоит 5 млн, и это дорого. Как сэкономить на проекте? Спойлер: откажитесь от React