Блог компании Mail.Ru Group
JavaScript
ReactJS
Программирование
Комментарии 116
+2
При всей моей нелюбви к формулировке «react-разработчик», это хороший гайдлайн!
-1

Во-во, что тяжело!


Хотя в плане того, на сколько React сделан хуже, то на нем нужно больше работать, что большой плюс для наемных сотрудников!

0
Мне, как пишущему еще и на vue.js, было бы интересно увидеть подобный гайд, но уже к vue.
Может, кто и знает?
P.S. Отдаю себе отчет, в том, что по факту многое будет «сильно схожим» — ну «законы физики всюду одинаковые» :)
0
По моему достаточно понять всю документацию к вью, а если, что то не ясно тут же гуглить про это.
0
Пардон, кажется я плохо изложил свою мысль… разумеется первым делом «читаем документацию». В базовых вещах она у vue.js одна из лучших (на мой субъективный взгляд) (однако продвинутые задачи там никак не описаны толком).

Я скорее «о взгляде со стороны», т.е. как хороший специалист видит подобную картину для другого фреймворка.

Комментом выше дал нам хаброюзер нечто близкое, как минимум там есть интересные мысли :)
+2

Интересно, сколько по времени займёт сие самообучение в условия незанятости или занятости обучающегося? Хм...

+5
К концу обучения знания уже устареют три раза. Вывод: выкидываем это все нафиг и берем c++,c# или java.
+1
Да, С++ для клиентской разработки точно подойдет. А еще лучше FORTRAN, он точно никогда не устареет.
(сам с++-разработчик, но коммент показался не к месту).
+1
Все зависит от уже имеющихся знаний. Если есть опыт работы с javafx или wpf, то чтобы разрабатывать приложения на реакте, потребуется не больше месяца погружения. Если вообще с нуля, то есть нет представления как работать с компонентами, то очень много. И это при условии что js и css на высоте. Если нет знаний по js и css, то на их изучение уйдет не меньше время чем на c# или java.
+1
Все эти компоненты довольно небольшие, какие-то вещи типа React Router осваиваются за несколько часов, какой-нибудь classnames — это вообще одна функция.

Я летом начал писать свой собственный iphoto/google photos для своих фоток, имея нулевые знания о reactjs, и о современном вебе вообще, сейчас как минимум могу закрыть большинство желтых.

Весь этот фронтенд со стороны кажется адом, потому что очень фрагментирован, но на поверку оказывается, что все фрагменты а) довольно мелкие и б) сильно упрощают код (и жизнь).

После C++ не страшно, короч, и намного более friendly.
0
Понятно, спасибо. Надо после C# попробовать, а то после объёма статьи и пунктов глаза на лоб полезли.
0
Посмотрите ещё на angular. Для разработчика c# по духу он намного ближе и меньше нерв потратите.
+1
Начнете писать что-то сложнее, чем странички привет мир, вот тогда и ощутите всю боль. Я на реакте написал форум, аналог ББ форума, но только с еще большими хотелками, так это было реальное адище! На фронте кода было написано в сто раз больше, чем на бэке. А взаимодействие одних компонентов с другими напоминало паутину. Миллионы пропсов туда сюда, миллионы всяких проверок, исключений, роли, пермишены — это просто адище!!!
+1

Однозначно что-то делаете не так. Я сейчас на Реакте+МобХ пишу редактор, что-то вроде Юнити, это намного сложнее таких базовых вещей, как форум. И у меня нету таких проблем.


Может, вы пользовались Редаксом? Он очень сильно усложняет разработку.

0
Тимлид, дятел, отказался от использования редакса. Все только пропсами и стейтами. Пояснить свою позицию он так и не смог. Мол, чтобы при будущих обновлениях ничего не отвалилось.

У себя же в проектах я тоже использую мобх. Без него это было бы тоже адище. Единственное, что тяжело отлаживать хранилище простым консольным выводом. Нужно ставить плагины, а я любитель лисы, для которой нет решения (а может плохо искал).

Я сейчас на Реакте+МобХ пишу редактор, что-то вроде Юнити


Лично я бы все таки на яве писал.
0
Тимлид, дятел, отказался от использования редакса. Все только пропсами и стейтами.

Поэтому-то и ад. Даже сам ФБ не смог справиться с голым реактом.


Про обновления, конечно, очень странно слышать. Redux — настолько маленькая библиотека, что там просто нечему отваливаться. Опять же, никто не заставляет обновляться.

0
Лично я бы все таки на яве писал

Не подходит Джава под задачу
-3
Я бы пункт с jQuery изменил на «Ни в коему случае не знакомьтесь с jQuery»
0
Откуда такая нелюбовь к инструменту, который не так давно сильно упрощал жизнь веб-разработчику?
+3
Моя «нелюбовь» обусловлена «чрезмерной любовью» окружающих. Он настолько изменил сознание многих «разработчиков», что изменить цвет кнопки без применения jQuery для них уже не представляется возможным.
Кроме того, jQuery настолько засел у многих в голове, что когда задаешь вопрос «как с помощью JS изменить цвет кнопки», в ответ тебе предлагают подключить n-килобайтную библиотеку на страницу для решения тривиальной задачи. Более того, есть даже такие индивидуумы, которые не понимают, что jQuery — это всего лишь библиотека, а не отдельный язык программирования.

Но надо упомянуть, что в последние несколько лет эта тенденция значительно уменьшается и это несомненно радует
0

ну да, ведь теперь, чтобы поменять цвет кнопки, нужно сделать так:


npm install babel
npm install css-selector
npm install button-color
npm install yarn...


Утрирую конечно, но веб сейчас это беготня от одной крайности к другой.

+1
Ну вот это я и пытался показать, когда писал предыдущий свой комментарий)) Для решения тривиальных задач многие привыкли использовать кучу библиотек, когда достаточно одной строки
+2
const btn = document.getElementById('btn_id')
btn.style.backgroundColor = '#000000'

Я вот только что попробовал без Ваших npm/yarn install — РАБОТАЕТ )))

0
можно еще проще:
#btn_id {background-color: #000}

jQuery? Не, не слышал))
Почему-то мне кажется, что многие js-dev применяют для таких задач исключительно js, забывая о том, что на css это куда проще. Но тут уже кому как удобнее.
+5
Я думал, что речь шла про «динамическое» изменение цвета кнопки, при определенном событии?
Простите, я может быть, потерял течение дискуссии…
0
Странно что никто до сих пор не предложил:
.button {
  background-color: red;
  &:hover {
    background-color: green;
  }
}

Пример не только без jQuery но и без JS вообще, тем более без какого-либо реакта и тонны зависимостей (синтаксис SCSS для примера). Также можно много примеров с анимацией привести без использования JS на чистом CSS…

Собственно это я к чему — если стоит задача написать с минимумом зависимостей как можно проще, ее всегда можно решить, но она очень часто не стыкуется с задачей написать гибко и достаточно удобно, тем более для разных задач свои технические условия.
0
Странно, что никто не предложил БЭМ
.mybutton {
  background-color: red;
  &--another-state { background-color: green; }
}
+1
Только вот с React разработчиками проблема точно такая же — они не знаю что можно что-то делать нативными средствами
-1
jQuery это не просто синтаксический сахар, или js для нубов, это в первую очередь универсальный код чтобы работало везде, их основанная задача была в этом, чтобы не думать о кроссбраузерности, так что не уметь менять цвет кнопки без jq это отсутствие необходимости так делать, потому что делать на чистом js это риски.
0

У вас информация устарела лет на 5. Какие риски вот в этой строчке кода:


document.getElementById('btn_id').style.backgroundColor = '#000000'
0
Сейчас думаю осталось очень мало ситуаций, где jQuery спасает от проблем совместимости, но когда эта библиотека только что появилась — какое это было удовольствие писать и не задумываться о том, как код поведёт себя в разных браузерах. До jQuery писать на JS было очень больно. Часто бывало так: 5 минут пишешь код, а потом ещё полчаса пытаешься сделать так, чтобы он одинаково работал в IE 5.5, IE 6, Firefox и Opera. И это в те времена, когда DevTools в браузерах ещё не существовало.

Так что про основную задачу комментатор выше написал правильно, просто сейчас это уже почти неактуально. Проблема с несовместимостью браузеров стала сильно меньше, а там, где она остаётся — появились новые, более удобные инструменты для разрешения таких конфликтов.

Может это вкусовое, но чем мне jQuery нравится до сих пор — так это краткостью. Сравните
document.getElementById('btn_id')
и
$('#btn_id')
(они не совсем идентичны, но для примера). И так со всем, короткие ключевые слова типа prop, on, hide, append и т.д., которые легко запоминались и которые было быстро писать. Vanilla JS всё-таки на редкость многословный.
0
но когда эта библиотека только что появилась — какое это было удовольствие писать и не задумываться о том, как код поведёт себя в разных браузерах

Я в курсе об этом. Именно поэтому написал "устарела", а не "совсем неправильная".


но чем мне jQuery нравится до сих пор — так это краткостью

Если вам нравится такой API – посмотрите на blissfuljs. 3-килобайтная утилитка с API в том же стиле. Или можно написать свои сокращения для методов, всяко лучше чем тащить слона jQuery.

+2
jQuery содержит большое количество идей, которые новичку знать обязательно, даже если он не будет потом непосредственно jQuery пользоваться. Это способ понять Javascript (в контексте веб-разработки) намного полнее. Также, если человек будет видеть jQuery-код в чужих проектах, или, например, когда будет искать ответ на вопрос на Stackoverflow, то он будет понимать, о чем идет речь.
+3
Ни в коему случае не знакомьтесь с jQuery


Это вы пишете на сайте где уже подключен jQuery, причем не самой новой версии.
+2
Простите, а можно обосновать в чем именно заключается аргумент против jQuery если он используется на Хабре?
-2
И что с ней должно быть не так?
Вроде ничего не коллапсирует, пространственно-временной континуум не нарушается.
-1
Вот две страницы для примера:

habr.com/post/423889 — десктопная версия поста, на jQuery
m.habr.com/post/423889/comments — мобильная версия того же поста, на Vue.

На десктопе у меня загрузка заняла 1,5 минуты. Только после этого времени кнопка ответа на комментарий начинает работать. В мобильной версии загрузка занимает 25 секунд.
+1
И при чем тут jQuery или VUE?
В таких сравнениях все упирается в конкретную реализацию.
Если все проекты пилить только на React — они от этого автоматически быстрее или лучше работать не станут, везде свои подводные камни.
У меня тоже знакомые фронты на реакте постоянно кидают какашками в jQuery, только при этом у самих проекты не лучше, со своими костылями.
Холивары эти уже порядком поднадоели — решает не то чье кунг-фу круче, а то как им владеет мастер. Кроме того напрямую сравнивать нельзя, ибо задачи разные и инструменты.
Примеры с комментариями не корректны по крайней мере по той причине что мы не знаем их реализацию и то насколько над ними заморачивались в плане оптимизации работы. Как минимум я думаю что при желании оптимизировать десктопную версию хабра можно и без смены стека.
0
А причём тут комментарии? jQuery можно и нужно использовать точечно.
Никогда не понимал этой дичи — «ни в коем случае не пользуйтеь ХХХ». Не умеете пользоваться — не пользуйтесь, конечно. А нормальным разработчикам это экономит кучу времени
+2
Неплохая иллюстрация к тезису о том, что новые языки учатся легко и быстро. И тезис-то не сказать, чтобы неверный, но «есть один нюанс...»
0
А кто нибудь может, показать сложные приложения на Реакте? На примере каких нибудь существующих интернет сервисов? Хотелось бы пощупать
-1
Slack на Electron написан, разве нет? Вот первая же ссылка в поиске: electronjs.org/apps/slack. И, кстати, WhatsApp Desktop — тоже: electronjs.org/apps/whatsapp (тоже — в смысле, ещё один messenger, и тоже Electron). Кстати, пользуюсь обоими приложениями (на Windows) — из особенностей — только долгая загрузка, старт приложения. На не самом последнем ящике (рабочий Dell, какой-то i7 внутри, 8 GB RAM, Win10) — секунд 20-30 запускается что Slack, что Цапа
0
Сбербанковский фронт на Реакте (не гарантирую, что весь, но новое всё пишут только на нём). В Альфе фронт весь на Реакте. Да много чего ещё. Реакт-консоль в Хром поставьте и пробегитесь по популярным сайтам
+5
блин БЭМ то зачем прописали как «must know» и без него очень даже норм. ибо это сильно дело вкуса
-2
Десять лет назад открывали блокнот и за пол часа делали все свистелки и перделки. А сейчас нужно знать десятки и сотни всяких библиотек, подходов, решений, которые по сути и нах не нужны. Так как ничего принципиально нового на странице так и не появилось, все тот же текст и изображения. Только хоботни добавилось в сто раз больше. Если что, то ежедневно пишу на реакте. При этом постоянно прозревая, зачем я пишу килотонны кода для вывода какой-то странички.
+2

Напишите в блокноте spa приложение с кучей форм и логики.

0
Да-да, мы таки добрались до веб программ. И в итоге чтобы сымитировать поведение десктопной программы городим десятки тысяч строк кода, раздувая билды до десятков мегабайт. А главное, что не меняется ни идеология, ни подходы. Скачем вприпрыжку с тем же js-ом, которому уже сто лет в обед. Любые новые технологии должны упрощать разработку, а не усложнять! А что по факту? На поле фронтенда полный хаос и бардах. Через год, а то и раньше, текущие знания фронтендера умножаются на ноль. И это уже не нормально!
+1

Что-то я не видел языков для десктопа на которых не нужно писать десятки тысяч строк кода по сравнению с вебом.

+1
Даже не буду в пример брать десктопные решения, приведу более простой пример: Андроид студия на ява для разработки мобильных приложений. У вас есть готовый форм билдер, благодаря которому вы можете накидать интерфейс за пару часов. Все остальное — это экшены и бизнес логика. Сколько раз вам удавалось просто взять и перенести компонент реакта написанный для одного проекта в другой проект? Ну если это конечно не какой-то глупый компонент. Для любых десктопных приложений, впрочем как и на бэкендовых языках, вы пишите реальную логику (алгоритмы, вычисления, хранение и обработка данных, передача данных по сетям и т.д), а фронт был рожден для отображения и красоты этого отображения. Раньше боролись за каждый лишний байт передаваемый по сети, а что сейчас?

Что-то я не видел языков для десктопа на которых не нужно писать десятки тысяч строк кода по сравнению с вебом.
Для десктопа тысячи строк вы пишите для бизнес логики, а на фронте вы пишите только морду. А это две большие разницы.
0

Так а что на js больше занимает? Бизнес логика или отображение?
Еще надо учитывать, что у андроида нет нужды в такой респонсивности и сама либа работы с андроидом встроенная и там гораздо больше кода, если убрать из сборки фреймворк/библиотеку на которой пишется, выхлоп будет тот же, бизнес логика и тонкий html + css

+2
Я говорю только про внешний вид. Формы будете сами писать или использовать сторонние? Валидацию форм и вывод ошибок сами будете организовывать или костыль попытаетесь прикрутить? Специфические данные для формы будете через фронт реализовывать или будете ждать ответа от бэка после сабмита или онченжа? Как реализуете в инпуте проверку на вещественное число? А как вы будете проверять роли и пермишены для пользователя с разрешением разным правам отдавать разные компоненты? Я ведь не теоретик, и на огромном проекте по недвижимости испытал всю боль от очень сложных интерфейсов и всевозможных нестандартных данных. А как вам форма на 70 полей с десятками комбинаций в зависимости от введенных данных или выбранных списков, радиобатанов и чекбоксов? Я уже молчу про всякие автопоиски и автозаполнения, которые без бэка вообще не реализуются в динамике. Может какой-то бложик накидать на реакте легко и не принуждено можно за недельку, но я на проекте только один форум к порталу пилил около года, и столкнулся с такими запросами бизнеса, что меня штырило каждый день и не отпускало. А как вам каждые пару месяцев новые мажорные апдейты реакта, с миллионом деприкейтов? Ой, обновился бэбпак, давайте потанцуем с бубном, так как после обновления он ни фига уже не собирает. Ой, поменяли в новом апдейте реакта подходы, теперь стейты в конструкторе не нужно писать, теперь в пропсах нужно жестко прописывать прилетаемые данные, какая прелесть. Останавливаем проект на месяц и рефакторим весь код. Отрефакторили, ура, а теперь одна старая либа, которая еще не обновилась в нпм, конфликтует с другими новыми. Билд теперь не собирается. Зато, мать его так, новые и современные технологии. Так, а теперь главное не забыть на сотни сущностей написать еще серверный рендеринг и так далее и тому подобное. Не разработка, а просто мечта какая-то.
+1
Я уже молчу про всякие автопоиски и автозаполнения, которые без бэка вообще не реализуются в динамике.

А под андроид вы без бека как напишете?

+1
У андроида есть своя локальная база! Зачем трафик гонять по сети, сжирая аккумулятор и вызывая тормоза? Но я все никак не могу понять, вы на реакте и js писали? Вы проблем вообще никаких не видите? Технология мечта, технология спасение?
0

По поводу бд:
https://developer.mozilla.org/ru/docs/Web/API/Window/sessionStorage
https://developer.mozilla.org/ru/docs/Web/API/Window/localStorage
Так же не стоит забывать о том, что андроид операционка, а веб работает в основном в браузерах, которых есть множество под ваш любимый андроид.


По поводу проблем, они есть везде и отрицать это глупо, к тому же, веб кросплатформенный и у браузеров нет своей sdk которую тянет в себе любое андроид устройство, у которого кстати тоже есть обратная совместимость, которую иногда нужно поддерживать.


Ну и самый главный довод: у вас есть альтернативы? Если нужен именно сайт, какой вы язык кроме js выберете?

0
Ну и самый главный довод: у вас есть альтернативы? Если нужен именно сайт, какой вы язык кроме js выберете?

А какие могут быть альтернативы, если нам вся эта дичь навязывается гигантами? Разве кто-то вышел к сообществу с предложением и дал на выбор ряд вариантов, например, использование нативного скомпилированного кода или оставить все как есть? Все это напоминает мне стокгольмский синдром. Нас имеют, а мы радуемся.

Меня возмущает не реакт или js, меня возмущает факт того, что вместо того чтобы изменить принцип и подход, на голову разработчику сваливают тонны «гениальных фреймворков и плагинов», которые не фига не решают, а только усложняют приложение, которое еще до выпуска первого релиза придется обновлять с десяток раз, при этом раз пять рефакторить после обновления. И пока хотя бы часть сообщества будет это благодарно кушать, и восторженно благодарить, то такое положение дел не изменится никогда. Через десять лет, чтобы вывести страничку с хелло ворд, наверняка придется потратить 40 часов времени разработчика, а подобные статьи выше, разрастутся до длины туалетного рулона.

Но альтернатив нет и это бесит.
0
Судя по вашим информативным ответам и мощной аргументации, я делаю предположение, что вы тролль обычный. Поэтому просто идите нах.
0

Какой тролль? У вас теории заговора о браузерных движках.

0
Кстати, в словах Kirill_Dan
есть доля истины: HTML/CSS не создавался для богатых интрфейсов.
А ведь были альтернативы вроде Java Applet, Sliverlight, Flash, там народ пилил довольно сложные интерфейсы относительно просто. Но ни одна из подобных технологий, где формочки были by design не стала поддерживаться нативно всеми бразуерам.
Но я не разделяю пессимизма Kirill_Dan
, у нас уже есть сносный date picker, вот подвезли <input type=«search», дальше будет какой-ниубдь HTML7 в котором, ещё больше фичей подвезут.
-1

Альтернативы есть:


  1. Компиляция из других языков в JS. Вот тут списочек где-то на сотню вариантов.
  2. WebAssembly

Альтернативы постепенно развиваются и видимо рано или поздно текущий пиздец, происходящий с фронтенд-разработкой, сколлапсирует под своей тяжестью и альтернативы обретут большую популярность.

0
Как-то у вас всё в одну кучу. Реакт прекрасно справляется с тем, для чего создавался (сам писал и пишу на нём, если что). Когда 70 полей и десятки комбинаций — это вопросы к бизнес-логике, а не к инструменту рисования вьюшек. И даже с этим реактовский подход с его изменением стейтов и автоматической перерисовкой отображения кардинально упрощает жизнь, нежели делать это всё ручками на коллбэках на чистом JS.
А вопрос взаимодействия толстого клиента и сервера с базой — это вообще третий вопрос.
0
Любая IDE по типу борландовских. Рисуешь формы, пишешь обработчики, привязываешь к формам.
В вебе по простоте только vue + bootstrap близко подошли, в остальном — простыни лапшекода.
0
Нет, там, где есть рисовалки форм, развесистая объектная модель этих форм — хорошо документированная, с удобными методами и т.п.
Во фреймворках JS — непохожие друг на друга велосипеды.
0

Дело в том, что десктопные формы — это по сути обёртки над API графической оболочки, такие как MFC, WinForms, Qt, GTK, etc. И у них есть общая концепция — оконная stateful модель и свой неблокирующий цикл обработки событий, за которым не надо следить.
В вебе совсем другая концепция: во-первых, нет никаких окон, во-вторых, отсутствует автоматическое сохранение состояния, в-третьих, event-loop хоть и есть, но общий для всего кода. Ну и устоявшиеся паттерны взаимодействия с экранами отличаются в вебе и на десктопе.
В итоге эмулировать десктоп в вебе сложно и невостребовано. А развесистая объектная модель для построения интерфейсов хорошо документированная и с относительно удобными методами в вебе есть, DOM называется.

0
Ну, пожалуй, согласен. Только уточню, что в wxWidgets нужно самому писать в отдельном от лупа UI треде обработчики, иначе луп заблокируется, а в web хоть явных окон нет, но условные объекты есть. Те же modal-ы поп-апы и т.п.
А DOM от документированности полезным stateful объектом не становится :( И в итоге получается, что под WEB UI приходится писать массу абстрактного кода.
0
Те же modal-ы поп-апы и т.п.

Скорее просто div'ы, которые по факту являются частью основной страницы и только за счёт CSS выглядят как что-то "отдельное".


А DOM от документированности полезным stateful объектом не становится :(

Ну, формально у нас есть localStorage, этакий аналог олдскульных settings.ini, из которого можно так же восстанавливать внешний вид, как это делалось при повторном открытии десктопной программы. А пока страница не перегрузилась она вполне себе stateful, на чём и основаны SPA-приложения. В каком-то роде, это ближайший аналог десктопных, им тоже надо время на первичную загрузку, а потом хранение состояния и отзывчивость (за минусом пинга) примерно такая же.

0
В целом, так и есть, но тем ни менее в Delphi и том же WinForms была огромная инфраструктура по сравнению с существующими API браузеров + UI библиотек. Всё делалось ОЧЕНЬ быстро. И компонентная база содержала кучу компонент практически на любые случаи. Это от вендора фреймворка + дополнительная куча компонент, API которых был в едином стиле с фреймворком в большинстве случаев. Зоопарка ощутимо было меньше.

В итоге эмулировать десктоп в вебе сложно и невостребовано.

Да эмулировать-то ничего и не надо. Никто не говорит, что требуется 1 в 1 переносить концепцию. Важно то, что подобными инструментами можно было быстро прототипировать накидав на формочку и получив быстрый результат. А затем не сильно напрягаясь допилить до рабочего решения.

П, С. Очень уважаю React и, в целом, не испытываю большого скепсиса по поводу современного веба, но то как выглядят изнутри многие современные веб «приложения» в сравнении с олдовыми винформами порой удручает.
0

Я тоже когда-то программировал на Delphi, компонентная модель там была удобной спору нет. Но что касается интерфейса не всё так однозначно… На среднестатистическую форму(вкладку) приходилось не больше пары десятков элементов управления. И зачастую было достаточно форм статических размеров, поддержку ресайза можно было только для главной формы делать, да ещё и минимально допустимый размер ей указать.
Если Вы сравните это со среднестатистической современной веб-страницей, то можно прифигеть… тут тысячи элементов управления и надо чтоб всё красивенько отображалось и на мобилках и на 4k мониторах. Поэтому их нельзя просто покидать на формочку, ибо заколебётесь их расставлять и режим выравнивания и ресайза выставлять. Хотя на заре WWW попытки были… тот же Microsoft FrontPage и аналоги.


Короче говоря, мой пойнт в том, что вы помните, что всё делалось просто, но уже забыли, что то, что делалось было на порядки проще в плане интерфейса.
Однако, объективный косяк есть: W3C просто не успевает вводить нормальные стандартизированные элементы, а те, что есть в разных браузерах выглядят по-разному и порой достаточно убого. В итоге даже банальный checkbox или select почти везде эмулируются через кастомную верстку CSS-фреймворками.

0

А если форма должна генерироваться динамически по списку полей, который приходит с сервера, и уметь отображаться на разных устройствах оптимальным образом? И да, поля тоже могут быть произвольного типа.

0
> если форма должна генерироваться динамически по списку полей, который приходит
Как минимум это было не про JavaScript, с появлением TypeScript я могу сделать класс изоморфного поля формы и в цикле плодить инстансы. Ну, в 90-х это было у всех на C++.
> и уметь отображаться на разных устройствах оптимальным образом
Опять не про HTML/CSS (о эти внезапные скроллбары в окнах скайпа, когда перевод не влезает туда, где был текст на английском!), а вот формы на основе сайзеров — вполне оптимальны.
0
с появлением TypeScript я могу сделать класс изоморфного поля формы и в цикле плодить инстансы

на JS это тоже можно сделать


Ну, в 90-х это было у всех на C++.

Это было сильно проще, чем на реакте?

0
Что мешает писать свистелки и перделки в блокноте сейчас? Проблема возникает, когда свистелки вырастают до целого фейерверка, и становится очень сложно разрабатывать его в блокноте. Эта проблема была актуальна и раньше. React и прочие фрэймворки помогают справляться со сложностью приложений, деля его на уровни абстракций.
0
Я согласен, вообще не спорю. Но разрастание клиента до уровня программы при устаревших условиях самого браузера + js — это, как по мне, полный бред. Как 10 лет назад без всего этого жили с относительно небольшой сложностью и нагрузкой клиента? А сейчас, чтобы вывести информационный блок с информацией и картинкой, нужно совершить шаги, написанные в статье, только не для изучения (считаем, что уже все знаем), а для инсталляции и первоначальной настройки. Да за это время я уже успею какое-то АПИ на руби накидать.
0
А сейчас, чтобы вывести информационный блок с информацией и картинкой, нужно совершить шаги, написанные в статье

Не нужно утрировать, что-бы вывести информационный блок с картинкой достаточно написать:
<img src="..."> <p>Info text</p>

0

Никто в здравом уме не городит стэк, описанный в статье, для того, чтобы отобразить картинку. Инструменты внедряются тогда, когда становится проще с ними, чем без них.

+1
Никто в здравом уме не городит стэк, описанный в статье

Ага. Первый таск — вывести картинку и текст. Второй таск — создать динамические комментарии, третий таск — сделать систему кармы,…

Знаете такую методологию, как Agile?! Когда у заказчика ветер в черепной коробке гуляет? Тут про здравый ум вообще говорить не приходится.
+1

Этот список/статью лучше назвать "что вам желательно знать чтобы быть web-разработчиком", а не react-разработчиком.

-1
Фронтенд разработчиком, если точнее. Так как фулстек разрабу нужно знать еще и бэкендовые языки, базы данных, разные протоколы, миллионы всяких сервисов и библиотек для сервера и т.д.
0

А мне вот что интересно. Со временем количество используемых технологий, а соответственно и сложность входа во фронтенд разработку, растет гораздо быстрее, чем сложность публикуемых веб-приложений. В итоге встает вопрос, что проще: сделать веб приложение на более простых, но понятных технологиях бородатого года, либо обучиться всему стеку 2018 года и потом "долететь за 5 минут".


Я не претендую на объективность, но заметил, что в работе нашей фронтэнд команды, работающей на реакте, постоянно что-то отваливается и местами глючит. На устранение причины тратятся месяцы, а чаще всего они отмазываются, что это глючит что-то в стеке: фреймворк, библиотека, etc… Любое изменение или добавка начинается с нытья, что это рушит им всю архитектуру, или что это очень сложно сделать, ссылаясь на ограничения фреймворка. И самое главное — за прошедшие 10 лет сложность приложений сильно не возросла, но у меня твердо сложилось ощущение, что сейчас разработка стала более дорогой и менее качественной, чем 10 лет назад, когда все писали на JQuery. Посговорчивей чтоли тогда люди были...

+2

Это у вас разработчики такие, если любое изменение рушит архитектуру — значит её нет.

+1
10 лет назад на клиенте в основном снежинки падающие рисовали, ну ладно, валидацию фомочки можно было сделать, а теперь это полноценные SPA приложения.
На каком нибудь Эмбере и сейчас можно сделать достойно, но кому это надо, если еще через 5 лет фронтендер со знанием только эмбера окажется на обочине индустрии. Тут уж лучше следовать трендам.

0

Видите ли, я вообще родом из 90-х. И на протяжении всей своей жизни видел и разрабатывал достаточно сложные десктопные приложения, используя разные технологии, начиная от MFC, VCL, QT, Java Swing и заканчивая Android-ом. Для меня достаточно сложным приложением является например Microsoft Word. И могу заявить, что даже он не тянет за собой все эти тонны нестабильного и постоянно меняющегося говна, и прочего псевдокода. Возможно в Microsoft все делают как-то неправильно и не концептуально, но люди как-то до сих пор обходились и обходятся. Уж не знаю что представляют из себя эти мифические "полноценные SPA приложения", но в реале дело не уходит дальше банального дешбоарда или десяти формочек с кнопочками, привязанных к страничной навигации. И мне очень смешит и одновременно нервирует, когда люди, имеющие в кармане язык с динамической типизацией, говорят о концептуальности использования Redux. Более того, я из области бекенда. Долгое время у нас был JavaEE, на смену которому постепенно пришел Spring. И нам как бы хватает — там есть все, что нужно для типового проекта. Почему же во фронтэнде нет такого инструмента, включающего в себя все необходимое? Уж извините за излишнюю резкость.

0
Полностью согласен. Я разрабатываю и на бэкенде и на фронте. После нормальных ЯП, JS для меня pain in ass. И эта проблема была бы решена, если бы убожеские браузеры ушли на нативное исполнение компилированного кода. Но нет. Где-то читал, что это заговор всех производителей. Какова причина, для меня загадка.
0

Возможно потому, что на фронтенде никто не будет тащить на фронт многомегабайтный фреймворк, потому что в нём есть всё, что можно.

-1

Ой ли? На фронтенд даже не постеснялись притащить целый браузер ввиде электрона ради поделки с парой кнопочек. Вот недавняя статья на этот счет. Веб приложения постоянно пухнут, нещадно жрут память и тормозят, при всем том, что их функциональность особо сильно не меняется. И это как бы никого не волнует. Никто не стесняется ради красивой кнопочки подключать сразу всю библиотеку, или ради пары иконок тащить весь фонт.


Так что причина не в этом, а в том, что это вся экосистема JS — это куча мелких говноподелок, склепанных школьниками на коленках. А все, более-менее серьезное в JS было сделано крупными компаниями для внутреннего использования и щедро подарено в оперсорс.

0

Это уже не фронтенд, а десктоп. Скачать бинарник и установить на компьютер это одно, а практически каждый раз загружать по сети приложение — другое.


Так что причина не в этом, а в том, что это вся экосистема JS — это куча мелких говноподелок, склепанных школьниками на коленках. А все, более-менее серьезное в JS было сделано крупными компаниями для внутреннего использования и щедро подарено в оперсорс.

Причина чего? Того, что нет фреймворка размером со Spring, или что он есть, но сделан корпорацией?


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

Java из коробки тоже много всего содержит, но всё равно в Spring куча классов. И вот, что интересно, вам не нравится рост объёмов фронтенда, но при этом вы хотели бы, чтобы на фронтенде был огромный фреймворк, где всё из коробки?

0
Да ну к черту.
Слегка ужасает, что всё это — не единый стек инструментов (как у того же ms), а более 50 разнообразных инструментов. Даже если каждый из них будет обновляться раз в месяц — это минимум два обновления каждый день!
Именно поэтому двух одинаковых фронтенд-разработчиков не бывает. Один знает 10 фреймворков, второй знает 10 фреймворков, и хорошо если эти множества пересекаются хотя бы мажорными версиями.
Полноценные SPA приложения — это всё те же десять формочек и кнопочек. Принципиально ничего нового в 2018 году в веб не пришло — всё те же асинхронные запросы-ответы, вокруг которых всё крутится. Это _должно_ делаться просто и быстро, а если для этого нужно знать 50 фреймворков — то с индустрией что-то не так.
+1

Полностью с вами согласен, коллега. Причем налицо парадокс — сложность разработки с каждым годом растет гораздо быстрее, чем сложность самих приложений. Интересно, когда же наступит технологическая сингулярность?

0
По-идее, каждый инструмент должен делать разработку проще (говоря формально, позволять достичь заданных требований, потратив меньше ресурсов). Если он делает её сложнее, то инструменту не место в проекте.
0
минимум два обновления каждый день!

Никто вас не накажет, если не будете обновляться. Можете вообще не обновляться, если все устраивает.


один знает 10 фреймворков, второй знает 10 фреймворков.

Ага, наверное, лучше так: "один написал 10 странных велосипедов, другой написал 10 странных велосипедов".

+1
Список длинный, материал объемный. Но для полноты гайдлайна не хватает примеров опенсорсных проектов под каждый пункт, где вот это все можно практиковать в реальных проектах. Новичку читать документацию и писать «привет мир» слабо поможет стартануть.
+1

Facebook не использует React на основном своем продукте, так как React недостаточно быстрый. Facebook часто зависает на секунд 3-5, когда просто ставишь смайлик. Представляете что было бы, если бы они его на React написали, вообще месяцами бы пришлось ждать?


Это все, что нужно знать про React… А если захочется узнать больше, то… лично я много матерился, когда читал документация, особенно зная, что во Vue это все сделали уже через правильное место.


Выводы:


  1. Китайцы умеют придумывать слово из трёх букв, которые никто не знает как произносить, но при этом они являются самыми сбалансированными решениями для своих платформ… И у обоих гредет версия 3 в скором будущем, помимо Vue, это ещё Yii.
  2. Нужно ждать, когда ВКонтакте родит свой фреймворк, так как у них в отличии от Facebook все летает (молчу вообще, что и UX сделан головой, а не тем, чем в Facebook).

P.S. На самом деле в документации React есть одна здравая мысль — это то, что JavaScript нужно учить по сайту Ильи Кантора, там ссылка на английскую версию.


P.P.S. По самой статье, такое впечатление, что человек просто написал все слова, которые знал.

+1
Как на счет того, что они его используют при разработке своих мобильных приложений: Facebook, Instagram? Тем временем у Vue все еще очень сыро с аналогом React Native.
0
А, теперь ясно, почему при установке на телефон их приложений память заканчивается )))
0

Было бы неплохо перечислить как раз самый минимум, чтобы не пугать начинающих разработчиков.

0
В тестирование добавьте codeceptjs — реально топовый фреймворк для тестирования примерно всего! Активно развивается и очень прост в настройке и изучении.
Только полноправные пользователи могут оставлять комментарии. , пожалуйста.