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 в том, что в ней за день разберётся и бэкендер миддл+.
>столько же как htmx+python/lavarel
ребята "изобрели" технологию 20летней давности, на рынке наверное полно 50-60летних дедушек которые за недорого что-то попишут на JSP/JSF и тому подобном. И вполне возможно, что сделают это лучше нубасов реакта.
А писали бы на 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 это было уже не совсем то
HTMX невероятно гениален своей простотой, он сделал HTML/HTTP именно такими, какими они и должны были быть изначально и куда их нужно уже сейчас развивать W3C стандартами, он там прям естественно вписывается.
А в Реакте изначально есть что-то чужеродное и противоестественное. Паразитарное. И тем самым ненужное и вредное.
Реакт пытался решать проблемы тормозов манипуляции DOM в старых браузерах, пытался решать проблемы мерцания экрана при переходах по страницам. Но это все за последние годы браузеры решили и без него самостоятельно.
Потом еще что-то решал. Как правильно компоненты делать и архитектуры наслаивать, ага.
Сейчас же он из потенциально полезной новомодной технологии превратился просто в социокультурный феномен - куча народу не хочет видимо вникать в современные HTML/CSS/VanillaJS/HTTP/etc, а хочет "работать" готовыми темплейт снипетами из стековерфлоу. Но это отвалится, как только HTMX коммунити наберет нужную критическую массу готовых шаблонов, постов взаимопомощи и прочих типовых решений с книжками.
Реакт сегодня это уже технолудическая инвестиция по типу попытки в 21 веке развития паровозов и трамваев на конной тяге. Даром что ты сейчас модный спец по закидыванию хуков в топку, каток истории тебя так или иначе тебя раздавит твоей чужеродностью, ненужностью и неэффективностью в ближайшие годы (как и все остальные чумовые фреймворки).
Чтобы отобразить визуальное представление состояния сессии пользователя в браузере - Javascript же никогда не был обязателен. Просто нужно было выдать из сервера нечто в текстовом или бинарном виде виде, и С++ код браузера предельно эффективно его отрендерит и обратные интерактивности (мышеклики и поля ввода) на сервер тоже сам отошлет. Без необходимости натужного предварительно пережевывания сотен тысяч строк на стремном обфусцированном Javascript коде.
Браузер же это по сути лишь продвинутый графический терминал (по типу TTY, mstsc.exe или xfreerdp, X/Ming, etc X11). Ни у кого ведь не возникает уже чумовая идея через вкрутить Javascript в какой putty или RealVNC, а чем веб-браузер лучше?
Разумный удел Javascript в обозримой перспективе - это лишь поддерживать мелкие недоделки в HTML/CSS функционале и в интерактивно-поведенческих сценариях в браузерах (которые еще не отлили в WebKit граните). Беря поправку на то, что 95% задач (анимации, трансформации, карусели, визуальные темы и т.п.), для которых JS был просто обязателен 10 лет назад - уже сейчас и вовсе отлично решаются средствами CSS (читай - написанным на C++ движком WebKit).
И на сервере Javascript делать тоже нечего, т.к. даже автор Node.JS признал, что нода была фатальной архитектурной ошибкой и перспектив в ней никаких давно уже нет. Пока еще живет в силу инертности и социокультурного феномена, но в целом она и там тоже не родная и должна быть в итоге выпилена.
Вместе с вечно недоделанным и странно принципиальным Firefox, который перестал быть прикольным и лишь тормозит прогресс человечества (став современным IE6/11), блокируя этот самый прогресс через свою несговорчивость в части доработки стандартов.
Странно, что ноду хоронят не те люди, которые ей пользуются, а те, которые ей не пользуются, и, следовательно, не знают, почему её выбрали те, кто пользуются. Вернее, они, может, и знают, но для них это не существенно. Однако те, кто всё же взял ноду, видимо, по-другому не могут, или для них это слишком напряжно. Давайте ещё всех с автоматических коробок передач пересадим на механические, ведь так в теории можно экономить бензин. Правда, придётся открывать школы эффективного вождения и загонять туда людей, тратя их время и деньги, но кого же это волнует?
Это и есть социокультурный феномен. Просто привыкли делать как-то так, как привыкли и как кажется проще. Один раз хорошо освоивший молоток будет вполне эффективно и шурупы забивать в доски (это кажется невероятным, пока не увидишь какого 60 летнего дедушку на стройке, который вбивает 75мм длиной каленый шуруп в доску с одного удара молотка).
В мире давным давно существует document.querySelector(), но до сих есть отдельная когорта ортодоксальных любителей $() синтаксиса, у них же есть свои доводы и мотивация. С нодой и реактом ситуация абсолютно аналогичная.
И автомобилями все не так однозначно. Да, есть 95% населения, которые и знать не знают, что у них не только тормозами на колесах, но и педалью газа управляет электронный болван (потенциально сбойный, как любая электроника и потенциально бажный, как любое ПО). И 5% которые умеют сами очень ловко дергать за ручки, крутить руль и нажимать педали, без электронного болвана в промежутке. Но те 95% они просто юзеры, им простительно. Впрочем, айтишники тоже в массе и не инженеры, и не автогонщики
Да, есть айтишники, которым нужно просто сделать, чтобы работало, не упарываясь в производительность. Не все занимаются хайлоадом. Обучиться новому языку с новым фреймворком иногда дороже, чем просто скопипастить готовое решение. Пусть даже кому-то оно кажется шурупом с молотком.
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. И не потому что некий "социокультный феномен" случился. Как раз таки появились новые инструменты, помимо молотка, люди их попробовали, и сюрприз-сюрприз, иногда они лучше подходят под задачу но иногда надо и гвоздь забить.
Слышал звон, да не знает где он. Потому что этот же автор ноды запилил другой проект, учтя все ошибки. Ну и есть альтернативы всякие.
Звон, трезвон, альтернативы, зачем это все? Есть же "тренд", что на Javascript будет переписано тотально вот вообще все, от фронта, бека и чуть-ли не JаvascriptOS вот вот уже будет с нами. Ну и? Когда же уже будет всеобщий JS Universe?
На самом же деле это все просто от инертности мышления. В браузерах весьма изначально странный по своей природе JS живет просто принудительно, не имея реальных альтернатив. Была надежда на WebAssembly, но видимо по политическим причинам ему перекрыли доступ в DOM API и прочим нужным API, иначе бы уже JS вылетел и из фронта. Только за счет давно доступных, к примеру, С++ dead code elimination / link time optimizations и прочих обфускаций коммерческого кода .
Например, абстракция низкоуровнего DOM API, решение проблемы композиции сложных UI элементов, инкапсуляция, унификация и т.д.
Это все не имеет никакого особого смысла и ценности для прикладной разработки. По хорошему для браузеров должны быть написаны просто хорошие библиотеки продвинутых веб компонент (или WebComponents, или и вовсе встроенных в браузер, но только не настолько непроходимо и безнадежно убогих, как input type="date"), потому как да, писать на div/input ну прям откровенно грустно. А пользоваться потом еще грустнее.
А в остальном же никакой такой прикладной логики на "продвинутом графическом терминале по имени веб-браузер" быть в принципе и не должно - он должен лишь предельно быстро отображать состояние приложения от ответов/запросов сервера, и слать на сервер когда нужно обратно значения полей ввода и прочие активности пользователя. Попытка представить браузер как некий прям полноценный архитектурный компонент программной логики приложения, с этими всеми доменными моделями, модульными уровнями абстракции, интерфейсами, сегрегацией доступа и ответственности... да ну, и это все на средстве, которое не то что нормальный компилятор/линковщик, но даже int64 тип полноценный почему-то не имеет и до сих пор в каком то странном безумии предлагает все целочисленные данные через double обрабатывать?
Покажите пример своего проекта на htmx, со сложным графическим интерфейсом с кучей зависимых полей, мультиформ, с реактивностью
Мне правда интересно
На офсайте есть ссылка на, https://github.com/rajasegar/awesome-htmx для начала.
А так - пока HTMX большей частью живет в бэкофисе, особо много не покажешь. И он себя не позиционирует как законченный фреймворк в духе какого Oracle APEX.
По поводу зависимых полей с реактивностью - это конечно отдельно улыбнуло. Все вам покоя пример онлайн калькулятора с полями A: [ ] + B: [ ] = [ ] не дает.
HTMX такое не решает, такие примитивы на стороне фронта можно пилить на чем угодно. Он вообще больше про взаимодействия фронта и бекэнда, начиная с "а вот теперь мы элегантно выбрасываем JSON API и SPA подход от него, и SPA будем пилить теперь вот так".
На офсайте есть ссылка на, https://github.com/rajasegar/awesome-htmx для начала.
100 тудулистов на разных языках. Действительно, сложный графический интерфейс.
100 тудулистов на разных языках. Действительно, сложный графический интерфейс.
Причем тут примитивизм todo examples? HTMX это просто подход, это не законченный фреймворк-инфраструктура с темплейтами аля Wordpress или Joomla.
Это по сути просто библиотека (да, ок, для PJAX и еще кое чего).
Если сравнивать с автомобилем - это да, по сути старый двигатель, но уже нового принципа действия, не ДВС, не электродвигатели, а скорее гравицапа. Которую можно вкрутить в свой старый Долориан и получить сосем новое некое качество перемещения из точки А в точку Б.
А дописать (переосмыслить, написать заново) нужные UI компоненты и в целом шаблоны - это вполне достижимая, веселая и задорная задача на ближайшие пару месяцев, как раз теперь и повод есть.
Ну или продолжать натужно ездить на индийском Реакт/Нода автобусе, не зря же права категории D последние пять лет дружно всем отделом получали :)
Теперь понятно, вы просто не занимались сложными проектами со сложными интерфейсами. Тогда речь ни о чем.
Htmx это уровень мелких поделок, сайтов лендосов.
И раз вы все равно генерируете код на сервере, вам и htmx /pjax /ajax не нужен. Зачем вам вообще это.
И раз вы все равно генерируете код на сервере, вам и htmx /pjax /ajax не нужен. Зачем вам вообще это.
Что такое сложный проект со сложными интерфейсами? Рассказывать про over 9000 примитивных CRUD страниц не надо - из даже если и будет более 100500, то суть их примитивности (качество) от количества оных не изменится.
Тогда что такое тогда сложный интерфейс? Какой необанк по типу Тинькофф это сложный или не сложный? Озон, алиэкспресс?
Что именно там такого в этих "сложных" интерфейсах, что в принципе нельзя сделать через HTMX с небольшими вкраплениями VanillaJS и WebComponents?
Можно пример? Типа вот берем форму заказа от Али, и... ? Наверное оплату через QR код по СПБ не прикрутить, или OAuth какой, да?
Конкретика будет? Или как всегда ограничимся абстрактными пугалками вида "а вот как только у вас проект станет достаточно сложный, так сразу начнутся проблемы идемпотентности зависимостей в силу роста величины модульного зацепления" ?
Я также думал как и вы, зачем все эти фронтовские фреймы напридумывали, не понимал, ведь гораздо проще на js/jquery лепить ))
Жаль что вам не попадались сложные интерфейсы в информационных системах. У вас примеры примитивы типа 9000 страниц crud, какие-то интернет магазины типа Али, лк от необанков. Там действительно не нужно вся эта чепуха с js.
А конкретика - информационные системы типа b2b торгов, трейдинговые платформы, ИС МФЦ, АСУ, и прочие проекты из Бигтек. И я имею ввиду не клиентские части, которые с 4 вкладками и 10 полями, доступные непосредственно клиентам системы. А именно админки по настройке, управлению информационной системы, где каждой роли свой кусочек интерфейса.
И честно, вам правда не нужен даже htmx, все прекрасно работает и без js
А конкретика - информационные системы типа b2b торгов, трейдинговые платформы, ИС МФЦ, АСУ, и прочие проекты из Бигтек.
Ну и? В чем проблема?
На HTMX нельзя сделать график со свечами или ордербук через SSE/WebSockets/etc в реалтайме?
Конкретнее, конкретнее пожалуйста. Я ведь тоже могу типа сильно умным прикинуться и рассказать, что на HTMX прям никак нельзя BOM процессы для сметно-кадастрового геодезического центра со спутниковым мониторингом перемещения грузовиков в реальном времени запилить, только на реакте, только на нем любимом.
Или какое CAE твердотельное моделирование механики жидких сред для спутникового коллайдера.
Казалось бы, при чем тут, да?
Так будет конкретика?
Я же правильно понимаю ваш посыл, графики и свечи постоянно рендерить на серверных мощностях и отдавать готовый html в браузер клиентам?
Вы считаете это адекватно использовать и нагружать сервер чтобы рендерить графики и свечи ?
Я же правильно понимаю ваш посыл, графики и свечи постоянно рендерить на серверных мощностях и отдавать готовый html в браузер клиентам?
Вообще не правильно. В самом начале сервер просто "рендерит" HTML на создание веб компонента для рисования графика. Благо их уже сотни готовых на любой вкус и цвет (в т.ч. и для чисто vanilla js).
Генерит или на первоначальной загрузке страницы или в момент когда пользователь кликнет на какую кнопку или закладку с "Динамика цен". Результатом обработки нажатия кнопки будет прилетевший в нужный element id этот самый HTML фрагмент с этим графиком и каким приложенным javascript кодом c данными. Lazy loading в действии. По сути гидратация через SSR, или как там в реато-SPA это сейчас называется.
И дальше как обычно - туда сюда шлем на/с сервера хоть JSONы, хоть сразу новые SVG элементы для графиков, хоть '<script></script>' на выполнение это кому как будет веселее.
HTMX это же не про "э блин, а вот теперь все снова все делаем типа только на HTML5/CSS3/NoJavascript, ну ок и вот чутка AJAX но больше нини", вовсе нет.
HTMX - это про "а вот сейчас мы элегантным, но мощным пинком выбрасываем наследие React/Vue/Angular//Svelte/Belte/Next/Nuxt/Naxt/Nixt/Nyxt../../../../../ (N=100500)xt" и начинаем жить нормальной жизнью фуллстек девелопера с уклоном в какие бухгалтерии, без выгорания на хуках и history API.
Я в курсе как работает pjax) там рендер кусочка html на сервере происходит и с сервера прилетают готовые html кусочки (вы считаете адекватно нагружать сервер рендерить такие куски данных ?)
Потому и спросил
Как обычно, это как? Как Htmx авторизовывает sse/websocket/ соединение? (По тз показываем графики только авторизованным клиентам и сессионная кука может стать не валидной, забаненной, как обработать на htmx такие случаи?).
Дальше что происходит? От sse/ws приходят только json? Чей код апдейтит графики и свечи? Ваша писанина как-то при входящем data вызывает bar.update()? или htmx умеет апдейтить графики автоматически ? Рядом с графиком еще куча фильтров с селектами, которые зависят от других селектов, (которые должны подставляться в запрос чтобы приходили новые обновы по новым фильтрам), как сформировать новый url для автоматического фетча через htmx? А через ws?
Допустим используем чью-то либу для графиков, которая рендерит график по своим темплейтам и js. Нужно чтобы по клику на свечу отображалась еще таблица по стакану. Htmx тут поможет ? получится ему навесить свои хендлеры на чужие html элементы постоянно меняющиеся, обновляющиеся?
Как обычно, это как? Как Htmx авторизовывает sse/websocket/ соединение? (По тз показываем графики только авторизованным клиентам и сессионная кука может стать не валидной, забаненной, как обработать на htmx такие случаи?).
Зачем? auth_token куки шлет браузер. Можно и без кукисов, в HTMX есть возможность дописывать произвольные request headers, но зачем усложнять?
Про невалидную куку не совсем понятно. Как обрабатывать на HTMX ошибки от сервера? Да как угодно, можно заново редиректить на страницу авторизации (сервер инициирует редирект клиента), или на стороне браузера можно перехватывать какие 403/404. Можно и так и так, как угодно. Там вообще нет никаких ограничений и навязываемых подходов, только новые дополнительные к HTML5/CSS3/JS6 фичи, которые можно использовать, можно не использовать (правда автор странно любит и поддерживает даже и IE11, но шутки по этому поводу оставим, у него видимо это личное).
Дальше что происходит? От sse/ws приходят только json? Чей код апдейтит графики и свечи? Ваша писанина как-то при входящем data вызывает bar.update()? или htmx умеет апдейтить графики автоматически ?
В смысле умеет? HTMX штатно сам умеет по клику или какому еще событию получить от сервера HTML код, встроить его куда сервер скажет, при случае вызвать указанный сервером JS или и вовсе сделать какой redirect/page reload. А что сверху - всегда можно ловко донавернуть самому в нужных местах разными способами, плюс расширения всякие готовые.
Там нет ничего военного - всякими разными подходами можно отработать действия пользователя и выслать на сервер request, куда записать тоже что угодно, и получить от сервера ответ - по дефолту один кусок HTML и target element id (но можно и много кусков, и много target), скрипты потом обработчиками вызывать, события получать/заново слать, и т.д. и т.п. Там нет ограничений, в отличие от. Полная свобода. Там только одно ограничение - нет обязательности в React/Vue/Angular и любого иного натужного OpinionWare в зависимостях.
Только htmx.min.js и браузер с его базовым функционалом, этого уже достаточно для полноценного SPA. А дальше можно самому развивать и декорировать куда захочется.
получится ему навесить свои хендлеры на чужие html элементы постоянно меняющиеся, обновляющиеся?
Элементарно. Один из способов - регистрируются custom events, на них вешаются обработчики. Сервер шлет этот самый event, обработчики делают что им там нужно, получив нужные данные через event параметры. И это лишь один из способов.
Может стоит документацию почитать и примеры поизучать? Они там очень прикольные, читаются легко, задорно и весело, в отличие от React/Vue/Angular тягомотины. Первая глава и эссе особенно заставляют прям задуматься о безумии этого вашего корпоративного софтостроения и не только.
Вижу, что у вас опыта разработки серьезных информационных систем на htmx еще не было, сейчас у вас в уме все предельно легко
Вы не заметили вопросов с подвохом, т.к. если бы делали раньше такие системы, то ответ был бы другой
например, про куки и хедеры в ws,
или про клики на свечу (в svg-разметке свечи к примеру не будет никаких уточняющих данных что за свеча, за какой промежуток времени, или либа вообще на canvas)
и самое ужасное в вашей парадигме это напрягать сервера (которые в хайлоаде итак еле дышат) рендером html-разметки.
хорошо что Озон и прочие бигтеки разрабатывают не такие разработчики как вы :)
SSE/Websockets лично я не занимался, да, чятики пилил другой человек. Ну в чем там сложность-то? sectet's hash можно послать каким угодно способом, да хоть как часть пользовательских данных. В чем откровение-то?
Клики на свечу? Да, такое я тоже не делал. Дальше что?
Загуглить "Add onclick event to SVG element" и найти готовый снипет может ребенок лет семи наверное. И потом еще штук 30 снипетов на выбор, какой больше глазу приятнее будет.
Тоже мне ловля на живца, смешно. Это все задачи уровня pre-junior. Решаются правым мизинцем и половинкой гипоталамуса (и ChatGPT вполне справится), там больших ресурсов и не требуется.
искренне желаю вам поучаствовать в разработке настоящих сложных информационных систем уровня бигтек (а не простых поделок на htmx)
люблю когда люди не имея опыта утверждают что разработать интерфейсы бигтека на htmx просто
особенно позабавило ваше утверждение что pre-junior справляются с такими задачами (тоже заметно что у вас нет опыта работы с pre-junior). Тоже самое и про ChatGPT - видно что вы ниразу не внедряли его в процессы разработки сложных ИС, поэтому у вас в уме все предельно легко :)
люблю когда люди не имея опыта утверждают
Ок, тебя попросили привести пример действительно сложных интерфейсов. В результате мы услышали про клики на свечах на SVG графиках, и увидели невнятную попытку самоутверждения демонстрацией чувства превосходства в финале.
Это вообще не спортивно. А можно было и про хитрые LOV с диалогами поиска, и про настраиваемые/сохраняемые фильтры в каких pivot или обычных гридах поговорить, для начала. И про offline mode в PWA, чтоб уж точно HTMX на лопатки положить.
Впрочем это наверное уже middle уровень, джуниорам такое не поручают? Ну и ладно, как нибудь в другой раз.
я тебе привел примеры тех проектов, где я участвовал, а тему графиков со свечами ты уже сам подхватил, и посыпался на них, все твои утверждения про htmx даже в таких темах не имеют подтверждения.
у себя в голове я уже тысячу раз разработал проекты уровня озон и янго, ничего сложного, и по твоей логике тоже могу утверждать, что обычного js там достаточно, никаких фреймов и htmx там не нужно
фильтры и гриды - это весь твой уровень? там htmx справится.
PWA так вообще смешно :)
нам джуниорам конечно не понять ваш сеньорский уровень типа htmx
а тему графиков со свечами ты уже сам подхватил
фильтры и гриды - это весь твой уровень? там htmx справится.
PWA так вообще смешно :)
По теме совсем нечего сказать? Это печально (с).
Кстати, а упомянутые "фреймы" это вообще что? Это так по-молодежному frameworks уже стало принято называть? Типа как "собес" это оказывается собеседование, а вовсе не то место, где СНИЛСы выдают?
Запуск идеи стоит 5 млн, и это дорого. Как сэкономить на проекте? Спойлер: откажитесь от React