Comments 57
Если смотреть не на загрузки npm, а на тренды Гугла, например, картина за год несколько другая
Google trends
Это по России
вот по миру
Мне кажется картина другая, так как все еще много проектов остается на jquery и видимо переводом проектов на что то более современное никто не занимается.
JQuery прекрасно решает свои задачи в небольших проектах, никто от нее не будет там отказываться. Не везде есть необходимость городить кучу фронтенд наворотов, если все будет прекрасно работать на Bootstrap + JQuery.
Смотреть популярность JQuery в npm не совсем корректно, так как очень часто ее используют без всяких npm — скачали с сайта, прикрутили к шаблону и все работает.
Смотреть популярность JQuery в npm не совсем корректно, так как очень часто ее используют без всяких npm — скачали с сайта, прикрутили к шаблону и все работает.
Вообще удивительно, сколько ацкой жути накручено вокруг, казалось бы, простой как валенок задачи — показать пользователю кусок данных из реляционной БД и дать с этим куском что-нибудь поделать.
Не все в мире CRUD. Почему обязательно из БД? Почему обязательно из реляционной?
Frontend ведь не только и не столько про отображение данных. Это интерфейс между пользователем и машиной на той стороне провода. Через него реализуются механизмы, задуманные дизайнером и UX, сценарии использования, психология и т.д. Красивое отображение табличек тут просто один из компонентов.
Frontend ведь не только и не столько про отображение данных. Это интерфейс между пользователем и машиной на той стороне провода. Через него реализуются механизмы, задуманные дизайнером и UX, сценарии использования, психология и т.д. Красивое отображение табличек тут просто один из компонентов.
Я внезапно осознал, насколько самокритична аббревиатура CRUD — написал что-то, потом прочитал и понял, что это — полная фигня; переписал, но результат остался плачевным; в итоге, плюнул и удалил.
Конечно. Не всё. Но как-то так получается, что почти всё. В процентах 95 случаев кроме фронтенда имеется на другой стороне бэкенд, который оказывается реляционной БД.
Даже если юзер вкушает свой восхитительный экспиренс просмотра ленты с котиками (или кошечками), наполнение ленты всё равно составляется через SQL (или, как вариант, NoSQL). А лайк — это не только обработка жмяканья на сердечко с демонстрацией прикольной анимации, но и INSERT в СУБД.
Поправьте меня, если я не прав, но все фреймворки, которые я видел или про которые слышал, в основе своей так либо иначе являются реализациями MVC. А в конечном счёте сводится к ORM, а там принцип «всё должно быть просто, но откуда весь этот гемор?» во всей красе. «Objects» и «Relations» как два мира, два детства, и поженить их нормально мы не можем. Чем-то похоже на историю с квантовыми теориями гравитации. По отдельности — нормально, а вместе в единое целое не срастается.
Так что реакты, ангуляры, вуи и прочие фигуранты — не конец истории. Тема — вечная, место — проклятое.
Даже если юзер вкушает свой восхитительный экспиренс просмотра ленты с котиками (или кошечками), наполнение ленты всё равно составляется через SQL (или, как вариант, NoSQL). А лайк — это не только обработка жмяканья на сердечко с демонстрацией прикольной анимации, но и INSERT в СУБД.
Поправьте меня, если я не прав, но все фреймворки, которые я видел или про которые слышал, в основе своей так либо иначе являются реализациями MVC. А в конечном счёте сводится к ORM, а там принцип «всё должно быть просто, но откуда весь этот гемор?» во всей красе. «Objects» и «Relations» как два мира, два детства, и поженить их нормально мы не можем. Чем-то похоже на историю с квантовыми теориями гравитации. По отдельности — нормально, а вместе в единое целое не срастается.
Так что реакты, ангуляры, вуи и прочие фигуранты — не конец истории. Тема — вечная, место — проклятое.
крайне редко встречается задача — «показать кусок»
всем нужно решение «как динамично показывать и обновлять ленты информаций и списки»
всем нужно решение «как динамично показывать и обновлять ленты информаций и списки»
Если не кусок, то что? Показать всё? Боюсь, это проблематично.
Впрочем, да, отображение длинных-предлинных списков — та ещё морока. Особенно в вебе. Тут недавно была публикация, что надо бы потихоньку прекращать играться с бесконечно прокручиваемыми динамически подгружаемыми лентами. Что с точки зрения эргономики они не очень.
Впрочем, да, отображение длинных-предлинных списков — та ещё морока. Особенно в вебе. Тут недавно была публикация, что надо бы потихоньку прекращать играться с бесконечно прокручиваемыми динамически подгружаемыми лентами. Что с точки зрения эргономики они не очень.
сколько ацкой жути
Вы слишком толерантны в выражениях. Если писать своими словами — сколько свисто-пер… ок
Скажите, а у habr.com сложный интерфейс и механизмы?
Вот если его писать, надо ангуляр и всё такое?
Это вопрос mcferden но можно и не только
Вот если его писать, надо ангуляр и всё такое?
Это вопрос mcferden но можно и не только
ребята балуются с мобильной версией и пишут на vue.
Мне кажется, что достаточно сложный, чтобы Angular/React/Vue дали разработчикам больше удобства, чем боли.
Тем не менее он вполне обходится одной jQuery, первой версии
Именно это хотел сказать maslyaev, как я понимаю
Зачем усложнять там, где не нужно
Именно это хотел сказать maslyaev, как я понимаю
Зачем усложнять там, где не нужно
Зачем усложнять там, где не нужно
Совершенно верно! Именно поэтому разработчики поступили и взяли простой современный фреймворк.
jQuery – это совсем непросто, слишком много там нужно писать руками, что в других уже сделано за нас.
А как можно в чистом Vue получить, например, ширину элемента? Vue структурирует код, но НЕ облегчает (а в каком то смысле даже усложняет) разработку если бездумно ее использовать везде где можно.
vuejs.org/v2/api/#ref
Можно обратиться к элементу через ref и узнать его ширину
> НЕ облегчает разработку если бездумно ее использовать везде где можно
Правильная мысль, но в неверном контексте. Мы же говорим про Хабр и про его механизм комментариев. Для его реализации Vue смотрится к месту.
Можно обратиться к элементу через ref и узнать его ширину
> НЕ облегчает разработку если бездумно ее использовать везде где можно
Правильная мысль, но в неверном контексте. Мы же говорим про Хабр и про его механизм комментариев. Для его реализации Vue смотрится к месту.
Можно обратиться к элементу через ref
Имеется в виду работать с элементами в стиле Vue — через данные data, методы, watch и пр. Иначе, получается, что обратиться к элементу и работать дальше проще через id с помощью jQuery. К тому же, если мы имеем дело с вложенными компонентами, приходится обращаться также через ref родителей. Да и сами разработчики/разработчик не рекомендуют использовать ref
Дык на JQuery эквивалентные задачи получатся сложнее чем на Vue.
В ситуации, когда нужно получить доступ к dom элементу и работать с ним дальше (что, конечно, довольно часто встречается), Vue скромно передает управление jQuery
Если хотите, можем рассмотреть какую-то конкретную ситуацию. Потому что бывает так, что после Jquery и иже с ним, event-driven мышление просто не может перестроиться на state-driven принципы.
Скажем, нужно нужно задать элементам списка такую максимальную ширину, которая имеется у элементов.
jsfiddle.net/erkesh/7x13Lvku
В этом примере случайно генерируется список. Буду благодарен, если покажете как это решается на чистом Vue (желательно, без использования ref)
jsfiddle.net/erkesh/7x13Lvku
В этом примере случайно генерируется список. Буду благодарен, если покажете как это решается на чистом Vue (желательно, без использования ref)
А вы в курсе, что эта задача решается с помощью css в 3 строки? Удалил все лишнее из вашего фидла: jsfiddle.net/wy4vd9ba
Второй вопрос, почему вы считаете, что не нужно использовать ref, если задача решается с помощью Vue или другого фреймворка? ref'ы это очень удобный, декларативный способ получить элемент и часть функционала фреймворка, а значит их нужно использовать. Не понимаю, почему это имеет какое-то отношение к jquery. Ситуаций когда нужно работать с DOM элементами много и фреймворки не запрещают с ними работать. DOM API фреймворки не отменяют и в тоже время, jquery тут совершенно не нужен.
Я бы решил данную задачу средствами css, но если все же представить, что я действую в предложенных обстоятельствах или же просто любитель извратов, то решение может быть примерно таким (сори, Svelte, вместо Vue, но это ничего особо не меняет): svelte.technology/repl?version=2.16.0&gist=a18f10c19e411d89420629c333629915
Основные отличия моего варианта от вашего (кроме читаемости, поддерживаемости и логического разделения кода) в том, что у меня сразу решаются крайние кейсы, когда элементов нет вообще или когда список элементов был изменен и нужно заново обсчитать ширину. Можете заметить, что мне для обработки данных кейсов даже не пришлось писать какой-то дополнительный код.
В каком месте мне здесь необходим jquery я понять так и не смог, честно говоря. Для вот этой строки что ли?
Рефку я тут мог бы тут и не использовать. Сделал для того, чтобы уйти от id элемента и сузить поиск по DOM дереву лишь поддеревом элемента, на который ссылкается рефка. У вас же, jquery будет лопатить весь DOM в поиске по селектору. В любом случае, чтобы сделать querySelectorAll() мне jquery точно не нужен.
Более того, даже если вам просто нравится императивный js, который вы пишете, вам все равно не нужен jquery. Вот я переписал ваш пример на DOM API, кол-во строки и сложность кода никак не изменились: jsfiddle.net/qbnvswtL
В целом, мне кажется, что я был отчасти прав, насчет event-driven и state-driven мышления и вам стоит задуматься над этим.
Второй вопрос, почему вы считаете, что не нужно использовать ref, если задача решается с помощью Vue или другого фреймворка? ref'ы это очень удобный, декларативный способ получить элемент и часть функционала фреймворка, а значит их нужно использовать. Не понимаю, почему это имеет какое-то отношение к jquery. Ситуаций когда нужно работать с DOM элементами много и фреймворки не запрещают с ними работать. DOM API фреймворки не отменяют и в тоже время, jquery тут совершенно не нужен.
Я бы решил данную задачу средствами css, но если все же представить, что я действую в предложенных обстоятельствах или же просто любитель извратов, то решение может быть примерно таким (сори, Svelte, вместо Vue, но это ничего особо не меняет): svelte.technology/repl?version=2.16.0&gist=a18f10c19e411d89420629c333629915
Основные отличия моего варианта от вашего (кроме читаемости, поддерживаемости и логического разделения кода) в том, что у меня сразу решаются крайние кейсы, когда элементов нет вообще или когда список элементов был изменен и нужно заново обсчитать ширину. Можете заметить, что мне для обработки данных кейсов даже не пришлось писать какой-то дополнительный код.
В каком месте мне здесь необходим jquery я понять так и не смог, честно говоря. Для вот этой строки что ли?
const items = this.refs.list.querySelectorAll('li .alignment');
Рефку я тут мог бы тут и не использовать. Сделал для того, чтобы уйти от id элемента и сузить поиск по DOM дереву лишь поддеревом элемента, на который ссылкается рефка. У вас же, jquery будет лопатить весь DOM в поиске по селектору. В любом случае, чтобы сделать querySelectorAll() мне jquery точно не нужен.
Более того, даже если вам просто нравится императивный js, который вы пишете, вам все равно не нужен jquery. Вот я переписал ваш пример на DOM API, кол-во строки и сложность кода никак не изменились: jsfiddle.net/qbnvswtL
В целом, мне кажется, что я был отчасти прав, насчет event-driven и state-driven мышления и вам стоит задуматься над этим.
Более того, даже если вам просто нравится императивный js, который вы пишете, вам все равно не нужен jquery. Вот я переписал ваш пример на DOM API, кол-во строки и сложность кода никак не изменились: jsfiddle.net/qbnvswtL
При этом вы сэкономили бы 30Кб gzip+minified кода (!!!), который вы доставляете своим пользователям. Да у меня целые приложения на Svelte весят меньше, чем один только jquery, который вы тащите на страницу, чтобы создать пару элементов и добавить пару классов.
Наверное, я плохо изложил задачку.
jsfiddle.net/wy4vd9ba
Здесь элементы занимают всю ширину
Задача стояла найти максимальную ширину из элементов и сделать все элементы такой ширины.
jsfiddle.net/wy4vd9ba
Здесь элементы занимают всю ширину
Задача стояла найти максимальную ширину из элементов и сделать все элементы такой ширины.
И что? Вся ширина списка будет равна ширине самого длинного элемента списка. Поэтому результат точно такой же, разве нет?
Для полноты картины, вариант решения этой же задачи на Svelte 3 (альфа-версия):
v3.svelte.technology/repl?version=3.0.0-alpha12&gist=4ec3fcd2d92dc763c57845b91bcc98fa
Для полноты картины, вариант решения этой же задачи на Svelte 3 (альфа-версия):
v3.svelte.technology/repl?version=3.0.0-alpha12&gist=4ec3fcd2d92dc763c57845b91bcc98fa
Поэтому результат точно такой же, разве нет?
Нет. Не список должен адаптироваться под элементы, а наоборот. Конечно, если этим списком все и ограничивается, можно обойтись одним лишь css.
Вариант на Svelte очень лаконичен. Стоит присмотрется к этому фреймворку
Нет. Не список должен адаптироваться под элементы, а наоборот.
Не очень понял. В обоих случаях, все элементы списка подсвечиваются ровно на длину самого длинного элемента данного списка. Сам список никуда не подстраивается. Более короткие элементы подстраиваются под более длинный, это да. Но ровно такой же результат дает и CSS вариант.
Вариант на Svelte очень лаконичен. Стоит присмотрется к этому фреймворку
Если используете телеграм, велком — @sveltejs.
Я, кажется, снова неправильно выразился. Чтобы было понятней, переписал свой пример.
jsfiddle.net/pmvj1g9L
Списки не имеют фиксированной длины. Элементы списка выравниваются, как предыдущем примере, по максимальному значению. Для пущей убедительности думал добавить также присваивание максимальной высоты и расположение списков произвольно — по горизонтали, вертикали. Но, это, на мой взгляд, излишне.
jsfiddle.net/pmvj1g9L
Списки не имеют фиксированной длины. Элементы списка выравниваются, как предыдущем примере, по максимальному значению. Для пущей убедительности думал добавить также присваивание максимальной высоты и расположение списков произвольно — по горизонтали, вертикали. Но, это, на мой взгляд, излишне.
Все равно не понял. Результат работы вашего кода и css решения лишь в том, что в ваше случае списки всегда пытаются забрать всю ширину (не больше максимально установленной конечно), а в моем решении списки имеют ширину максимального элемента списка.
Хорошо это можно увидеть, если «раскрасить» элементы списков красным:
Ваш вариант:
Вариант в 3 строки CSS:
Извините, но пока профит от того, что списки имеют одинаковую ширину и не зависят от контента не понятен. Если подразумевается, что сам список имеет визуальное представление, например, рамку или тень, тогда еще можно согласиться. Хотя даже в этом случае, я бы не стал писать javascript, который лопатить списки, а использовал бы дополнительный div-элемент для блока.
Кстати, для второго списка ширина почему-то не обсчиталась у вас.
Хорошо это можно увидеть, если «раскрасить» элементы списков красным:
Ваш вариант:
Вариант в 3 строки CSS:
Извините, но пока профит от того, что списки имеют одинаковую ширину и не зависят от контента не понятен. Если подразумевается, что сам список имеет визуальное представление, например, рамку или тень, тогда еще можно согласиться. Хотя даже в этом случае, я бы не стал писать javascript, который лопатить списки, а использовал бы дополнительный div-элемент для блока.
Кстати, для второго списка ширина почему-то не обсчиталась у вас.
В статье много раз упоминается github, однако почему-то пропущена история о том что github как раз в сентябре 2018 полностью избавился от jQuery на фронтенде: githubengineering.com/removing-jquery-from-github-frontend. Тоже вполне себе один из итогов года.
ценой отказа от кучи совместимостей, что наглядно показало — зачем нужно JQuery и библиотеки
у меня есть машина с Firefox 56 и там перестал работать ряд функций на фронтенде гитхаба. Ребята так быстро бегут в будущее, что отбрасывают доступ в браузеры почти годичной давности — смелый, очень смелый шаг.
у меня есть машина с Firefox 56 и там перестал работать ряд функций на фронтенде гитхаба. Ребята так быстро бегут в будущее, что отбрасывают доступ в браузеры почти годичной давности — смелый, очень смелый шаг.
Мир веб-разработки развивается невероятно быстро
Мир
Технология CSS-in-JS получает всё большее распространение
Мое личное мнение, что это уже какое-то бездумное извращение. Код ради кода. При использовании классов, вы просто перейдете в файл стилей и поправите стили к классу, как ваша душа пожалает. Без всяких танцев с бубном. А при подходе, пишем все прямо в коде стилями, в случае чего, придется шариться по всему коду и править его! Ну прямо «очень удобно, стильно и молодежно»! Особенно дебажить это все будет очень «весело».
Всю жизнь программисты боролись за разделение логики, бэка, фронта и стилей. И до чего мы в итоге докатились? Все шарашим вместе в едином файле, грубо говоря. Не удивлюсь, если завтра появятся трансляторы из JS в С++. Начнут системы и драйвера писать на JS.
Не знаю, кто во всем этом видит развитие, но я вижу полную деградацию.
П.С. JS и React знаю на отлично. Но JS ненавижу! Просто нет другого выхода.
Если вы знаете React отлично, то для вас не секрет, что React поощряет разделение приложения на компоненты, а компоненты на еще более маленькие компоненты, чем меньше компоненты, тем больше выигрыш в производительности. Если вы стремитесь следовать этой декомпозиции, то придете к тому, что большинство компонент будут требовать буквально парочку css классов. Выносить 5-10 строк в отдельный файл — это красиво, но не практично. Каждый раз создавая компонент, создавать для него index.js, styles.css, template.jsx становится очень утомительным для рядовых разработчиков, все чаще хочется написать эти 5 строк стилей прямо в MyComponent.js
При разделении компоненты на отдельные файлы, вы должны позаботиться о грамотной файловой структуре приложения. Вы ведь не хотите чтобы быстрый поиск в вашей IDE стал менее удобным? А теперь подумайте, если стили хранятся в styles.css или код компоненты в index.js, быстрый поиск файла должен включать в себя и название каталога. А открыв несколько файлов стилей вы получите в IDE несколько открытых styles.css, если ваша IDE еще и не отображает путь к файлу, то найти нужный становится сомнительным удовольствием. Если вы исправляете эту проблему более информативными наименованиями файлов стилей, пример: MyComponentStyles.css, то нарушаете принцип чистого кода о наименованиях, извиняюсь, но не вспомню точную формулировку.
Теперь давайте вспомним про шум вокруг JSX. JS сообщество было очень недовольно тем что смешали JS и Html, основным доводом были либо ваше субъективное
Теперь о CSS-in-JS. Давайте говоря об этом думать не о css, а о различных sass, less, postcss, stylus… Все это — попытки дать css какие-либо возможности ЯП. Сперва придумывается новый css ЯП, затем его нужно изучить, затем появляется что-то лучшее, опять учить. Появление CSS-in-JS это вполне логичный шаг если собрать весь предыдущий опыт и попытаться сделать все правильно. Теперь мы можем стилизировать компоненты на понятном нам языке, а не изучать очередной ЯП для css.
Vue в этом плане видится мне эталоном, все в одном файле компоненты, с четкими границами где что должно быть.
При разделении компоненты на отдельные файлы, вы должны позаботиться о грамотной файловой структуре приложения. Вы ведь не хотите чтобы быстрый поиск в вашей IDE стал менее удобным? А теперь подумайте, если стили хранятся в styles.css или код компоненты в index.js, быстрый поиск файла должен включать в себя и название каталога. А открыв несколько файлов стилей вы получите в IDE несколько открытых styles.css, если ваша IDE еще и не отображает путь к файлу, то найти нужный становится сомнительным удовольствием. Если вы исправляете эту проблему более информативными наименованиями файлов стилей, пример: MyComponentStyles.css, то нарушаете принцип чистого кода о наименованиях, извиняюсь, но не вспомню точную формулировку.
Теперь давайте вспомним про шум вокруг JSX. JS сообщество было очень недовольно тем что смешали JS и Html, основным доводом были либо ваше субъективное
Всю жизнь программисты боролись за разделение логики, бэка, фронта и стилей.либо о нарушении Single Responsibility принципа. В первом случае да, так и было, но не забывайте о том что долгое время JS был просто скриптом для веб разработки, инструментом для анимации меню. Но язык развивается, развиваются и инструменты вокруг языка, сегодня мы пишем на JS приложения не уступающие десктопным и логично будет предположить, что старые ценности должны остаться в прошлом, а не мешать развитию и будущему языка. Второй довод в корне некорректен т.к. разделение компонент на разметку, стили и код не является Single Responsibility принципом, и объединение их в один файл не является нарушением этого принципа. Код, разметка и стиль компоненты являются единым целым, они не должны существовать отдельно. Если вы хотите возразить DRY принципом, то имейте в виду, если мы говорим о React, то DRY реализуется здесь при помощи HOC или RenderProps, а не импортом стилей из других компонентов.
Теперь о CSS-in-JS. Давайте говоря об этом думать не о css, а о различных sass, less, postcss, stylus… Все это — попытки дать css какие-либо возможности ЯП. Сперва придумывается новый css ЯП, затем его нужно изучить, затем появляется что-то лучшее, опять учить. Появление CSS-in-JS это вполне логичный шаг если собрать весь предыдущий опыт и попытаться сделать все правильно. Теперь мы можем стилизировать компоненты на понятном нам языке, а не изучать очередной ЯП для css.
Vue в этом плане видится мне эталоном, все в одном файле компоненты, с четкими границами где что должно быть.
React поощряет разделение приложения на компоненты, а компоненты на еще более маленькие компоненты
На сколько я помню, то есть глупые компоненты, а есть умные. И если прогер разрабатывает, не какой-то там бложик или сайт новостей, а что-то более сложное с серьезной фронтовой логикой, то он должен был сталкиваться с ситуацией, что сотня мелких тупых компонентов — это адов трэш, который ухудшает понимание работы логики приложения и обслуживания этого зоопарка, чем ряд толстоватых умных компонентов, где код на виду и легко читается. Очень часто, попытка разбить один логический компонент на кучу маленьких, приводит к абсолютно не нужному переусложнению кода (привет миллионы пропсов).
чем меньше компоненты, тем больше выигрыш в производительности
Каждая инициализация нового компонента — это затратная операция и для процессора и для памяти. И если будет проверка производительности на загрузке одного громадного компонента и миллиона маленьких, то один отработает быстрее. По моему — это вполне очевидно. Это, кстати, касается любого ЯП. Суть дробления не в скорости, а в построении абстрактной архитектуры. Которую легче обслуживать и переиспользовать. В этом, как раз и заключается гибкость компонентного подхода.
Если вы стремитесь следовать этой декомпозиции, то придете к тому, что большинство компонент будут требовать буквально парочку css классов. Выносить 5-10 строк в отдельный файл — это красиво, но не практично. Каждый раз создавая компонент, создавать для него index.js, styles.css, template.jsx становится очень утомительным для рядовых разработчиков, все чаще хочется написать эти 5 строк стилей прямо в MyComponent.js
Дайте угадаю, вы пришли во фронт сразу в Реакт? Вот объясните, зачем для каждого компонента делать отдельный файл стилей? Суть-то не в этом, а в том, чтобы унифицировать подходы к верстке. А значит, файлы стилей будут называться исходя из другой логики, например: buttons.scss, fonts.scss, colors.scss и так далее.
Идем дальше, приведу два варианта, вот применили вы ко всем кнопкам в проекте с тысячей компонент класс кнопки: className='btn btn-color-green' — это первый вариант. И второй — вы решили это сделать прямо в коде: style={my-style-variable}.
Теперь возникла ситуация, вот же незадача, заказчик прибежал с криком, что зеленый цвет кнопки не такой, как в шаблоне. Нужно срочно поменять цвет на более темный.
В перовом случае вы просто зайдете в файл: buttons.scss и поправите значение бэкграунда в классе btn-color-green. Во втором случае, вы начнете рассказывать заказчику, что это очень долго и дорого. Что нужно править все тысячи файлов компонент, так как значение является константой в самой компоненте.
Каждый раз создавая компонент, создавать для него index.js, styles.css, template.jsx становится очень утомительным для рядовых разработчиков
Мы точно пишем на одном и том же с вами Реакте? Зачем вы используете index.js? А стили вы где храните? Прямо в компоненте или в ассетах? Как я написал выше, верстка создается универсальной. Именно по этому в свое время был очень популярен бутстрап фреймворк от Твитер.
Теперь давайте вспомним про шум вокруг JSX. JS сообщество было очень недовольно тем что смешали JS и Html
Отделить html от логики невозможно в принципе. Хоть от JS, хоть от другого серверного ЯП. Поэтому рождение JSX — это неизбежное развитие всего этого геморроя, который породило рождение браузерной спецификации. И этот подход более читаемый и простой, чем в том же Ву.
Но язык развивается, развиваются и инструменты вокруг языка, сегодня мы пишем на JS приложения не уступающие десктопным и логично будет предположить, что старые ценности должны остаться в прошлом, а не мешать развитию и будущему языка.
На счет вашей фразы «JS приложения не уступающие десктопным», я, как человек, который пишет на многих ЯП (Ruby, Python, PHP, Java, JS) более 15 лет, могу со всей уверенностью заявить, что вы сравнили х… й с пальцем. Это касается и скорости/производительности и простоте написания кода и построения архитектуры, и масштабируемости и в простоте поддержки. Сам по себе голый JS — это ничто! Как компьютер без системы, только с голым биосом. Сравнивать его с десктопными ЯП — это очень смело, но наивно.
А что касается развития JS, то не хрена он толком не развивается! Развивается вся хипстерсая хрень вокруг него, чтобы JS перестал выглядеть, как кусок говна на палке. Но это не облегчает, по сути задачу, а только порождает необходимость каждый день изучать все новые и новые «технологии». При чем такие «новые» и «технологичные», что все тоже самое можно написать на Делфи 20-ти летней давности (раз уж зашла речь про равнения на десктопы).
Да, кстати, если вы вдруг не в курсе, то все то, что можно делать с помощью Реакта, можно написать на чистом JS, конечно использую html и стили, так как он без них, как я сказал выше — ноль без палки.
Теперь о CSS-in-JS. Давайте говоря об этом думать не о css, а о различных sass, less, postcss, stylus… Все это — попытки дать css какие-либо возможности ЯП. Сперва придумывается новый css ЯП, затем его нужно изучить, затем появляется что-то лучшее, опять учить. Появление CSS-in-JS это вполне логичный шаг если собрать весь предыдущий опыт и попытаться сделать все правильно. Теперь мы можем стилизировать компоненты на понятном нам языке, а не изучать очередной ЯП для css.
Нет, стили в коде — это не технология и не подход! Это очередная попытка самостоятельно трахнуть себя в задницу. О эффективности я уже писал выше. А теперь напишу еще о том, что когда нужно создать сложную верстку, то в Sass приходится много чего городить, включая логику, миксины, условия и много еще чего. А в случае стиля в коде, придется все это х… явертить прямо в компоненте, при этом сама логика стилей может по количеству кода переплюнуть код логики самого компонента. А еще мы знаем, что дебажить JS — это лютый трэш. Иногда такие баги вылазят, что хрен понимаешь, как это отловить. Но мы же, мля, очень современные и прогрессивные, поэтому еще добавим себе геморроя в виде логики стилей в компоненты. И если словим какую бажину, то будем мужественно тратить на нее десятки часов, чтобы только понять, мы вальнули верстку или логику компоненты.
Итак, подвожу итоги. Первое, что мне приходит в голову, так это то, что изучать фронт вы начали вчера или позавчера. Зачем начали со мной спорить, мне не совсем понятно.
Но дам пару советов:
1) Не стоит документацию, руководство, самоучитель и так далее по программированию воспринимать, как догму! Если только начинаете программировать, тогда нужно от чего-то отталкиваться, но брать это на вооружение, как истину не стоит ни в коем случае. Программирование — профессия творческая, тут нет единого правильного пути. Часто сами разработчики ЯП холиварят друг с другом, как правильно. Единой точки зрения быть не может!
2) Для каждой задачи нужно использовать конкретный и подходящий для нее инструмент. Если нужно писать верстку стилями, нужно учить и CSS и Sass (или другой какой). Писать абсолютно все на удобном для себя ЯП — это путь в говнокодеры, и вступление в ряды очередного безумного адепта конкретного ЯП.
3) Знание ЯП — это ничто! От слова совсем. Знание ЯП не делает никого программистом. Это жуткое заблуждение, что достаточно выучить ЯП и пару решений. Программистов миллионы, которые отлично знают ЯП. А почти весь софт похож на унылое говно. Как так?
4) Хорошим программистом является тот, кто умеет самостоятельно все анализировать, кто может строить алгоритмы любой сложности, тот кто умеет для каждой задачи подобрать самый подходящий инструмент, тот, кто понимает, что самое главное — это АРХИТЕКТУРА, а не ЯП.
Если будет достигнут пункт № 4, то ЯП для специалиста становится уже не важным. Он сможет написать софт на чем угодно. Ведь ЯП — это всего лишь инструмент в опытных руках.
вот применили вы ко всем кнопкам в проекте с тысячей компонент класс кнопки: className='btn btn-color-green'
Это какой-то очень странный для Реакта подход. Обычно все-таки создают компонент Button и везде подключают его, а не передают имена классов.
А еще мы знаем, что дебажить JS — это лютый трэш. Иногда такие баги вылазят, что хрен понимаешь, как это отловить.
Не понимаю, чего вы сложного увидели в отладке JS. Во всех браузерах есть удобные отладчики. А еще на JS-код можно написать юнит-тесты. А вы хоть раз видели, что бы кто-то тестировал SASS-миксины?
Обычно все-таки создают компонент Button и везде подключают его, а не передают имена классов.
Компонент Button — это глупый компонент. Пусть даже у него есть базовая верстка. Есть задача, нужно на странице вывести две кнопки. Одна на ховер не реагирует, вторая становиться объемной. Например, для Ок и Отменить. При этом макеты дизайна еще могут сто раз поменяться. Что будете делать? Таких кнопок в умных компонентах до фига и больше. Желательно, приведите кусок кода. Там пару строк, от силы.
Не понимаю, чего вы сложного увидели в отладке JS.
У вас падает сборщик. В трейсах нет никакой конкретной ошибки, нет никакого указания на компонент и нет никакой строчки кода. Просто огромный поток ошибок сборки ядра. Как будете дебажить?
Одна на ховер не реагирует, вторая становиться объемной. Например, для Ок и Отменить
У нас в библиотеке компонентов на работе сделано так:
<div>
<Button variant="normal">Отменить</Button>
<Button variant="primary">Ok</Button>
</div>Библиотека используется в десятке смежных проектов, всем хватает.
При этом макеты дизайна еще могут сто раз поменяться.
В любой адекватной компании есть фирменный стиль и гайдлайны. Макеты могут меняться сколько угодно, но кнопки там будут все те же, в фирменном стиле.
Просто огромный поток ошибок сборки ядра. Как будете дебажить?
А вы это точно про Javascript? Самая страшная ошибка, которая может там случиться – undefined is not a function с указанием строчки в исходнике. Никаких сложностей.
Библиотека используется в десятке смежных проектов, всем хватает.
Если у вас всего два варианта пропса на все случае жизни и вам хватает, это хорошо. Но бывает до фига ситуаций, когда не хватает. И при чем тут фирменный стиль? Если мы не про сайт визитку говорим, а например про SaaS сервис, где вариантов кнопки может быть миллион (с галочкой, с крестиком, со спиннером, разных цветов, форматов, анимированная, кнопка, как ссылка и т.д.). Вы будете все это городить в компоненте кнопка? Сто пятсот if..else? Так это мы говорим про простую кнопку. Есть более сложные компоненты. Я уже это проходил пару лет назад. Когда из глупого компонента TextField слепили такого монстра, который умеет все: автопоиск, автозаполнение, текст, только цифры, работа с дробными, выпадающий список и миллион еще чего. Пропсов было под сотню, верстки под каждый вариант в самом компоненте больше логики. У всех кто приходил в проект была задача отрефакторить этот ужас. Но все погибали в этом безумном компоненте. И ничего уже сделать было нельзя. Он использовался везде и всюду. Что-то поправили в нем, перестало работать другое, в другом месте.
Так что, ИМХО, все лепить в одном месте (я про стили в классе в том числе) — это очень скользкая дорожка. Хотя я понимаю тех, кто не умеет верстать, а знает только JS. Конечно им проще, и они будут отстаивать этот способ чисто из своих корыстных целей.
А вы это точно про Javascript? Самая страшная ошибка, которая может там случиться – undefined is not a function с указанием строчки в исходнике. Никаких сложностей.
habr.com/post/347458
Вот вам пример компонентов кнопок разных крупных сервисов.
- https://atlaskit.atlassian.com/packages/core/button
- https://polaris.shopify.com/components/actions/button
- https://material-ui.com/demos/buttons/
В большинстве компаний можно встретить аналогичные компоненты. Это как раз на сайтах визитках обычно встречается раздрай по причине излишней креативности маркетинга.
Пропсов было под сотню, верстки под каждый вариант в самом компоненте больше логики.
А CSS-стили здесь причем? Что мешает разбить этот компонент на несколько маленьких?
habr.com/post/347458
Самый заплюсованный комментарий там раскрывает суть. У профессиональных разработчиков с такими вещами трудностей возникать не должно.
Вот вам пример компонентов кнопок разных крупных сервисов.
Это все равно, что Бутстрап в пример привести и сказать, что всем и его хватает. Лично я на Реакте писал форум, аналог phpBB. Кнопок действий было до фига и больше. И явно не цветом они отличались.
А CSS-стили здесь причем? Что мешает разбить этот компонент на несколько маленьких?
Упоротость тимлида, который тоже сам себе что-то вбил в голову и всех нагибал делать только так.
Самый заплюсованный комментарий там раскрывает суть. У профессиональных разработчиков с такими вещами трудностей возникать не должно.Судя по очень многим комментариям на хабре, да и везде тоже, складывается впечатление, что все супер профессионалы во всем, для которых нет никаких трудностей и проблем ни в чем. А как глянешь на их софт (про код я вообще молчу), то в консоли миллион ошибок на проде сыпется. Да и глючит все так, что никакого терпения не хватит с этим работать.
Спор в программировании штука не продуктивная. Вы считаете так, я по другому. Кто-то прочитал рекомендации хипстерской технологии и принял ее за библию. Кто-то берет только то, что действительно нужно, не создавая себе догм и ограничений. Но на что я обратил внимание (это не нашего диалога касается), что чем меньше у человека опыта и знаний, тем он более категоричен и не может привести реальные ситуации возникновения проблем в будущем при конкретном подходе, плюс не может четко аргументировать свою позицию (мол так в книжке написано, значит так и есть). И тот кто знает только один ЯП — очень яростно его защищает (синдром утенка).
Как я говорил ранее, решает архитектура, а не ЯП. Пусть многим такое утверждение не нравится, но это факт. Поэтому есть смысл спорить в построении гибкой и масштабируемой архитектуре, а не о том, как лучше верстать компонент.
Я с вами не согласен. Ваши выводы обо мне не верны, ваши доводы субъективны и агрессивны.
Скажу только, что это было большой ошибкой хабра, разрешать писать комментарии всем. На вашем примере я это осознал в полной мере, спасибо.
Скажу только, что это было большой ошибкой хабра, разрешать писать комментарии всем. На вашем примере я это осознал в полной мере, спасибо.
Я с вами не согласен. Ваши выводы обо мне не верны, ваши доводы субъективны и агрессивны.
Извините, если обидел. Но позиция ваша опять не верна. Уж простите. Не согласны, давайте свои аргументы, я все воспринимаю, и если не прав, я это прямо тут признаю и извинюсь перед вами при всех.
Скажу только, что это было большой ошибкой хабра, разрешать писать комментарии всем.Попахивает авторитаризмом и цензурой. Это плохой звоночек. Если хабра закроет комменты, то все от сюда свалят в тот же день.
На вашем примере я это осознал в полной мере, спасибо.
Я работал на крупном проекте, где бос обычных слов не знал. Его обычный язык — это мат, похлеще, чем у портовых грузчиков. Если вас начнет прессовать за косяки в проекте тимлид, то что вы будете делать? Запретите его, прикончите его или на себя руки наложите? Программирование (которое не хобби по вечерам после основной работы) — это боль, нет, не так — это БОЛЬ! Это вечные стрессы и погоня за розовым пони. Поэтому обижаться — это самое непродуктивное, что можно делать в этой профессии. Но дело ваше.
Еще раз сорян. У меня не было цели вас обидеть или унизить.
UFO just landed and posted this here
Это не проблема css-in-js, как раз наоборот, вам нужно хранить конфигурационные значения в теме, и при указании цвета вашей кнопки, использовать значение из темы. Если нужно поменять цвет по требованию дизайнера, вы меняете цвет в теме. Если нужно менять тему динамически, пользователем, тоже самое — даем пользователю или набор тем или доступ к изменению отдельных параметров темы.
Самое ироничное в этом то, что это не React подход, не JS подход, а практика которой уже не один десяток лет, css-in-js дает вам возможность использовать ее безболезненно.
Material UI, кстати предоставляет этот подход из коробки.
Самое ироничное в этом то, что это не React подход, не JS подход, а практика которой уже не один десяток лет, css-in-js дает вам возможность использовать ее безболезненно.
Material UI, кстати предоставляет этот подход из коробки.
UFO just landed and posted this here
Sass и TypeScript не в тему — и то, и другое компилируется во вполне себе стандартные форматы.
CSS-in-JS отрицает использование CSS
Не отрицает. Вы пишите все тот же CSS, со всеми свойствами, ховерами и другими каскадами, только в JS вместо отдельного файла.
всякие React-ы отрицают использование web-компонентов
https://custom-elements-everywhere.com – там показывается, как интегрировать веб-компоненты в свой любимый фреймворк
куча стандартов модулей (ES2015, CommonJS, System, UMD, AMD, RequireJS)
Только ES2015 и CommonJS существуют в данный момент. Остальные – легаси. Да и CommonJS тоже станет устаревшим, как только в Node.js завезут модули без флага.
С такими поправками ситуация, может быть, не будет выглядеть такой печальной.
Это красивая история «Чем занимались JS-библиотеки в 2018 году», а не обзор технологий фронтенда. Напомню, это HTML, CSS и JavaScript, а не React, Angular и Webpack.
Кажется первый спокойный год.
Так слегка конфиг вебпака подправить, посмотреть что нового в тайпскрипте, бабель бету на релиз поменять, посмотреть как там тайпскрипт транспилится — и ты полностью обновился.
Так слегка конфиг вебпака подправить, посмотреть что нового в тайпскрипте, бабель бету на релиз поменять, посмотреть как там тайпскрипт транспилится — и ты полностью обновился.
Sign up to leave a comment.
Фронтенд-2018: итоги года