Объявсните, зачем нужны React, Angular и Vue.js?

Это все _можно_ делать на html/css, однако не нужно, так как выглядеть оно будет кривым костылем и реализовываться при помощи средств для того не предназначенных.

Везде в 99% случаях можно обойтись без этих библиотек. Можно взять другие например riot.

Давай конкретику. Про меню - это однозначно и стопроцентно, что на данный момент самый кошерный вариант - это чистый html/css, без использования скриптов вообще.

Если быть более точным, то если в проекте уже используется Фреймворк, через который вы работаете с GUI, то через него и меню нужно делать, но я говорю сейчас про сферического коня меня в вакууме...

...потому что есть у меня подозрения, что если вот взять все эти сферические задачи и подумать, как их правильно реализовывать, то запросто может оказаться, что все они в большинстве проектов весьма удобно реализуются с помощью современных html/css без js-Фреймворков вообще.

Вы же, например, знаете, что на html/css без скриптов можно делать обработку событий (как я выше писал про сворачивание/разворачивание меню)? Ещё можно много всего: начиная от псевдо (и не очень) трёхмерных элементов до различных видов анимаций: вращения по X-Y-Z, перемещения, масштабирования, затенения, кучи фильтров (прям как в фотошопе), при этом можно задавать скорость и прочие параметры этих изменений. Есть media query в css, которые позволяют применять различные фрагменты стилей и радикально менять куски страницы (в том числе включая и выключая некоторые из них) в зависимости от различных параметров, например, таких, как размер экрана. Много-много-много всего, включая всякую динамику, можно реализовать в декларативном стиле на html/css без скриптов.

*сферическое меню в вакууме

извините за такую дурацкую опечатку

Ну что ты разнылся? Бери 2 фреймворка(ангулар и любой на вкус), изучай, и будет тебе счастье.

представь что в городе где есть метро внезапно все с автомобилей пересядут на метро, что произойдет?

представь что в городе где есть метро внезапно все с автомобилей пересядут на метро, что произойдет?

Пусть пересядут на велосипеды. Заодно жирдяев станет поменьше.

Ну что ты разнылся?

Ты дебил или обдолбался чем-то? С чего ты взял, что я ною? Я говорю, что в отрасли атмосфера нездоровая. А ты розовых слонов по монитору гоняешь.

Если говорить о ангуляре/реакте - то это не веб-фрейморвки. Это обычные графические тулкиты вроде Qt

Ага. Ты еще скажи, что их использование не накладывает отпечаток на то, как ты формируешь предметную область. Экшоны, сервисы, фабрики и прочие гугло-фейсбучные термины - вот это всё из чего на 95% состоит код любого приложения с Angular/React

все они в большинстве проектов весьма удобно реализуются с помощью современных html/css без js-Фреймворков вообще.

Напиши gmail без js. Или сравни гуглеверсию gmail-без-новомодного-жс с обычной.

Как что.

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

Напиши gmail без js.

И на кой черт оно надо? Это был пруф-оф-концепт в своё время. Вау-эффекта они добились (а вот с wave не добились). Это не значит что так надо делать.

Или сравни гуглеверсию gmail-без-новомодного-жс с обычной.

Я так понимаю, подразумевается, что «gmail-без-новомодного-жс» - это фуууу? Не соглашусь. Когда они начали раз в полгода корежить UX своего web-мыла несколько лет назад (уже , наверно, десяток!) с радостью вернулся на оффлайн клиенты.

Я так понимаю, подразумевается, что «gmail-без-новомодного-жс» - это фуууу?

https://mail.google.com/mail/?ui=html — да. Но даже там есть немного js.

Чтоб смуззи в барбершопах подавали и гироскутер на спиннерах катился по коворкингу быстрей.

А потом начнется «а нахрена нужен riot?». После ещё пару страниц дискуссии «а зачем нужна %libname%?»

В мире js это нормально. Каждые полгода появляется новая библиотека, которая лучше/меньше/быстрее прошлых.

Вот только сайты быстрей не становятся.

Это реальная история из практики или ты прикалываешься? Если первое, то в цитатник!

Потому что наименее костыльный способ построение интерфейсов на языке разметки текста. Разработка одностраничных или просто сильно привяpзанных к ajax приложений без этих библиотек напоминает удаление гланд через анус.

Я открываю «мой круг» и смотрю вакансии. Так-так, что у нас там по CSS? Less, Sass, Scss, Haml... погодите, что? Четыре языка стилей, кроме одного? Ну ок. А что у нас там по JS фреймворкам? jQuery, React, Redux, Angular, Vue, Backbone... как я, чёрт возьми, это всё изучу? А это ещё, матерь божья, что такое? CoffeeScript, TypeScript - ещё два языка для фронтэнда, которые в итоге скомилируются в JavaScript?

Вот это что?

Ты дебил или обдолбался чем-то?

Мальчик ты как определил мое состояние?

Я говорю, что в отрасли атмосфера нездоровая.

Направление молодое, активно развивается, это нормально.

Напиши gmail без js. Или сравни гуглеверсию gmail-без-новомодного-жс с обычной.

Я ни в коем случае не утверждал, что JS не нужен совсем. Более того, я уже не первый год пишу веб-приложения, которые чуть больше чем полностью обмазаны JS. Я лишь имел ввиду, что зачастую люди упарываются по фреймворкам и пихают JS во все щели, где по-нормальному хватает с лихвой HTML/CSS.

раньше решался тремя-четырмя?

Да не решался он нихрена. Пока я не стал использовать TypeScript, Sass и Haml в виде pug, я рыдал, кровавыми слезами, глядя на жаваскрипт код и на разметку(да, ковыряю веб-сайты с 1999-го, пионером был в 1996-м). А про лапшу в style.css я уже не говорю. Никакой нормальный человек не может оставаться нормальным, когда пишет на чистом javascript. Да, есть уникумы, которые на старых компах программировали, записывая числа в память из-под бэйсика, и у них нормально получается и JS, и css, сразу из головы... Но это долбанутые хикки.

Стильно, модно, молодёжно! В каких-то реально больших и сложных проектах с кучей разработчиков, без этого никак. В реальности, 95% современного веба можно написать на чистом html/css + немного JS (даже без jquery), и сделать это быстрее, чем на фреймворках. Ну если не оглядываться на совместимость с IE6.

Они нужны, чтобы не сойти с ума, когда реализуешь информационную систему с веб-приложением. Ибо html предназначен для разметки текста по типу как в книжке, но с гиперссылками, а javascript - для забавных трюков вокруг этой разметки. И когда кому-то нужно реализовать что-то похожее на 1С, он без этих фреймворков сойдёт с ума. Хотя, facebook выглядит как г...о всё равно.

=^_^=

http://web.archive.org/web/20041125235043/http://www.systemhalt.nm.ru:80/

А что у нас там по JS фреймворкам? jQuery, React, Redux, Angular, Vue, Backbone... как я, чёрт возьми, это всё изучу?

Мало указал.

Вот полный список:

Examples

These are examples written in pure JavaScript.

Backbone.js AngularJS Ember.js KnockoutJS Dojo Knockback.js CanJS Polymer React Mithril Ampersand Flight Vue.js Marionette.js TroopJS + RequireJS

These are applications written in programming languages that compile to JavaScript.

Spine Dart GWT Closure Elm AngularDart TypeScript + Backbone.js TypeScript + AngularJS TypeScript + React Serenade.js Reagent Scala.js + React Scala.js + Binding.scala js_of_ocaml Humble + GopherJS

These are examples written in JavaScript that we are still evaluating.

Chaplin + Brunch Backbone.js + RequireJS KnockoutJS + RequireJS AngularJS + RequireJS CanJS + RequireJS soma.js + RequireJS Durandal Lavaca + RequireJS cujoJS Sammy.js soma.js DUEL Kendo UI PureMVC Olives Dijon rAppid.js DeftJS + ExtJS Aria Templates Enyo + Backbone.js SAPUI5 Exoskeleton Atma.js Ractive.js React + Alt React + Backbone.js Aurelia FOAM WebRx Angular 2.0 Riot JSBlocks

R = App also demonstrates routing

Real-time

SocketStream Firebase + AngularJS

Node.js

Express + gcloud-node

Compare these to a non-framework implementation

Vanilla JS Vanilla ES6 jQuery

http://todomvc.com/

Вот только сайты быстрей не становятся.

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

sic! немного не в тему. в оригинале это значит «такое говно было написано в оригинале».

Да про монстры никто и не говорит, есть же удобные:

http://riotjs.com

И

https://preactjs.com

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

Я лишь имел ввиду, что зачастую люди упарываются по фреймворкам и пихают JS во все щели, где по-нормальному хватает с лихвой HTML/CSS

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

Для «утолщения» клиента.

Ну, про less и sass - не надо. Куча современных css фреймверков типа Bulma на них написаны.

Э? sass сравнительно жив, но less — нет.

Пример ужасный же! Около 6-ти секунд загрузка экрана почты, потом ещё 15 какой-то контент подгружается, нет ни вебсокетов, ни лонг поллинга, можно написать себе письмо с другой вкладки и наблюдать как ничего не происходит. Меня смущают многие сайты, от того же гугла, как у них порой что-то едет на мобильном, но gmail это вершина некомпетентности, никогда не приводите это в пример.

«Обычная» версия там существует для того, чтобы «продвинутая» не казалась такой убогой.

По сабжу все просто: обновлять html без перезагрузки. Когда приходят данные через websocket или запрос-ответ через ajax и нужно обновить html - можно на чистом js писать, задача фреймворков сделать код однообразным и поддерживаемым, организовать в компоненты, связать данные.

Про меню - это однозначно и стопроцентно, что на данный момент самый кошерный вариант

Active и checked - это кривой костыль, а не вариант. Его можно использовать, когда нормальных средств нет.

Если быть более точным, то если в проекте уже используется Фреймворк, через который вы работаете с GUI, то через него и меню нужно делать, но я говорю сейчас про сферического коня меня в вакууме...

В данном случае (меню) достаточно vanilla.js. Фреймворк достаточно легковесен и гарантированно лежит в кеше пользователя. Позволяет скрывать и отображать меню по клику одной строчкой. Без извращений с css, которые совершенный ад поддерживать потом.

Вы же, например, знаете, что на html/css без скриптов можно делать обработку событий (как я выше писал про сворачивание/разворачивание меню)?

Это не обработка событий. Меню в данном случае не реагирует на клик. Так кажется будто оно реагирует, потому что поведение похоже. Классический пример костыля.

Много-много-много всего, включая всякую динамику, можно реализовать в декларативном стиле на html/css без скриптов.

Конечно можно, вот только не завидую тому, кто потом будет копаться в этом дерьме.

Экшоны, сервисы, фабрики и прочие гугло-фейсбучные термины -

С каких пор сервисы и фабрики - фейсбучные термины? Экшоны - термин редакса, а не реакта. Flux - классический MVC из 90, на котором построена вся гуйня. Фабрики и сервисы - обычные термины из обычной десктопной гуйни. Другое дело, конечно, что реакт упорно пытается притворяться бекендом (но суть этого не меняется). Ангуляр же - чистой воды классический десктопный гуи-тулкит по всем параметрам.

Active и checked - это кривой костыль, а не вариант. Его можно использовать, когда нормальных средств нет.

Какие у тебя критерии костыля? Как по мне, это рабочий механизм искаропки.

А для чего ты предлагаешь использовать :active ссылки? Только для того, чтобы цвет или шрифт поменять?

В данном случае (меню) достаточно vanilla.js. Фреймворк достаточно легковесен и гарантированно лежит в кеше пользователя. Позволяет скрывать и отображать меню по клику одной строчкой. Без извращений с css, которые совершенный ад поддерживать потом.

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

К тому же, мне кажется, ты немного преувеличиваешь, говоря про одну строчку кода. Тут речь была о том, что можно замутить через CSS многоуровневое меню. Тебе, чтобы повторить функционал, потребуется навешивать обработчики событий на каждый пункт, способный развернуться и всё равно (sic!) менять стили... или достраивать меню на лету - что дикость.

Я не знаю, как сходу на ванильном JS это написать, потому напишу на jQuery. Можешь, если тебе не лень, показать, как это будет на ванилине.

$('a[role="menu"]').click(function() {
    $(this).find('li').each(function(li) {
        $(li).css('display', 'block');
    });
});

$('ul[role="menu"]').click(function() {
    $('ul[role="menu"] > li').each(function(li) {
        $(li).css('display', 'none');
    });

    $(this).find('li').each(function(li) {
        $(li).css('display', 'block');
    });
});

Это не обработка событий. Меню в данном случае не реагирует на клик. Так кажется будто оно реагирует, потому что поведение похоже. Классический пример костыля.

Это самая натуральная обработка событий, просто записанная не в императивном стиле, как у меня в коде выше, а в декларативном. Кроме того, если мы захотим, например, чтоб меню не просто открывалось, а делало это быстро, но плавно, то надо будет ещё анимацию через jQuery делать, а на ванильном JS, - таймеры юзать, что превратит код для меня в безумие. На CSS же, тебе нужно будет чуть изменить подход: добавить, что в скрытом состоянии высота равна нулю, а в раскрытом - 100% и сделать смену стилей плавной через различные параметры transition.

Конечно можно, вот только не завидую тому, кто потом будет копаться в этом дерьме.

Дерьмом будет твой код на ванильном JS. С jQuery тоже будет дерьмом. Тут уж и вправду, если не можешь осилить CSS, то бери фреймворк, а дальше - фигак, фигак, и в продакшен.

В смысле, тебе чего-то не хватает в нём (less.js)?

Ладно, напишу иначе, раз не понятно.

Если говорить о ангуляре/реакте - то это не веб-фрейморвки. Это обычные графические тулкиты вроде Qt

Раз ангуляр с реактом не фреймворки, а всего-лишь гуй, то логично ожидать, что веб-приложение (предметная область, логика, CRUD, etc) пишется отдельно от них, а затем сбоку легко прикручиваются ангуляр/реакт. Что не совсем так. Всё, что я видел, пишется строго в идеологии этих «не фреймворков». Функции этих «не фреймворков» плотно оплетают весь код. И требуется полное переписывания приложения если захочется перейти на другой «не фреймворк»

Какие у тебя критерии костыля?

Костыль - использование инструмента для того, для чего он не предназначен.

Я не знаю, как сходу на ванильном JS это написать, потому напишу на jQuery. Можешь, если тебе не лень, показать, как это будет на ванилине.

Да так же, только document.querySelector вместо $.

Это самая натуральная обработка событий, просто записанная не в императивном стиле, как у меня в коде выше, а в декларативном.

Там нет никакой обработки событий. Обработка событий - это реакция на клик (что и должно происходить), А ты устанавливаешь зависимость видимости от состояния элемента. То, что это состояние меняется нужным образом при кликах - просто случайная удача.

Дерьмом будет твой код на ванильном JS.

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

Раз ангуляр с реактом не фреймворки, а всего-лишь гуй, то логично ожидать, что веб-приложение (предметная область, логика, CRUD, etc) пишется отдельно от них, а затем сбоку легко прикручиваются ангуляр/реакт.

Так и делается.

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

Ну вот у тебя в ангуляре есть шаблон, в котором (click)=«changeModel()» и функция changeModel(), которая соответствующим образом меняет модель. changeModel() ничего, конечно же, не знает ни о каком ангуляре. Где и что у тебя тут оплетает?

И требуется полное переписывания приложения если захочется перейти на другой «не фреймворк»

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

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

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

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

колхозный скевоморфизм

Сделай уже каминг аут.

Костыль - использование инструмента для того, для чего он не предназначен.

Селекторы :active, :checked и подобные были сделаны для того, чтобы можно было применить стиль, отличный от стандартного, для элементов и их дочерних элементов в соответствующих случаях. Собственно, это и делается для реализации многоуровневого выпадающего меню.

Да так же, только document.querySelector вместо $.

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

Там нет никакой обработки событий. Обработка событий - это реакция на клик (что и должно происходить), А ты устанавливаешь зависимость видимости от состояния элемента. То, что это состояние меняется нужным образом при кликах - просто случайная удача.

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

В коде на js с первого взгляда понятно, что происходит.

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

Рили вот это:

$('ul[role="menu"]').click(function() {
    $('ul[role="menu"] > li').each(function(li) {
        $(li).css('display', 'none');
    });

    $(this).find('li').each(function(li) {
        $(li).css('display', 'block');
    });
});

a[role=menu] > ul {
  display: none;
}

a[role=menu]:active > ul {
  display: block;
}

Селекторы :active, :checked и подобные были сделаны для того, чтобы можно было применить стиль, отличный от стандартного, для элементов и их дочерних элементов в соответствующих случаях.

Только вот рассматриваемый случай - не соответствующий. Ни checked, ни active не является случаем «я кликнул по объекту». Это не гарантируется.

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

Задача - отреагировать на изменения при клике. У тебя же описана (да, декларативно) реакция на изменение состояний active\checked. Тебе вообще никто не гарантирует, что эти состояния будут меняться при клике. Это так в большинстве реализаций - и не более того.

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

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

Затем, чтобы генерить HTML из шаблонов, подставля данные, полученные с сервера.
То есть с сервера прилетают сырые данные, без разметки.
Это удобно, когда у тебя несколько интерфейсов используют одни и те же данные (разные версии сайта, мобилы и пр)

Less, Sass, Scss, Haml... погодите, что? Четыре языка стилей, кроме одного? Ну ок.

Sass и Scss — это один и тот же язык, Haml — это язык разметки, а не язык стилей.

А это ещё, матерь божья, что такое? CoffeeScript, TypeScript - ещё два языка для фронтэнда, которые в итоге скомилируются в JavaScript?

CoffeeScript учится буквально за час, TypeScript — за пару вечеров.

typescript вообще учить не обязательно, т.к. код на js - валидный код на ts.