company_banner

Фронтенд-2018: итоги года

Original author: Trey Huffine
  • Translation
Мир веб-разработки развивается невероятно быстро. То, что вчера было новостью, сегодня уже может устареть, а то, о чём сегодня почти никто не знает, завтра способно стать двигателем прогресса. В материале, перевод которого мы сегодня публикуем, будет рассмотрено всё самое интересное, произошедшее в сфере фронтенда в 2018 году. Речь пойдёт о развитии фреймворков и вспомогательных инструментов, о JavaScript-трендах, а также о том, в каком направлении фронтенд может пойти в 2019-м.



Стандартизация WebAssembly


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

Во второй половине 2017 года разработчики всех ведущих браузеров сообщили о поддержке WebAssembly. Затем, в феврале 2018, произошло 3 важных события: вышла первая версия спецификации WebAssembly, были опубликованы спецификации соответствующего JavaScript-интерфейса и веб-API.

О загрузках популярных фронтенд-библиотек из npm


В первой четвёрке самых популярных фронтенд-модулей, загружаемых из npm, находятся React, jQuery, Angular и Vue. Ниже мы поговорим о ситуации с библиотеками для веб-разработки подробнее.


Загрузки фронтенд-библиотек из npm в 2018 году

React продолжает господствовать в мире фронтенд-библиотек и постоянно развивается


React уже многие годы занимает ведущую позицию в веб-разработке. Масштабы его использования продолжали расти и в 2018. Эта библиотека остаётся одной из самых любимых в среде программистов в соответствии с опросом, проведённым Stack Overflow.

Основная команда разработчиков React весьма активно занимается развитием библиотеки и добавлением в неё новых возможностей. В течение 2018 года можно было видеть появление множества дополнений к React v16, включая новые методы жизненного цикла компонентов, новое API Context, новые события, связанные с указателем мыши, «ленивые» функции, и новый компонент высшего порядка React.memo. Надо отметить, что больше всего внимания было уделено хукам React и API Suspense.

Хуки React были встречены с большим интересом, о них много писали, многим они понравились. Эта технология позволяет добавлять состояние к функциональным компонентам благодаря использованию функции useState, она даёт возможность управлять событиями жизненного цикла компонентов.

Вот видео, в котором продемонстрировано то, как использование хуков позволило значительно улучшить код React-приложения.

Ещё одна интереснейшая новая возможность рассматриваемой библиотеки — React Suspense. Она предназначена для управления загрузкой данных внутри самих React-компонентов. API Suspense позволяет приостановить вывод данных в процессе ожидания завершения асинхронной операции их получения из какого-либо источника. Именно API Suspense используется в «ленивых» функциях для реализации разделения кода компонентов. Основная цель внедрения этой технологии заключается в возможности управлять любыми асинхронными загрузками данных, такими, как запросы к различным API. Кроме того, API Suspense позволяет кэшировать ответы на запросы.

Существует специально сконструированный пример, который демонстрирует множество индикаторов загрузки данных на странице, отображаемых до тех пор, пока флаги isFetching установлены в true. Благодаря API Suspense у разработчика есть средства управления пользовательским интерфейсом, в частности — эти средства могут использоваться для указания того, что должно выводиться на экране в процессе ожидания загрузки данных, для установки времени ожидания, для настройки навигации. Есть даже распространённое мнение, в соответствии с которым API Suspense способно устранить необходимость в использовании Redux. Из этого выступления Дэна Абрамова можно узнать о разработке приложений с использованием данного API.

Vue продолжает расти, обходя React по количеству звёзд на GitHub


После взрывного роста Vue в 2017 году то же самое продолжилось и в 2018. Этот фреймворк даже обошёл React по количеству звёзд на GitHub.

Хотя веб-разработчики и любят Vue, данный фреймворк всё ещё прилично отстаёт от React и Angular в плане его реального использования. Однако Vue может похвастаться активной пользовательской базой, которая продолжает расти, что даёт надежду на то, что в будущем Vue сыграет значительную роль в веб-разработке.

Эван Ю (создатель Vue) много рассказывает о Vue 3


Vue движется к релизу версии 3.0. В 2018 году создатель фреймворка, Эван Ю, говорил на различных мероприятиях об ожидаемых возможностях фреймворка и писал об этом.

Фреймворк Angular остаётся весьма востребованным, вышел его седьмой релиз


В октябре 2018 вышел седьмой релиз Angular. Этот фреймворк к настоящему моменту претерпел значительное развитие, пройдя путь от MVC-архитектуры до современной системы, использующей компоненты. Его популярность также постоянно растёт.

Хотя у Angular и нет столь же ревностных сторонников, которыми отличаются React и Vue, этот фреймворк всё ещё остаётся популярным в профессиональных проектах. Многие разработчики устают от React, так как при использовании этой библиотеки им приходится принимать массу решений, касающихся выбора дополнительных инструментов, проектирования архитектуры приложений, построения процесса сборки проектов. Angular же, с другой стороны, снимает с разработчика необходимость принимать многие решения, даёт в его распоряжение широко используемые архитектурные шаблоны. Angular — это фреймворк, возможности которого охватывают все нужды разработчика веб-приложений, а соответствующее средство командной строки полностью берёт на себя процесс сборки проекта. Конечно, многие вещи при таком подходе заданы во фреймворке достаточно жёстко. Ещё одним преимуществом использования Angular в профессиональной среде является тот факт, что он рассчитан на применение TypeScript. В результате об Angular можно сказать, что этот фреймворк создал себе имя в среде веб-разработки и продолжает укреплять свои позиции.

Надо отметить, что npm-пакет @angular/core представляет собой новый Angular, а пакет angular — это старый AngularJS.

Вот данные npm по загрузкам в 2018 году пакетов @angular/core, angular, react и vue, а также сведения о состоянии этих проектов из GitHub.


Данные по проектам angular/core, angular, react и vue

Всё больше разработчиков хотели бы изучить GraphQL, но эта технология пока не обошла REST


Технология GraphQL нашла применение в некоторых крупных проектах вроде GitHub, но она не распространилась пока достаточно широко. В соответствии с исследованием State of JS — лишь немногим более 20% фронтенд-разработчиков пользовались технологией GraphQL, однако показатель, характеризующий тех, кто о ней слышал и планирует её использовать, составляет впечатляющие 62.5%.


Технология GraphQL

Технология CSS-in-JS получает всё большее распространение


При анализе среды веб-разработки возникает такое ощущение, что она находится на пути унификации абсолютно всего с использованием JavaScript. Эта тенденция видна и в применении к технологии CSS-in-JS, при использовании которой стили создаются с помощью инструментов JS для работы со строками. Это позволяет работать со стилями и зависимостями, используя обычный синтаксис JS и механизмы импорта и экспорта. Кроме того, это упрощает динамическую стилизацию, так как компоненты, использующие CSS-in-JS, способны преобразовывать свойства в стили. Ниже приведены примеры обычного CSS-кода и CSS-in-JS.

Для управления динамическими стилями средствами обычного CSS нужно работать с именами классов в компоненте и обновлять их, основываясь на состоянии и свойствах. Кроме того, для разных вариантов стилизации, нужно пользоваться CSS-классами:

// JS- код компонента
const MyComp = ({ isActive }) => {
  const className = isActive ? 'active' : 'inactive';
  return <div className={className}>HI</div>
}
// Содержимое CSS-файла
.active { color: green; }
.inactive { color: red; }

Благодаря использованию CSS-in-JS применять CSS-классы больше не нужно. Достаточно передать соответствующее свойство стилизованному компоненту, который реализует динамическую стилизацию. Код выходит гораздо более чистым, мы получаем более чёткое разделение задач между стилями и React, позволяя CSS заниматься динамической стилизацией, основанной на свойствах. В React такой код выглядит как вполне обычный JavaScript:

const Header = styled.div`
  color: ${({ isActive }) => isActive ? 'green' : 'red'};
`;
const MyComp = ({ isActive }} => (
  <Header isActive={isActive}>HI</Header>
)

Для реализации возможностей CSS-in-JS используются, в основном, такие библиотеки, как styled-components и emotion. Библиотека Styled components существует дольше Emotion, она получила более широкое распространение, но популярность Emotion быстро растёт, многие разработчики выбирают именно её. Надо отметить, что Кент С. Доддс даже прекратил работу над своей CSS-in-JS-библиотекой Glamorous, отдав предпочтение Emotion. Вот как выглядят библиотеки Styled components и Emotion с точки зрения npm и GitHub.


Библиотеки Styled components и Emotion в 2018

Фреймворк Vue поддерживает локальный CSS при использовании однофайловых компонентов без применения дополнительных библиотек. Для этого достаточно просто добавить свойство scoped к тегу компонента style, после чего Vue задействует технологию CSS-in-JS для организации работы с локальными стилями, которые не выходят за пределы компонента и не попадают в другие компоненты.

Кроме того, надо отметить, что и в Angular, по умолчанию, посредством технологии view encapsulation, используется ограничение области видимости CSS.

Разработчики, борясь с «усталостью» от технологий, находят спасение в инструментах командной строки


Всем известно то, насколько выматывающим может быть наблюдение за постоянно обновляющимися библиотеками, жизненно важными для веб-проектов, а также правильное обновление проектов с учётом обновлений библиотек и принятие в таких условиях правильных архитектурных решений. Эта проблема стала катализатором разработки инструментов командной строки, которые решают подобные вопросы, позволяя программистам сосредоточиться на работе над приложениями. Все эти инструменты стали основным средством, с помощью которых в 2018 году создаются новые приложения. В частности, в этой сфере можно отметить следующие проекты: Next.js (SSR для React), Create-React-App (создание клиентских React-приложений), Nuxt.js (SSR для Vue), Vue CLI (клиентские Vue-приложения), Expo CLI для React Native, стандартные средства Angular.

Стремление разработчиков к упрощению фронтенда и к повышению производительности привело к росту популярности генераторов статических сайтов


Во время бурного, революционного развития JavaScript всем нравилось изучать новейшие библиотеки и применять их на практике. Однако сейчас, когда всё более или менее стабилизируется, разработчики начали понимать, что далеко не все сайты должны представлять собой сложные одностраничные приложения (SPA). Это понимание привело к появлению, росту и развитию генераторов статических сайтов. Благодаря им можно разрабатывать проекты с использованием различных фронтенд-инструментов, вроде React или Vue, которые потом, в ходе сборки, преобразуются в статические HTML-файлы. Это позволяет очень быстро отдавать клиентам уже полностью готовые страницы.

Статические сайты хороши тем, что они представляют собой идеальную комбинацию простоты и производительности. Если HTML-файлы формируются во время сборки проекта, это даёт возможность отправлять пользователям готовые страницы, которые загружаются практически мгновенно, не прибегая при этом ни к серверному, ни к клиентскому рендерингу. Вместе с HTML-кодом клиент загружает и необходимые для работы страницы JS-файлы, что даёт пользователям те же возможности, что и обычные одностраничные приложения.

Генераторы статических сайтов отлично подходят для создания чего-то вроде личных сайтов или блогов, но их можно использовать и в более крупных проектах. В 2018 году можно было наблюдать рост популярности таких генераторов, как Gatsby и React Static для React-приложений, и таких инструментов, как VuePress, для проектов, основанных на Vue. На самом деле, статические сайты стали настолько популярными, что опенсорсный проект Gatsby вырос в компанию и получил венчурные инвестиции.

Бессерверные архитектуры и JAMStack


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

Движение в сторону бессерверности было расширено благодаря методике разработки веб-проектов JAMStack (J — это JavaScript, A — это API, M — это Markup, то есть — разметка). В основе JAMStack лежат концепции разработки статических сайтов, о которых мы говорили в предыдущем разделе. Эта методика позволяет добиться чрезвычайно высоких скоростей загрузки сайтов за счёт заранее сформированной разметки. На клиенте такие сайты превращаются в динамические SPA благодаря применению специальных серверных API. В 2018 даже прошёл, под эгидой freeCodeCamp, Netlify и GitHub, первый JAMStack-хакатон. Вот материал, в котором продемонстрированы особенности использования архитектуры JAM на freecodecamp.com, который позволяет оценить возможности разработки крупномасштабных приложений с применением методики JAMStack.

Возможно, TypeScript — это будущее JS, но то же самое нельзя сказать о Flow


JavaScript часто критикуют за отсутствие статической типизации. Основными средствами для решения этой проблемы являются TypeScript и Flow. При этом TypeScript гораздо популярнее Flow, и, на самом деле, исследование Stack Overflow показало, что разработчики любят TypeScript даже больше чем сам JavaScript (соответствующие показатели для этих языков составляют 67% и 61.9%). В соответствии с исследованием State of JS, более 80% разработчиков либо планируют использовать TS, либо уже с удовольствием его применяют. Если говорить о Flow, то пользуются им, или хотят им пользоваться, лишь 34% разработчиков.

Судя по всем показателям, TypeScript представляет собой стандартное решение для статической типизации в JS, многие отдают предпочтение TS перед обычным JavaScript. В этом году число загрузок TS в npm постоянно и существенно росло, в то время как график загрузок Flow оставался довольно-таки плоским. Возникает такое ощущение, что TypeScript, из инструмента, которым пользовались лишь ярые приверженцы статической типизации, становится чрезвычайно широко используемым средством веб-разработки. Вот данные по TypeScript и Flow (в виде babel-preset-flow) из npm и GitHub.


Загрузки TypeScript и Flow во второй половине 2018 года

В начале 2018 года был выпущен Webpack 4


Webpack 4 вышел всего через 8 месяцев после релиза Webpack 3. В новой версии Webpack сохранилось движение в сторону упрощения работы и ускорения процесса сборки. Иногда производительность Webpack 4 может превышать производительность Webpack 3 на 98%. Webpack 4 нацелен на использование разумно подобранных параметров по умолчанию, поддерживает больше возможностей без необходимости подключения плагинов, при этом для того, чтобы приступить к использованию Webpack, больше необязательно сначала готовить конфигурационный файл. Кроме того, теперь Webpack поддерживает WebAssembly и позволяет напрямую импортировать WebAssembly-файлы.

Вышел Babel 7.0


Babel 7 вышел в 2018 году — после почти трёх лет, прошедших с выхода Babel 6. Babel — это библиотека, средствами которой транспилируется JavaScript-код, в котором используются возможности свежих стандартов (ES6+), в ES5-код, что позволяет обеспечивать кросс-браузерную совместимость JS-проектов. Материал, в котором сообщается о выходе новой версии Babel, указывает на то, что Babel 7 стал быстрее, современнее, поддерживает расширенные возможности конфигурирования, обладает улучшенным функционалом, касающимся минификации, поддерживает технологии JSX Fragments и TypeScript, новые языковые конструкции, находящиеся на ранних стадиях согласования, и многое другое. Надо отметить, что пакеты Babel в npm теперь используют пространство имён @babel.

Важные публикации 2018 года


Рассмотрим несколько значительных публикаций, вышедших в 2018 году.

  • Вот материал о том, какую цену приходится платить за использование JavaScript в 2018 году.
  • Вот публикация, сделанная по итогам мероприятия React Conf, из которой можно узнать о будущем React.
  • В этой статье Airbnb делится опытом работы с React Native, приобретённым компанией за 2 года.
  • Здесь Google демонстрирует всем желающим устройство Google Photos Web UI.
  • Тут можно почитать о том, что Microsoft собирается перевести браузер Edge на платформу Chromium.
  • А вот весьма интересное выступление Райана Даля, создателя Node.js.

Прогноз на 2019 год


Что ждёт фронтенд в 2019 году? Вот наш прогноз:

  • WebAssembly станет всё чаще встречаться в веб-проектах благодаря непрестанному развитию этой технологии, стандартизации и стремлению разработчиков к производительности.
  • React всё так же будет возглавлять рейтинг инструментов для веб-разработки, в то время как Vue и Angular будут продолжать наращивать пользовательскую базу.
  • Технология CSS-in-JS может стать стандартным подходом к стилизации, заменив обычный CSS.
  • Возможно, разработчики обратят внимание на стандартные веб-компоненты.
  • Производительность, что неудивительно, по-прежнему будет притягивать к себе всеобщее внимание. Это говорит о том, что прогрессивные веб-приложения (PWA) и технологии разделения кода будут применяться в подавляющем большинстве веб-проектов.
  • Благодаря распространению и развитию PWA веб-проекты будут плотнее интегрированы с возможностями мобильных и настольных устройств, будут предоставлять пользователям полноценные возможности работы без подключения к сети.
  • Продолжится рост и развитие средств командной строки, направленных на то, чтобы освободить разработчиков от необходимости самостоятельной настройки инструментов и дать им возможность спокойно заниматься созданием веб-проектов.
  • Большее количество компаний внедрит мобильные решения, основанные на стандартных технологиях, таких, как React Native или Flutter.
  • Во фронтенд-разработке повысится роль контейнеризации (в частности, речь идёт о Docker и Kubernetes).
  • Произойдёт значительное продвижение GraphQL, эта технология будет использоваться в большем количестве компаний.
  • TypeScript будет рассматриваться уже не как альтернатива обычному JavaScript, а как стандартный выбор в тех ситуациях, в которых раньше обычно выбирали JavaScript.
  • Технологии виртуальной реальности сделают большой шаг вперёд, используя такие библиотеки, как A-Frame, React VR и Google VR.

Уважаемые читатели! Чего вы ждёте от фронтенд-разработки в 2019 году?

RUVDS.com
VDS/VPS-хостинг. Скидка 10% по коду HABR

Comments 57

    0
    Если смотреть не на загрузки npm, а на тренды Гугла, например, картина за год несколько другая
    Google trends
    image
      0
      Это по России
      вот по миру
      image
        0
        Мне кажется картина другая, так как все еще много проектов остается на jquery и видимо переводом проектов на что то более современное никто не занимается.
          +1
          JQuery прекрасно решает свои задачи в небольших проектах, никто от нее не будет там отказываться. Не везде есть необходимость городить кучу фронтенд наворотов, если все будет прекрасно работать на Bootstrap + JQuery.
          Смотреть популярность JQuery в npm не совсем корректно, так как очень часто ее используют без всяких npm — скачали с сайта, прикрутили к шаблону и все работает.
      –1
      Вообще удивительно, сколько ацкой жути накручено вокруг, казалось бы, простой как валенок задачи — показать пользователю кусок данных из реляционной БД и дать с этим куском что-нибудь поделать.
        –1
        Не все в мире CRUD. Почему обязательно из БД? Почему обязательно из реляционной?

        Frontend ведь не только и не столько про отображение данных. Это интерфейс между пользователем и машиной на той стороне провода. Через него реализуются механизмы, задуманные дизайнером и UX, сценарии использования, психология и т.д. Красивое отображение табличек тут просто один из компонентов.
          +2
          Я внезапно осознал, насколько самокритична аббревиатура CRUD — написал что-то, потом прочитал и понял, что это — полная фигня; переписал, но результат остался плачевным; в итоге, плюнул и удалил.
            0
            как и вся наша никчемная жизнь
              0
              «Я есть CRUD» ©
              +1
              Конечно. Не всё. Но как-то так получается, что почти всё. В процентах 95 случаев кроме фронтенда имеется на другой стороне бэкенд, который оказывается реляционной БД.
              Даже если юзер вкушает свой восхитительный экспиренс просмотра ленты с котиками (или кошечками), наполнение ленты всё равно составляется через SQL (или, как вариант, NoSQL). А лайк — это не только обработка жмяканья на сердечко с демонстрацией прикольной анимации, но и INSERT в СУБД.

              Поправьте меня, если я не прав, но все фреймворки, которые я видел или про которые слышал, в основе своей так либо иначе являются реализациями MVC. А в конечном счёте сводится к ORM, а там принцип «всё должно быть просто, но откуда весь этот гемор?» во всей красе. «Objects» и «Relations» как два мира, два детства, и поженить их нормально мы не можем. Чем-то похоже на историю с квантовыми теориями гравитации. По отдельности — нормально, а вместе в единое целое не срастается.

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

                +2
                Если не кусок, то что? Показать всё? Боюсь, это проблематично.
                Впрочем, да, отображение длинных-предлинных списков — та ещё морока. Особенно в вебе. Тут недавно была публикация, что надо бы потихоньку прекращать играться с бесконечно прокручиваемыми динамически подгружаемыми лентами. Что с точки зрения эргономики они не очень.
                  0

                  Если не кусок, то много маленьких кусочков в неизвестном заранее количестве по неизвестным заранее параметрам, да побыстрее. Я, по крайней мере, понял так.

                    0
                    И изменение одного маленького куска влияет сразу на несколько других маленьких кусков, которые, возможно, тоже на что-то влияют, плюс посылает асинхронный запрос.
                +2
                сколько ацкой жути

                Вы слишком толерантны в выражениях. Если писать своими словами — сколько свисто-пер… ок
                +1
                Скажите, а у habr.com сложный интерфейс и механизмы?
                Вот если его писать, надо ангуляр и всё такое?

                Это вопрос mcferden но можно и не только
                  0
                  ребята балуются с мобильной версией и пишут на vue.
                    0
                    Мне кажется, что достаточно сложный, чтобы Angular/React/Vue дали разработчикам больше удобства, чем боли.
                      –1
                      Тем не менее он вполне обходится одной jQuery, первой версии
                      Именно это хотел сказать maslyaev, как я понимаю
                      Зачем усложнять там, где не нужно
                        +1
                        Зачем усложнять там, где не нужно

                        Совершенно верно! Именно поэтому разработчики поступили и взяли простой современный фреймворк.


                        jQuery – это совсем непросто, слишком много там нужно писать руками, что в других уже сделано за нас.

                          0
                          А как можно в чистом Vue получить, например, ширину элемента? Vue структурирует код, но НЕ облегчает (а в каком то смысле даже усложняет) разработку если бездумно ее использовать везде где можно.
                            0
                            vuejs.org/v2/api/#ref

                            Можно обратиться к элементу через ref и узнать его ширину

                            > НЕ облегчает разработку если бездумно ее использовать везде где можно

                            Правильная мысль, но в неверном контексте. Мы же говорим про Хабр и про его механизм комментариев. Для его реализации Vue смотрится к месту.
                              0
                              Можно обратиться к элементу через ref

                              Имеется в виду работать с элементами в стиле Vue — через данные data, методы, watch и пр. Иначе, получается, что обратиться к элементу и работать дальше проще через id с помощью jQuery. К тому же, если мы имеем дело с вложенными компонентами, приходится обращаться также через ref родителей. Да и сами разработчики/разработчик не рекомендуют использовать ref
                                +1
                                Нужно осознать, что Vue и другие фреймворки предлагают концепцию непрямого управления HTML. Вы даете фреймворку команду – он ее исполняет. Заниматься микроменеджментом и делать за них работу руками неэффективно. После этого понимания желание залезть в DOM и поменять там что-то руками пропадает.

                          +1
                          Дык на JQuery эквивалентные задачи получатся сложнее чем на Vue.
                            +1
                            В ситуации, когда нужно получить доступ к dom элементу и работать с ним дальше (что, конечно, довольно часто встречается), Vue скромно передает управление jQuery
                              0
                              Если хотите, можем рассмотреть какую-то конкретную ситуацию. Потому что бывает так, что после Jquery и иже с ним, event-driven мышление просто не может перестроиться на state-driven принципы.
                                –1
                                Скажем, нужно нужно задать элементам списка такую максимальную ширину, которая имеется у элементов.
                                jsfiddle.net/erkesh/7x13Lvku
                                В этом примере случайно генерируется список. Буду благодарен, если покажете как это решается на чистом Vue (желательно, без использования ref)
                                  +1
                                  А вы в курсе, что эта задача решается с помощью 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 я понять так и не смог, честно говоря. Для вот этой строки что ли?

                                  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 мышления и вам стоит задуматься над этим.
                                    0
                                    Более того, даже если вам просто нравится императивный js, который вы пишете, вам все равно не нужен jquery. Вот я переписал ваш пример на DOM API, кол-во строки и сложность кода никак не изменились: jsfiddle.net/qbnvswtL


                                    При этом вы сэкономили бы 30Кб gzip+minified кода (!!!), который вы доставляете своим пользователям. Да у меня целые приложения на Svelte весят меньше, чем один только jquery, который вы тащите на страницу, чтобы создать пару элементов и добавить пару классов.
                                      0
                                      Наверное, я плохо изложил задачку.
                                      jsfiddle.net/wy4vd9ba
                                      Здесь элементы занимают всю ширину
                                      Задача стояла найти максимальную ширину из элементов и сделать все элементы такой ширины.
                                        0
                                        И что? Вся ширина списка будет равна ширине самого длинного элемента списка. Поэтому результат точно такой же, разве нет?

                                        Для полноты картины, вариант решения этой же задачи на Svelte 3 (альфа-версия):
                                        v3.svelte.technology/repl?version=3.0.0-alpha12&gist=4ec3fcd2d92dc763c57845b91bcc98fa
                                          0
                                          Поэтому результат точно такой же, разве нет?

                                          Нет. Не список должен адаптироваться под элементы, а наоборот. Конечно, если этим списком все и ограничивается, можно обойтись одним лишь css.
                                          Вариант на Svelte очень лаконичен. Стоит присмотрется к этому фреймворку
                                            0
                                            Нет. Не список должен адаптироваться под элементы, а наоборот.

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

                                            Вариант на Svelte очень лаконичен. Стоит присмотрется к этому фреймворку

                                            Если используете телеграм, велком — @sveltejs.
                                              0
                                              Я, кажется, снова неправильно выразился. Чтобы было понятней, переписал свой пример.
                                              jsfiddle.net/pmvj1g9L
                                              Списки не имеют фиксированной длины. Элементы списка выравниваются, как предыдущем примере, по максимальному значению. Для пущей убедительности думал добавить также присваивание максимальной высоты и расположение списков произвольно — по горизонтали, вертикали. Но, это, на мой взгляд, излишне.
                                                0
                                                Все равно не понял. Результат работы вашего кода и css решения лишь в том, что в ваше случае списки всегда пытаются забрать всю ширину (не больше максимально установленной конечно), а в моем решении списки имеют ширину максимального элемента списка.

                                                Хорошо это можно увидеть, если «раскрасить» элементы списков красным:

                                                Ваш вариант:


                                                Вариант в 3 строки CSS:


                                                Извините, но пока профит от того, что списки имеют одинаковую ширину и не зависят от контента не понятен. Если подразумевается, что сам список имеет визуальное представление, например, рамку или тень, тогда еще можно согласиться. Хотя даже в этом случае, я бы не стал писать javascript, который лопатить списки, а использовал бы дополнительный div-элемент для блока.

                                                Кстати, для второго списка ширина почему-то не обсчиталась у вас.
                        +1
                        В статье много раз упоминается github, однако почему-то пропущена история о том что github как раз в сентябре 2018 полностью избавился от jQuery на фронтенде: githubengineering.com/removing-jquery-from-github-frontend. Тоже вполне себе один из итогов года.
                          –1
                          ценой отказа от кучи совместимостей, что наглядно показало — зачем нужно JQuery и библиотеки

                          у меня есть машина с Firefox 56 и там перестал работать ряд функций на фронтенде гитхаба. Ребята так быстро бегут в будущее, что отбрасывают доступ в браузеры почти годичной давности — смелый, очень смелый шаг.
                          0
                          Мир веб-разработки развивается невероятно быстро


                          Мир СВИСТЕЛОК- веб-разработки развивается невероятно быстро
                            +5
                            Технология CSS-in-JS получает всё большее распространение


                            Мое личное мнение, что это уже какое-то бездумное извращение. Код ради кода. При использовании классов, вы просто перейдете в файл стилей и поправите стили к классу, как ваша душа пожалает. Без всяких танцев с бубном. А при подходе, пишем все прямо в коде стилями, в случае чего, придется шариться по всему коду и править его! Ну прямо «очень удобно, стильно и молодежно»! Особенно дебажить это все будет очень «весело».

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

                            Не знаю, кто во всем этом видит развитие, но я вижу полную деградацию.

                            П.С. JS и React знаю на отлично. Но JS ненавижу! Просто нет другого выхода.
                              +1
                              Если вы знаете 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, основным доводом были либо ваше субъективное
                              Всю жизнь программисты боролись за разделение логики, бэка, фронта и стилей.
                              либо о нарушении 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 в этом плане видится мне эталоном, все в одном файле компоненты, с четкими границами где что должно быть.
                                –1
                                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, то ЯП для специалиста становится уже не важным. Он сможет написать софт на чем угодно. Ведь ЯП — это всего лишь инструмент в опытных руках.
                                  0
                                  вот применили вы ко всем кнопкам в проекте с тысячей компонент класс кнопки: className='btn btn-color-green'

                                  Это какой-то очень странный для Реакта подход. Обычно все-таки создают компонент Button и везде подключают его, а не передают имена классов.


                                  А еще мы знаем, что дебажить JS — это лютый трэш. Иногда такие баги вылазят, что хрен понимаешь, как это отловить.

                                  Не понимаю, чего вы сложного увидели в отладке JS. Во всех браузерах есть удобные отладчики. А еще на JS-код можно написать юнит-тесты. А вы хоть раз видели, что бы кто-то тестировал SASS-миксины?

                                    –1
                                    Обычно все-таки создают компонент Button и везде подключают его, а не передают имена классов.


                                    Компонент Button — это глупый компонент. Пусть даже у него есть базовая верстка. Есть задача, нужно на странице вывести две кнопки. Одна на ховер не реагирует, вторая становиться объемной. Например, для Ок и Отменить. При этом макеты дизайна еще могут сто раз поменяться. Что будете делать? Таких кнопок в умных компонентах до фига и больше. Желательно, приведите кусок кода. Там пару строк, от силы.

                                    Не понимаю, чего вы сложного увидели в отладке JS.

                                    У вас падает сборщик. В трейсах нет никакой конкретной ошибки, нет никакого указания на компонент и нет никакой строчки кода. Просто огромный поток ошибок сборки ядра. Как будете дебажить?
                                      0
                                      Одна на ховер не реагирует, вторая становиться объемной. Например, для Ок и Отменить

                                      У нас в библиотеке компонентов на работе сделано так:


                                      <div>
                                        <Button variant="normal">Отменить</Button>
                                        <Button variant="primary">Ok</Button>
                                      </div>

                                      Библиотека используется в десятке смежных проектов, всем хватает.


                                      При этом макеты дизайна еще могут сто раз поменяться.

                                      В любой адекватной компании есть фирменный стиль и гайдлайны. Макеты могут меняться сколько угодно, но кнопки там будут все те же, в фирменном стиле.


                                      Просто огромный поток ошибок сборки ядра. Как будете дебажить?

                                      А вы это точно про Javascript? Самая страшная ошибка, которая может там случиться – undefined is not a function с указанием строчки в исходнике. Никаких сложностей.

                                        0
                                        Библиотека используется в десятке смежных проектов, всем хватает.

                                        Если у вас всего два варианта пропса на все случае жизни и вам хватает, это хорошо. Но бывает до фига ситуаций, когда не хватает. И при чем тут фирменный стиль? Если мы не про сайт визитку говорим, а например про SaaS сервис, где вариантов кнопки может быть миллион (с галочкой, с крестиком, со спиннером, разных цветов, форматов, анимированная, кнопка, как ссылка и т.д.). Вы будете все это городить в компоненте кнопка? Сто пятсот if..else? Так это мы говорим про простую кнопку. Есть более сложные компоненты. Я уже это проходил пару лет назад. Когда из глупого компонента TextField слепили такого монстра, который умеет все: автопоиск, автозаполнение, текст, только цифры, работа с дробными, выпадающий список и миллион еще чего. Пропсов было под сотню, верстки под каждый вариант в самом компоненте больше логики. У всех кто приходил в проект была задача отрефакторить этот ужас. Но все погибали в этом безумном компоненте. И ничего уже сделать было нельзя. Он использовался везде и всюду. Что-то поправили в нем, перестало работать другое, в другом месте.

                                        Так что, ИМХО, все лепить в одном месте (я про стили в классе в том числе) — это очень скользкая дорожка. Хотя я понимаю тех, кто не умеет верстать, а знает только JS. Конечно им проще, и они будут отстаивать этот способ чисто из своих корыстных целей.

                                        А вы это точно про Javascript? Самая страшная ошибка, которая может там случиться – undefined is not a function с указанием строчки в исходнике. Никаких сложностей.

                                        habr.com/post/347458
                                          0

                                          Вот вам пример компонентов кнопок разных крупных сервисов.



                                          В большинстве компаний можно встретить аналогичные компоненты. Это как раз на сайтах визитках обычно встречается раздрай по причине излишней креативности маркетинга.


                                          Пропсов было под сотню, верстки под каждый вариант в самом компоненте больше логики.

                                          А CSS-стили здесь причем? Что мешает разбить этот компонент на несколько маленьких?


                                          habr.com/post/347458

                                          Самый заплюсованный комментарий там раскрывает суть. У профессиональных разработчиков с такими вещами трудностей возникать не должно.

                                            0
                                            Вот вам пример компонентов кнопок разных крупных сервисов.

                                            Это все равно, что Бутстрап в пример привести и сказать, что всем и его хватает. Лично я на Реакте писал форум, аналог phpBB. Кнопок действий было до фига и больше. И явно не цветом они отличались.

                                            А CSS-стили здесь причем? Что мешает разбить этот компонент на несколько маленьких?

                                            Упоротость тимлида, который тоже сам себе что-то вбил в голову и всех нагибал делать только так.

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

                                            Спор в программировании штука не продуктивная. Вы считаете так, я по другому. Кто-то прочитал рекомендации хипстерской технологии и принял ее за библию. Кто-то берет только то, что действительно нужно, не создавая себе догм и ограничений. Но на что я обратил внимание (это не нашего диалога касается), что чем меньше у человека опыта и знаний, тем он более категоричен и не может привести реальные ситуации возникновения проблем в будущем при конкретном подходе, плюс не может четко аргументировать свою позицию (мол так в книжке написано, значит так и есть). И тот кто знает только один ЯП — очень яростно его защищает (синдром утенка).

                                            Как я говорил ранее, решает архитектура, а не ЯП. Пусть многим такое утверждение не нравится, но это факт. Поэтому есть смысл спорить в построении гибкой и масштабируемой архитектуре, а не о том, как лучше верстать компонент.
                                    0
                                    Я с вами не согласен. Ваши выводы обо мне не верны, ваши доводы субъективны и агрессивны.
                                    Скажу только, что это было большой ошибкой хабра, разрешать писать комментарии всем. На вашем примере я это осознал в полной мере, спасибо.
                                      0
                                      Я с вами не согласен. Ваши выводы обо мне не верны, ваши доводы субъективны и агрессивны.

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

                                      Скажу только, что это было большой ошибкой хабра, разрешать писать комментарии всем.
                                      Попахивает авторитаризмом и цензурой. Это плохой звоночек. Если хабра закроет комменты, то все от сюда свалят в тот же день.

                                      На вашем примере я это осознал в полной мере, спасибо.

                                      Я работал на крупном проекте, где бос обычных слов не знал. Его обычный язык — это мат, похлеще, чем у портовых грузчиков. Если вас начнет прессовать за косяки в проекте тимлид, то что вы будете делать? Запретите его, прикончите его или на себя руки наложите? Программирование (которое не хобби по вечерам после основной работы) — это боль, нет, не так — это БОЛЬ! Это вечные стрессы и погоня за розовым пони. Поэтому обижаться — это самое непродуктивное, что можно делать в этой профессии. Но дело ваше.

                                      Еще раз сорян. У меня не было цели вас обидеть или унизить.
                                  • UFO just landed and posted this here
                                      +1
                                      Это не проблема css-in-js, как раз наоборот, вам нужно хранить конфигурационные значения в теме, и при указании цвета вашей кнопки, использовать значение из темы. Если нужно поменять цвет по требованию дизайнера, вы меняете цвет в теме. Если нужно менять тему динамически, пользователем, тоже самое — даем пользователю или набор тем или доступ к изменению отдельных параметров темы.
                                      Самое ироничное в этом то, что это не React подход, не JS подход, а практика которой уже не один десяток лет, css-in-js дает вам возможность использовать ее безболезненно.
                                      Material UI, кстати предоставляет этот подход из коробки.
                                      • UFO just landed and posted this here
                                          0
                                          Sass и TypeScript не в тему — и то, и другое компилируется во вполне себе стандартные форматы.
                                            0
                                            CSS-in-JS отрицает использование CSS

                                            Не отрицает. Вы пишите все тот же CSS, со всеми свойствами, ховерами и другими каскадами, только в JS вместо отдельного файла.


                                            всякие React-ы отрицают использование web-компонентов

                                            https://custom-elements-everywhere.com – там показывается, как интегрировать веб-компоненты в свой любимый фреймворк


                                            куча стандартов модулей (ES2015, CommonJS, System, UMD, AMD, RequireJS)

                                            Только ES2015 и CommonJS существуют в данный момент. Остальные – легаси. Да и CommonJS тоже станет устаревшим, как только в Node.js завезут модули без флага.


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

                                    +4

                                    Это красивая история «Чем занимались JS-библиотеки в 2018 году», а не обзор технологий фронтенда. Напомню, это HTML, CSS и JavaScript, а не React, Angular и Webpack.

                                      +1
                                      Кажется первый спокойный год.
                                      Так слегка конфиг вебпака подправить, посмотреть что нового в тайпскрипте, бабель бету на релиз поменять, посмотреть как там тайпскрипт транспилится — и ты полностью обновился.

                                      Only users with full accounts can post comments. Log in, please.