Comments 121
Во-во, что тяжело!
Хотя в плане того, на сколько React сделан хуже, то на нем нужно больше работать, что большой плюс для наемных сотрудников!
Может, кто и знает?
P.S. Отдаю себе отчет, в том, что по факту многое будет «сильно схожим» — ну «законы физики всюду одинаковые» :)
github.com/orsanawwad/awesome-roadmaps
Я скорее «о взгляде со стороны», т.е. как хороший специалист видит подобную картину для другого фреймворка.
Комментом выше дал нам хаброюзер нечто близкое, как минимум там есть интересные мысли :)
Интересно, сколько по времени займёт сие самообучение в условия незанятости или занятости обучающегося? Хм...
Согласна))
(сам с++-разработчик, но коммент показался не к месту).
Поиграться уже можно: https://webassembly.org/docs/c-and-c++/. А за год может и популярность наберёт..
Я летом начал писать свой собственный iphoto/google photos для своих фоток, имея нулевые знания о reactjs, и о современном вебе вообще, сейчас как минимум могу закрыть большинство желтых.
Весь этот фронтенд со стороны кажется адом, потому что очень фрагментирован, но на поверку оказывается, что все фрагменты а) довольно мелкие и б) сильно упрощают код (и жизнь).
После C++ не страшно, короч, и намного более friendly.
Однозначно что-то делаете не так. Я сейчас на Реакте+МобХ пишу редактор, что-то вроде Юнити, это намного сложнее таких базовых вещей, как форум. И у меня нету таких проблем.
Может, вы пользовались Редаксом? Он очень сильно усложняет разработку.
У себя же в проектах я тоже использую мобх. Без него это было бы тоже адище. Единственное, что тяжело отлаживать хранилище простым консольным выводом. Нужно ставить плагины, а я любитель лисы, для которой нет решения (а может плохо искал).
Я сейчас на Реакте+МобХ пишу редактор, что-то вроде Юнити
Лично я бы все таки на яве писал.
Кроме того, jQuery настолько засел у многих в голове, что когда задаешь вопрос «как с помощью JS изменить цвет кнопки», в ответ тебе предлагают подключить n-килобайтную библиотеку на страницу для решения тривиальной задачи. Более того, есть даже такие индивидуумы, которые не понимают, что jQuery — это всего лишь библиотека, а не отдельный язык программирования.
Но надо упомянуть, что в последние несколько лет эта тенденция значительно уменьшается и это несомненно радует
const btn = document.getElementById('btn_id')
btn.style.backgroundColor = '#000000'
Я вот только что попробовал без Ваших npm/yarn install — РАБОТАЕТ )))
#btn_id {background-color: #000}
jQuery? Не, не слышал))
Почему-то мне кажется, что многие js-dev применяют для таких задач исключительно js, забывая о том, что на css это куда проще. Но тут уже кому как удобнее.
Простите, я может быть, потерял течение дискуссии…
.button {
background-color: red;
&:hover {
background-color: green;
}
}
Пример не только без jQuery но и без JS вообще, тем более без какого-либо реакта и тонны зависимостей (синтаксис SCSS для примера). Также можно много примеров с анимацией привести без использования JS на чистом CSS…
Собственно это я к чему — если стоит задача написать с минимумом зависимостей как можно проще, ее всегда можно решить, но она очень часто не стыкуется с задачей написать гибко и достаточно удобно, тем более для разных задач свои технические условия.
У вас информация устарела лет на 5. Какие риски вот в этой строчке кода:
document.getElementById('btn_id').style.backgroundColor = '#000000'
Так что про основную задачу комментатор выше написал правильно, просто сейчас это уже почти неактуально. Проблема с несовместимостью браузеров стала сильно меньше, а там, где она остаётся — появились новые, более удобные инструменты для разрешения таких конфликтов.
Может это вкусовое, но чем мне jQuery нравится до сих пор — так это краткостью. Сравните
document.getElementById('btn_id')
и $('#btn_id')
(они не совсем идентичны, но для примера). И так со всем, короткие ключевые слова типа prop, on, hide, append и т.д., которые легко запоминались и которые было быстро писать. Vanilla JS всё-таки на редкость многословный.но когда эта библиотека только что появилась — какое это было удовольствие писать и не задумываться о том, как код поведёт себя в разных браузерах
Я в курсе об этом. Именно поэтому написал "устарела", а не "совсем неправильная".
но чем мне jQuery нравится до сих пор — так это краткостью
Если вам нравится такой API – посмотрите на blissfuljs. 3-килобайтная утилитка с API в том же стиле. Или можно написать свои сокращения для методов, всяко лучше чем тащить слона jQuery.
Ни в коему случае не знакомьтесь с jQuery
Это вы пишете на сайте где уже подключен jQuery, причем не самой новой версии.
Вроде ничего не коллапсирует, пространственно-временной континуум не нарушается.
habr.com/post/423889 — десктопная версия поста, на jQuery
m.habr.com/post/423889/comments — мобильная версия того же поста, на Vue.
На десктопе у меня загрузка заняла 1,5 минуты. Только после этого времени кнопка ответа на комментарий начинает работать. В мобильной версии загрузка занимает 25 секунд.
В таких сравнениях все упирается в конкретную реализацию.
Если все проекты пилить только на React — они от этого автоматически быстрее или лучше работать не станут, везде свои подводные камни.
У меня тоже знакомые фронты на реакте постоянно кидают какашками в jQuery, только при этом у самих проекты не лучше, со своими костылями.
Холивары эти уже порядком поднадоели — решает не то чье кунг-фу круче, а то как им владеет мастер. Кроме того напрямую сравнивать нельзя, ибо задачи разные и инструменты.
Примеры с комментариями не корректны по крайней мере по той причине что мы не знаем их реализацию и то насколько над ними заморачивались в плане оптимизации работы. Как минимум я думаю что при желании оптимизировать десктопную версию хабра можно и без смены стека.
Никогда не понимал этой дичи — «ни в коем случае не пользуйтеь ХХХ». Не умеете пользоваться — не пользуйтесь, конечно. А нормальным разработчикам это экономит кучу времени
Что-то я не видел языков для десктопа на которых не нужно писать десятки тысяч строк кода по сравнению с вебом.Для десктопа тысячи строк вы пишите для бизнес логики, а на фронте вы пишите только морду. А это две большие разницы.
Ну и самый главный довод: у вас есть альтернативы? Если нужен именно сайт, какой вы язык кроме js выберете?
А какие могут быть альтернативы, если нам вся эта дичь навязывается гигантами? Разве кто-то вышел к сообществу с предложением и дал на выбор ряд вариантов, например, использование нативного скомпилированного кода или оставить все как есть? Все это напоминает мне стокгольмский синдром. Нас имеют, а мы радуемся.
Меня возмущает не реакт или js, меня возмущает факт того, что вместо того чтобы изменить принцип и подход, на голову разработчику сваливают тонны «гениальных фреймворков и плагинов», которые не фига не решают, а только усложняют приложение, которое еще до выпуска первого релиза придется обновлять с десяток раз, при этом раз пять рефакторить после обновления. И пока хотя бы часть сообщества будет это благодарно кушать, и восторженно благодарить, то такое положение дел не изменится никогда. Через десять лет, чтобы вывести страничку с хелло ворд, наверняка придется потратить 40 часов времени разработчика, а подобные статьи выше, разрастутся до длины туалетного рулона.
Но альтернатив нет и это бесит.
есть доля истины: HTML/CSS не создавался для богатых интрфейсов.
А ведь были альтернативы вроде Java Applet, Sliverlight, Flash, там народ пилил довольно сложные интерфейсы относительно просто. Но ни одна из подобных технологий, где формочки были by design не стала поддерживаться нативно всеми бразуерам.
Но я не разделяю пессимизма Kirill_Dan
, у нас уже есть сносный date picker, вот подвезли <input type=«search», дальше будет какой-ниубдь HTML7 в котором, ещё больше фичей подвезут.
1. Компиляция из других языков в JS. Вот [тут](https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS) списочек где-то на сотню вариантов.
1. [WebAssembly](https://webassembly.org/docs/high-level-goals/)
Альтернативы постепенно развиваются и видимо рано или поздно текущий пи*дец, происходящий с фронтенд-разработкой, сколлапсирует под своей тяжестью и альтернативы обретут большую популярность.
А вопрос взаимодействия толстого клиента и сервера с базой — это вообще третий вопрос.
В вебе по простоте только vue + bootstrap близко подошли, в остальном — простыни лапшекода.
Во фреймворках JS — непохожие друг на друга велосипеды.
Дело в том, что десктопные формы — это по сути обёртки над API графической оболочки, такие как MFC, WinForms, Qt, GTK, etc. И у них есть общая концепция — оконная stateful модель и свой неблокирующий цикл обработки событий, за которым не надо следить.
В вебе совсем другая концепция: во-первых, нет никаких окон, во-вторых, отсутствует автоматическое сохранение состояния, в-третьих, event-loop хоть и есть, но общий для всего кода. Ну и устоявшиеся паттерны взаимодействия с экранами отличаются в вебе и на десктопе.
В итоге эмулировать десктоп в вебе сложно и невостребовано. А развесистая объектная модель для построения интерфейсов хорошо документированная и с относительно удобными методами в вебе есть, DOM называется.
А DOM от документированности полезным stateful объектом не становится :( И в итоге получается, что под WEB UI приходится писать массу абстрактного кода.
Те же modal-ы поп-апы и т.п.
Скорее просто div'ы, которые по факту являются частью основной страницы и только за счёт CSS выглядят как что-то "отдельное".
А DOM от документированности полезным stateful объектом не становится :(
Ну, формально у нас есть localStorage, этакий аналог олдскульных settings.ini, из которого можно так же восстанавливать внешний вид, как это делалось при повторном открытии десктопной программы. А пока страница не перегрузилась она вполне себе stateful, на чём и основаны SPA-приложения. В каком-то роде, это ближайший аналог десктопных, им тоже надо время на первичную загрузку, а потом хранение состояния и отзывчивость (за минусом пинга) примерно такая же.
В итоге эмулировать десктоп в вебе сложно и невостребовано.
Да эмулировать-то ничего и не надо. Никто не говорит, что требуется 1 в 1 переносить концепцию. Важно то, что подобными инструментами можно было быстро прототипировать накидав на формочку и получив быстрый результат. А затем не сильно напрягаясь допилить до рабочего решения.
П, С. Очень уважаю React и, в целом, не испытываю большого скепсиса по поводу современного веба, но то как выглядят изнутри многие современные веб «приложения» в сравнении с олдовыми винформами порой удручает.
Я тоже когда-то программировал на Delphi, компонентная модель там была удобной спору нет. Но что касается интерфейса не всё так однозначно… На среднестатистическую форму(вкладку) приходилось не больше пары десятков элементов управления. И зачастую было достаточно форм статических размеров, поддержку ресайза можно было только для главной формы делать, да ещё и минимально допустимый размер ей указать.
Если Вы сравните это со среднестатистической современной веб-страницей, то можно прифигеть… тут тысячи элементов управления и надо чтоб всё красивенько отображалось и на мобилках и на 4k мониторах. Поэтому их нельзя просто покидать на формочку, ибо заколебётесь их расставлять и режим выравнивания и ресайза выставлять. Хотя на заре WWW попытки были… тот же Microsoft FrontPage и аналоги.
Короче говоря, мой пойнт в том, что вы помните, что всё делалось просто, но уже забыли, что то, что делалось было на порядки проще в плане интерфейса.
Однако, объективный косяк есть: W3C просто не успевает вводить нормальные стандартизированные элементы, а те, что есть в разных браузерах выглядят по-разному и порой достаточно убого. В итоге даже банальный checkbox или select почти везде эмулируются через кастомную верстку CSS-фреймворками.
Как минимум это было не про JavaScript, с появлением TypeScript я могу сделать класс изоморфного поля формы и в цикле плодить инстансы. Ну, в 90-х это было у всех на C++.
> и уметь отображаться на разных устройствах оптимальным образом
Опять не про HTML/CSS (о эти внезапные скроллбары в окнах скайпа, когда перевод не влезает туда, где был текст на английском!), а вот формы на основе сайзеров — вполне оптимальны.
Вся проблема в том что люди с других языков не могут осилить веб. То есть проблема в том что не хотят переучиваться и думают что этот список технологий какой-то лишний капец. Никакого капеца нет, просто кругом неосиляторы.
Никто в здравом уме не городит стэк, описанный в статье, для того, чтобы отобразить картинку. Инструменты внедряются тогда, когда становится проще с ними, чем без них.
Никто в здравом уме не городит стэк, описанный в статье
Ага. Первый таск — вывести картинку и текст. Второй таск — создать динамические комментарии, третий таск — сделать систему кармы,…
Знаете такую методологию, как Agile?! Когда у заказчика ветер в черепной коробке гуляет? Тут про здравый ум вообще говорить не приходится.
А мне вот что интересно. Со временем количество используемых технологий, а соответственно и сложность входа во фронтенд разработку, растет гораздо быстрее, чем сложность публикуемых веб-приложений. В итоге встает вопрос, что проще: сделать веб приложение на более простых, но понятных технологиях бородатого года, либо обучиться всему стеку 2018 года и потом "долететь за 5 минут".
Я не претендую на объективность, но заметил, что в работе нашей фронтэнд команды, работающей на реакте, постоянно что-то отваливается и местами глючит. На устранение причины тратятся месяцы, а чаще всего они отмазываются, что это глючит что-то в стеке: фреймворк, библиотека, etc… Любое изменение или добавка начинается с нытья, что это рушит им всю архитектуру, или что это очень сложно сделать, ссылаясь на ограничения фреймворка. И самое главное — за прошедшие 10 лет сложность приложений сильно не возросла, но у меня твердо сложилось ощущение, что сейчас разработка стала более дорогой и менее качественной, чем 10 лет назад, когда все писали на JQuery. Посговорчивей чтоли тогда люди были...
На каком нибудь Эмбере и сейчас можно сделать достойно, но кому это надо, если еще через 5 лет фронтендер со знанием только эмбера окажется на обочине индустрии. Тут уж лучше следовать трендам.
Видите ли, я вообще родом из 90-х. И на протяжении всей своей жизни видел и разрабатывал достаточно сложные десктопные приложения, используя разные технологии, начиная от MFC, VCL, QT, Java Swing и заканчивая Android-ом. Для меня достаточно сложным приложением является например Microsoft Word. И могу заявить, что даже он не тянет за собой все эти тонны нестабильного и постоянно меняющегося говна, и прочего псевдокода. Возможно в Microsoft все делают как-то неправильно и не концептуально, но люди как-то до сих пор обходились и обходятся. Уж не знаю что представляют из себя эти мифические "полноценные SPA приложения", но в реале дело не уходит дальше банального дешбоарда или десяти формочек с кнопочками, привязанных к страничной навигации. И мне очень смешит и одновременно нервирует, когда люди, имеющие в кармане язык с динамической типизацией, говорят о концептуальности использования Redux. Более того, я из области бекенда. Долгое время у нас был JavaEE, на смену которому постепенно пришел Spring. И нам как бы хватает — там есть все, что нужно для типового проекта. Почему же во фронтэнде нет такого инструмента, включающего в себя все необходимое? Уж извините за излишнюю резкость.
Ой ли? На фронтенд даже не постеснялись притащить целый браузер ввиде электрона ради поделки с парой кнопочек. Вот недавняя статья на этот счет. Веб приложения постоянно пухнут, нещадно жрут память и тормозят, при всем том, что их функциональность особо сильно не меняется. И это как бы никого не волнует. Никто не стесняется ради красивой кнопочки подключать сразу всю библиотеку, или ради пары иконок тащить весь фонт.
Так что причина не в этом, а в том, что это вся экосистема JS — это куча мелких говноподелок, склепанных школьниками на коленках. А все, более-менее серьезное в JS было сделано крупными компаниями для внутреннего использования и щедро подарено в оперсорс.
Причина того, что нет более-менее нормального стандартизованного стека технологий разработки. Spring я привел лишь в качестве примера, я сам его недолюбливаю. Однако он интегрируется практически со всеми технологиями, предлагает простой уровень абстракций для управления, и прямо из коробки годен практически для любого проекта. Сегодня пишут на спринге, и завтра тоже будут писать на нем.
Во фронтэнде же не существует более-менее универсального стека разработки. Сегодня есть 50 технологий, хреново интегрирующихся между собой, завтра их будет 150. Вчера был ангуляр, сегодня реакт, завтра какой-нибудь Vue.js или еще 10 других. Вы никогда не поспеете за всем этим. К тому же ваше рабочее время будет тратиться на изучение всего этого дерьма, вместо того, чтобы решать поставленные задачи. Вот я и говорил выше, что согласно моей практике, за последние 10 лет фронтэнд разработка не стала ни быстрей, ни качественней, ни дешевле, тогда как задачи практически не изменились.
Слегка ужасает, что всё это — не единый стек инструментов (как у того же ms), а более 50 разнообразных инструментов. Даже если каждый из них будет обновляться раз в месяц — это минимум два обновления каждый день!
Именно поэтому двух одинаковых фронтенд-разработчиков не бывает. Один знает 10 фреймворков, второй знает 10 фреймворков, и хорошо если эти множества пересекаются хотя бы мажорными версиями.
Полноценные SPA приложения — это всё те же десять формочек и кнопочек. Принципиально ничего нового в 2018 году в веб не пришло — всё те же асинхронные запросы-ответы, вокруг которых всё крутится. Это _должно_ делаться просто и быстро, а если для этого нужно знать 50 фреймворков — то с индустрией что-то не так.
Полностью с вами согласен, коллега. Причем налицо парадокс — сложность разработки с каждым годом растет гораздо быстрее, чем сложность самих приложений. Интересно, когда же наступит технологическая сингулярность?
минимум два обновления каждый день!
Никто вас не накажет, если не будете обновляться. Можете вообще не обновляться, если все устраивает.
один знает 10 фреймворков, второй знает 10 фреймворков.
Ага, наверное, лучше так: "один написал 10 странных велосипедов, другой написал 10 странных велосипедов".
Thanks.
(PS I am a bit new to this amazing website)
Welcome!
For example, https://github.com/ChristosChristofidis/awesome-deep-learning
(I googled "awesome list deep learning" and took the first link).
Facebook не использует React на основном своем продукте, так как React недостаточно быстрый. Facebook часто зависает на секунд 3-5, когда просто ставишь смайлик. Представляете что было бы, если бы они его на React написали, вообще месяцами бы пришлось ждать?
Это все, что нужно знать про React… А если захочется узнать больше, то… лично я много матерился, когда читал документация, особенно зная, что во Vue это все сделали уже через правильное место.
Выводы:
- Китайцы умеют придумывать слово из трёх букв, которые никто не знает как произносить, но при этом они являются самыми сбалансированными решениями для своих платформ… И у обоих гредет версия 3 в скором будущем, помимо Vue, это ещё Yii.
- Нужно ждать, когда ВКонтакте родит свой фреймворк, так как у них в отличии от Facebook все летает (молчу вообще, что и UX сделан головой, а не тем, чем в Facebook).
P.S. На самом деле в документации React есть одна здравая мысль — это то, что JavaScript нужно учить по сайту Ильи Кантора, там ссылка на английскую версию.
P.P.S. По самой статье, такое впечатление, что человек просто написал все слова, которые знал.
Было бы неплохо перечислить как раз самый минимум, чтобы не пугать начинающих разработчиков.
Как стать React разработчиком в 2018 году