Несмотря на краткость статьи - она невероятно водянистая.
А что по поводу reactive - его вообще можно не использовать. Даже если завернуть в реф объект - всё будет хорошо. В чем выгода reactive (с этого стоило начать а не к доке отсылать) - не описано
атомная энергетика (представляете, если в ПО или в оборудование будет баг?);
То есть, по вашему, если у человека есть высшее образование, то он багов не пишет? Как-то это наивно, не находите?
Я всегда считал считаю и буду считать, что лучшая форма образования - это самообразование.
Как было отмечено еще в первом клмментарии , никому не нужны вечные Нокиа 3310. Технологии устаревают, программа обучения устаревает вместе с ней. Она предельно неэффективна. А с учётом появления AI испытывать теорию на практике в программировании стало ещё проще. Так что пока один будет 5 лет учиться в универе, другой за год набьёт руку, создаст резюме с накрученным опытом и получит 4 года реального полезного опыта, за то же время окажется куда более ценным экземпляром для бизнеса.
Сломался впн от hidemyip, снова, я устал терпеть и нашёл эту статью будь она неладна. Послушался автора и потерял 4к рублей. Купил тариф, сразу решил на полгода взять, раз так просто всё заработает, подумал я. По итогу без впн в их сервисе нереально даже аккаунт подтвердить - ошибка при попытке отправить код подтверждения на моб телефон. В итоге купил аезу за крипту, получил ссылку на их конфиг влесс и установил в некорей. Впн заработал, теперь воюю с pq. Подтверждение прошёл - теперь непонятно как открыть админку вайргарда - по какому урлу домена она находится не понятно "После активации сервера нужно зайти в веб-интерфейс управления VPN-ом, создать нового пользователя и скачать его конфигурационный файл с настройками подключения." - где этот интерфейс находится автор не упоминает. Короче плохая статья, зря я вообще её прочитал и доверился.
А зачем тогда вообще нужна Яндекс карта, если не для использования их геокодера? Во фронтовой части карты osm на несколько порядков гибче Яндекс карт. И денег за спрос не берет
Я вот это всё почитал и мне как-то на секунду показалось - поднять openlayers на своих тайлах гибче, дешевле и даже местами проще. Если бы я писал своё приложение, приносящее доход, я бы не хотел чтобы маржинальность моего бизнеса зависела от провайдера карт.
Подними тарифы хостинг провайдер - я могу перенести инфраструктуру к кому угодно. Подними тарифы Яндекс - мне придется переписывать уйму кода.
При этом по другую сторону есть osm - сложный, кастомный, но тарифы он точно не поднимет 😁
При чем эти ребята вкорячивают nextjs, начиная каждый новый page со строчки 'use client' и прям обмазываются кайфом что они такие правильные, "используют SSR" 😁👍
Всё зависит от требований. Если к вам пришли за лендингом и попросили реакт - я полностью на вашей стороне.
Но если к вам пришли за сервисом по интеграции данных для автоматизации бизнес-процессов - а вы предложили бы мне SSR с jQuery - я бы вас сразу же уволил 🤗
Нужно уметь выбирать и применять технологию по мере уместности, а не потому что что-то модно, а что-то вечно.
Про версионирование, а если на SSR юзер оставит вкладку открытой на неделю, а разраб поменяет шаблон формы и изменит обработчик - добавит поле или поменяет путь до него - форма как должна узнать на старой вкладке что она старая? Эта проблема присуща обоим подходам и решается в обоих подходах одинаково. Нет её только если приложение абсолютно монолитно и предназначено для прикладных оффлайн задач. Калькулятор, excel, word... - какой оффлайн в вебе? (электрон извини, ничего личного 🫡)
У CSR есть ряд плюсов.
Во-первых сложное динамическое взаимодействие на чистом SSR выстроить нереально сложно. В любых современных SSR проектах есть острова клиентского рендера там, где много связей и сложный пользовательский путь.
Во-вторых CSR экономит трафик. Не приходится гонять кучу разметки по сети. А бандлы джаваскрипта весят меньше, если написаны не макаками. По итогу мы гоняем только json который легче + может кэшиться на уровне клиента через query cache плагины (tanstack query, rtk query...)
В-третьих (что там автор про производительность говорил?), по названию подхода очевидно, что в рендере представления участвует только клиент - мы снимаем с сервера эту задачу, оставляя под его ответственность только передачу бандла (что часто отводится вообще отдельному веб-серверу) и (непосредственно на backend) dto.
Ну а если вы писали SSR - вы уже фуллстек. Неважно куда вас забросит судьба - на фронт или бэк. Хороший программист грамотно мыслит везде.
Я не думаю что Туполев копировал эту систему. Ему и без того пришлось несладко при конвертации из дюймовой в метрическую систему. Да и копипаста это всегда вторично. У нас не умели, да и что греха таить, до сих пор не умеем мы делать такие высокотехнологичные моторы.
Да и скорее всего те крепости, которым пришлось сесть на нашем дальнем востоке, не обладали этой аппаратурой.
Всё равно эти плюшки не решают типичных проблем микрофронта. Так или иначе шареды нужно ставить и хранить отдельными npm пакетами, решать геморрой с router в remote и mixed content restrict policy.
Очень специфичный подход, применять его на мой взгляд стоит в очень специфичных случаях. Иначе он повлечет лишь издержки.
У реакта теперь есть компайлер - меня больше не будут ругать когда я назову реакт фреймворком?)
Автоматические оптимизации это круто конечно, но конкуренты то уже от vdom отказались. Всё равно нагонять, зато видно куда им двигаться дальше.
Обновление с формами вообще неактуально. Платины типа реакт хук формс или формик решают эту проблему, только помимо неё ещё больше дополняют функционал.
У реакта перед вью всего одно преимущество - хайп. Это не то, ради чего, на мой взгляд, его можно выбрать.
Какой механизм реакта ни выбери - его аналог на vue работает проще и логичнее, а выбор доп модулей необязателен - а одним реактом сыт не будешь. Реактеры считают это фичей, вьюшники - недоработкой. Это вечный холивар) Я на стороне вьюшников
Прекрасная статья, но как вишенки на торте, на мой взгляд, не хватает пары моментов. Первый - абзац про отказ от избыточных библиотек, тему задели лишь вскользь. Некоторые библиотеки, особенно из старичков, вообще не поддерживают tree shaking, вследствие архитектурной монолитности. И их исключение из кода - большой - если не основной - скачок в сторону увеличения перформанса. Как, например, меняли moment и на что именно. Ну и второй важный тейк - перформанс это не только про LCP. Это и про потребление памяти, которая вследствие иммутабельной концепции в реакте страдает. Работали ли над потреблением памяти в рантайме и если да, то с какими результатами.
Честно говоря, сравнение не самое привлекательное. Осталось много вопросов. А слоты. А сложносоставные события. А как вообще без референсов жить я вообще не понимаю. Про реактивность и стейт менеджмент не написано ничего.
Какой вообще может быть разговор о другом подходе если подход точно такой же. Те же самые компоненты, состояния и события. Просто инкапсулированы на порядок хуже чем у вью.
Да у вас в статье сабмит запрашивает пользовательские данные. Прочитайте что за бред вы в абзаце о формах написали. У меня этим утром на завтрак вместо кофе кровь из глаз, спасибо
На самом деле с ростом опыта гуглишь всё меньше и меньше. Я сам с детства путаю больше с меньше. Но гуглить синтаксис доступа к объекту, называя себя инженером - это слишком
мне, к примеру, наоборот, удобнее в месиве, чем скакать по пачке файлов.
Несмотря на краткость статьи - она невероятно водянистая.
А что по поводу reactive - его вообще можно не использовать. Даже если завернуть в реф объект - всё будет хорошо. В чем выгода reactive (с этого стоило начать а не к доке отсылать) - не описано
То есть, по вашему, если у человека есть высшее образование, то он багов не пишет? Как-то это наивно, не находите?
Я всегда считал считаю и буду считать, что лучшая форма образования - это самообразование.
Как было отмечено еще в первом клмментарии , никому не нужны вечные Нокиа 3310. Технологии устаревают, программа обучения устаревает вместе с ней. Она предельно неэффективна. А с учётом появления AI испытывать теорию на практике в программировании стало ещё проще. Так что пока один будет 5 лет учиться в универе, другой за год набьёт руку, создаст резюме с накрученным опытом и получит 4 года реального полезного опыта, за то же время окажется куда более ценным экземпляром для бизнеса.
Проверено, работает.
Более актуальное название "как не умея писать на vue можно превратить проект в реакт помойку"
Сломался впн от hidemyip, снова, я устал терпеть и нашёл эту статью будь она неладна.
Послушался автора и потерял 4к рублей. Купил тариф, сразу решил на полгода взять, раз так просто всё заработает, подумал я. По итогу без впн в их сервисе нереально даже аккаунт подтвердить - ошибка при попытке отправить код подтверждения на моб телефон.
В итоге купил аезу за крипту, получил ссылку на их конфиг влесс и установил в некорей.
Впн заработал, теперь воюю с pq.
Подтверждение прошёл - теперь непонятно как открыть админку вайргарда - по какому урлу домена она находится не понятно
"После активации сервера нужно зайти в веб-интерфейс управления VPN-ом, создать нового пользователя и скачать его конфигурационный файл с настройками подключения." - где этот интерфейс находится автор не упоминает.
Короче плохая статья, зря я вообще её прочитал и доверился.
В нем появился компилятор так что уже фреймворк
А зачем тогда вообще нужна Яндекс карта, если не для использования их геокодера? Во фронтовой части карты osm на несколько порядков гибче Яндекс карт. И денег за спрос не берет
Я вот это всё почитал и мне как-то на секунду показалось - поднять openlayers на своих тайлах гибче, дешевле и даже местами проще. Если бы я писал своё приложение, приносящее доход, я бы не хотел чтобы маржинальность моего бизнеса зависела от провайдера карт.
Подними тарифы хостинг провайдер - я могу перенести инфраструктуру к кому угодно. Подними тарифы Яндекс - мне придется переписывать уйму кода.
При этом по другую сторону есть osm - сложный, кастомный, но тарифы он точно не поднимет 😁
При чем эти ребята вкорячивают nextjs, начиная каждый новый page со строчки 'use client' и прям обмазываются кайфом что они такие правильные, "используют SSR" 😁👍
Всё зависит от требований. Если к вам пришли за лендингом и попросили реакт - я полностью на вашей стороне.
Но если к вам пришли за сервисом по интеграции данных для автоматизации бизнес-процессов - а вы предложили бы мне SSR с jQuery - я бы вас сразу же уволил 🤗
Нужно уметь выбирать и применять технологию по мере уместности, а не потому что что-то модно, а что-то вечно.
Про версионирование, а если на SSR юзер оставит вкладку открытой на неделю, а разраб поменяет шаблон формы и изменит обработчик - добавит поле или поменяет путь до него - форма как должна узнать на старой вкладке что она старая? Эта проблема присуща обоим подходам и решается в обоих подходах одинаково. Нет её только если приложение абсолютно монолитно и предназначено для прикладных оффлайн задач. Калькулятор, excel, word... - какой оффлайн в вебе? (электрон извини, ничего личного 🫡)
У CSR есть ряд плюсов.
Во-первых сложное динамическое взаимодействие на чистом SSR выстроить нереально сложно. В любых современных SSR проектах есть острова клиентского рендера там, где много связей и сложный пользовательский путь.
Во-вторых CSR экономит трафик. Не приходится гонять кучу разметки по сети. А бандлы джаваскрипта весят меньше, если написаны не макаками. По итогу мы гоняем только json который легче + может кэшиться на уровне клиента через query cache плагины (tanstack query, rtk query...)
В-третьих (что там автор про производительность говорил?), по названию подхода очевидно, что в рендере представления участвует только клиент - мы снимаем с сервера эту задачу, оставляя под его ответственность только передачу бандла (что часто отводится вообще отдельному веб-серверу) и (непосредственно на backend) dto.
Ну а если вы писали SSR - вы уже фуллстек. Неважно куда вас забросит судьба - на фронт или бэк. Хороший программист грамотно мыслит везде.
Attention, sarcasm!
Я не думаю что Туполев копировал эту систему. Ему и без того пришлось несладко при конвертации из дюймовой в метрическую систему. Да и копипаста это всегда вторично. У нас не умели, да и что греха таить, до сих пор не умеем мы делать такие высокотехнологичные моторы.
Да и скорее всего те крепости, которым пришлось сесть на нашем дальнем востоке, не обладали этой аппаратурой.
Всё равно эти плюшки не решают типичных проблем микрофронта. Так или иначе шареды нужно ставить и хранить отдельными npm пакетами, решать геморрой с router в remote и mixed content restrict policy.
Очень специфичный подход, применять его на мой взгляд стоит в очень специфичных случаях. Иначе он повлечет лишь издержки.
Статья хорошая.
У реакта теперь есть компайлер - меня больше не будут ругать когда я назову реакт фреймворком?)
Автоматические оптимизации это круто конечно, но конкуренты то уже от vdom отказались. Всё равно нагонять, зато видно куда им двигаться дальше.
Обновление с формами вообще неактуально. Платины типа реакт хук формс или формик решают эту проблему, только помимо неё ещё больше дополняют функционал.
У реакта перед вью всего одно преимущество - хайп. Это не то, ради чего, на мой взгляд, его можно выбрать.
Какой механизм реакта ни выбери - его аналог на vue работает проще и логичнее, а выбор доп модулей необязателен - а одним реактом сыт не будешь. Реактеры считают это фичей, вьюшники - недоработкой. Это вечный холивар) Я на стороне вьюшников
Прекрасная статья, но как вишенки на торте, на мой взгляд, не хватает пары моментов. Первый - абзац про отказ от избыточных библиотек, тему задели лишь вскользь. Некоторые библиотеки, особенно из старичков, вообще не поддерживают tree shaking, вследствие архитектурной монолитности. И их исключение из кода - большой - если не основной - скачок в сторону увеличения перформанса. Как, например, меняли moment и на что именно.
Ну и второй важный тейк - перформанс это не только про LCP. Это и про потребление памяти, которая вследствие иммутабельной концепции в реакте страдает. Работали ли над потреблением памяти в рантайме и если да, то с какими результатами.
При этом автор вообще ни слова не написал про механику парсинга представления
Честно говоря, сравнение не самое привлекательное. Осталось много вопросов. А слоты. А сложносоставные события. А как вообще без референсов жить я вообще не понимаю. Про реактивность и стейт менеджмент не написано ничего.
Какой вообще может быть разговор о другом подходе если подход точно такой же. Те же самые компоненты, состояния и события. Просто инкапсулированы на порядок хуже чем у вью.
Да у вас в статье сабмит запрашивает пользовательские данные. Прочитайте что за бред вы в абзаце о формах написали. У меня этим утром на завтрак вместо кофе кровь из глаз, спасибо
На самом деле с ростом опыта гуглишь всё меньше и меньше. Я сам с детства путаю больше с меньше. Но гуглить синтаксис доступа к объекту, называя себя инженером - это слишком