Объявсните, зачем нужны автомобили?

Что-то никак не пойму, зачем всё это нужно. Можете подсказать пример региона (или его части) где без этого всего ну вообще никак? Пока что понял, что через эти штуки можно перемещаться по дорогам. Но зачем?

По сабжу: они нужны именно для того, чтобы выводить контент в html.

Объявсните, зачем нужны автомобили?

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

Ты прав. А большинство сайтов интернета может быть заменено пабликами вконтакте.

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

Рендерить на стороне сервера — довольно таки затратно.

Просто я не врубаюсь, зачем через js рендерить контент в html, если он не с сервера пришел.

Вот нажал пользователь кнопочку «скрыть меню». Ты его скрыл. Без всякого взаимодействия с сервером. Решил пользователь залезть в меню, нажал опять на кнопочку, ты меню показал. Без всяких повторных запросов. Вот затем и рендерить через js, чтобы страница на действия пользователя реагировала.

Ты прав. А большинство сайтов интернета может быть заменено пабликами вконтакте.

А так скоро и будет в Чебурнете.

Вот нажал пользователь кнопочку «скрыть меню». Ты его скрыл. Без всякого взаимодействия с сервером. Решил пользователь залезть в меню, нажал опять на кнопочку, ты меню показал. Без всяких повторных запросов. Вот затем и рендерить через js, чтобы страница на действия пользователя реагировала.

Это всё делается на HTML и CSS. Без джаваскриптов вобще. Или я тебя не так понял.

Клик в ксс?

Ну в самом простом случае - делаешь кнопку «скрыть меню» из тега A, в него вкладываешь список-меню из тегов UL/LI. В css пишешь:

a:link > ul {
    display: none;
}

a:active > ul {
    display: block;
}

Можно использовать чекбокс и :checked, например. Масса вариантов.

Я не форнтенд девелопер но пробовал React. Только один кейс от человека который далек от js. У меня была модель (динамически подгружаемые данные), её нужно было преобразовать во view в табличном виде, как это сделать? В начале я подумал сделать свой велосипед для биндинга данных в dom дереве, но быстро нашел knockoutjs. Все в нем было хорошо, кроме того что нужно было править html при изменении структуры данных. ReactJS мне позволил сделать динамичную генерацию view от модели.

Читер!

Это не гибко и не семантично.

Читер!

Все нормальные верстальщики так делают.

Это не гибко и не семантично.

Ох, пожечки ты мой, ну...

<a href="#" role="button">
  <ul>
    <li></li>
    <li></li>
  </ul>
</a>

*божечки

Я про всю массу вариантов, а не про первый. Всеравно читер ))

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

Тут стоит использовать простое правило: если вам не понятно, зачем это нужно, - значит оно вам не нужно.

Вобщем, о чём это я. Меню (в том числе многоуровневое) строится на html/css. Не смотря на то, что я пару лет как основательно пишу чисто на js, этого факта отрицать не могу. А берутся пункты меню откуда? Либо заданы жёстко разметкой в простейшем случае, либо дёргаются из базы данных с помощью (ТАДАМ!) серверных ЯП. Я лично не вижу смысла дёргать из БД данные, скажем, на PHP, генерить из них JSON, отдавать клиенту, на клиенте с помощью JS из JSON генерить HTML с той же подвязкой из CSS, когда можно минуя JS/JSON сразу создать разметку на стороне сервера на PHP и (sic!) закешировать её.

Ну а тут я с тобой согласен на все 146%.

Хотя мне вот недавно по проекту требование прилетело — запиливать на vue. Хотя радует что делать можно не SPA, а только там, где реально можно красиво/удобно запилить, т.е. не перегибать и не ударяться в крайности.

Тут стоит использовать простое правило: если вам не понятно, зачем это нужно, - значит оно вам не нужно.

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

Каждой задаче свое решение. Вот многостраничный список, разбитый по 50 записей на страницу - либо дергать сервер на генерацию всей страницы, либо только на отдачу JSON. Второе менее затратно. Но примеров и за и против вообще можно много нарисовать...

Ты так же легко можешь кешировать эту постраничку постранично.

Ты сравнил костыльную библиотеку, на которой хипстеры по две недели делают формочку на 5 инпутов с автомобилем? Однако...

Каждой задаче свое решение. Вот многостраничный список, разбитый по 50 записей на страницу - либо дергать сервер на генерацию всей страницы, либо только на отдачу JSON. Второе менее затратно. Но примеров и за и против вообще можно много нарисовать...

Да, тут, согласен, не надо всё меню сразу выдавать клиенту, и перегружать страницу - тоже не надо. В далёком мохнатом году для подобных задач придумали AJAX, который по сей день прекрасно с ней справляется и парсить JSON из строки в дерево объектов/массивов давно научились все современные браузеры. Остаётся написать короткую рекурсивную функцию, которая от корневого UL пройдёт по дочерним и в соответствии с JSON заполнит их тегами LI с содержимым. Но это всё не тянет для использование монстра типа Angular и подобных. Это на данный момент даже jQuery уже не требует.

Жизнь кеша может стать слишком короткой, если данные часто изменяются.

Это всё делается на HTML и CSS. Без джаваскриптов вобще.

Можно пошаманить с CSS и HTML, можно бэкэнд на крестах написать. Можно много чего руками сделать. Но на vue это делать проще.

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

когда можно минуя JS/JSON сразу создать разметку на стороне сервера на PHP и (sic!) закешировать её.

И, как минимум vue, этому никак не мешает.

И, как минимум vue, этому никак не мешает.

Модель-Вид-Контроллер, Модель-Вид-МодельВида, Модель-Вид-Представитель, активная модель, пассивная модель, пассивный вид, контроллер-супервизор... четырёхклятаяфигня!!! мне работать надо, а не в сортах контроллеров разбираться. Есть некоторая грань, переходя через которую ты перестаёшь писать код для людей, а начинаешь бить морды друг другу в курилке за поклонения разным шаблонам проектирования.

Я сравнил гроб на четырёх колёсах, под которым хипстеры лежат по две недели, не вылезая из гаража с фреймворком. Да.

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

И что тебе мешает работать?

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

Ну так не переходи эту грань.

Кеша шаблонов или кеша данных? Хотя не важно, и там и там это решается временем изменения.

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

И что тебе мешает работать?

Как что. Берут меня (фронтэндщика), какого-то парня (бэкэндщика) дизайнера там, тестера на простенький проектик, и ставят в надзирание на пол ставки тимлида. Тимлид вчера читал хабру и наткнулся там на очередной Vue, он узнал из статьи, что Vue круче, чем Angular, поэтому новый проект мы (вернее я, он то ничего делать не будет) будем писать на Vue, а старый - поддерживать на ангуляре. А ещё он прочитал, что PHP - это недостаточно по-хипстерски и не потянет наш хайлоад по продаже спиннеров в Нижнезадрыщенске, поэтому бэкэндщик будет писать тоже на JS, а не на привычном ему PHP, так что тот обязан по ходу дела разобраться в ноде, npm, и кей-вэлью БД, потому что так хипсторы делают. Один дизайнер тихонько сидит в уголке и плачет, обнимая свой фотошоп, потому что не дай бог тимлид узнает, что есть бесплатный GIMP...

Смени работу, думаю ещё есть много мест где достаточно открывать меню css.

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

Ну так не переходи эту грань.

Я открываю «мой круг» и смотрю вакансии.

Так-так, что у нас там по CSS?

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

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

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

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

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

Ну так жизнь проф. фронтендщика тяжела. Потому я туда и не лезу.

Но это разнообразие не отменяет того факта, что vue, при разумном его применении, облегчает разработку.

Плачь!

Top 23 Best Free JavaScript Frameworks for Web Developers 2017

https://colorlib.com/wp/javascript-frameworks/

Есть ещё которые не Free и которые не Top. Я не зря сказал про пятьдесят цветов рукояток молотков.

Haml — не язык стилей, а шаблонизатор. Sass и Scss — два диалекта одного и того же языка. jQuery, React, Redux — не фреймворки (Vue и Backbone разве что с натяжкой). Redux так вообще просто библиотека state machine, не зависящая от view-слоя. CoffeeScript устарел, TypeScript от современного JavaScript отличается только типизацией. Так что выбирай что-то одно из каждого набора и учи. Зачем тебе одинаковые молотки, если нужны молоток, отвёртка и плоскогубцы?

Да в этом случае проще вообще не кешировать на стороне приложения, а оставить все на бд и ее кеши.

Рендерить на стороне сервера — довольно таки затратно.

Все нормальные люди пользуются кешированием.

А бд в любом случае проверяет то же самое — филемтайм файла или аналогичное поле в структуре в памяти/файле. Но в бд нет шаблонов.

Все нормальные люди пользуются кешированием.

Ты не закэшируешь все миллиарды вариантов стейта, в зависимости от которых будет разный отрендеренный DOM для разных юзеров.

Зачем тебе учить всё, тем более если половина из перечисленного (less, jquery, backbone, coffeescript) — трупы?

Не, ну, смотря какая задача стоит.

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

Куда-то не туда ушел веб...

Зачем тебе учить всё, тем более если половина из перечисленного (less, jquery, backbone, coffeescript) — трупы?

Скажем так. Мне - уже незачем, потому что ввиду того что я давно интересуюсь вебом, я все эти штуки хорошо знаю. Ну, если быть совсем честным, то первые две - на отлично, а остальные - на четвёрочку, может, с минусом, но не суть. Ещё в моих амбарах безумия есть воспоминания о Marionette, Dart, LiveScript, ещё я на флеше писал, но застал только третий ActionScript, который тоже из семейства ECMA*, ну прочая фигня.

А вот новичку что делать? Если ты берёшь, открываешь список вакансий, а там полно их с требованием знать jQuery тот же... ведь не смотря на то, что браузеры сейчас много умеют, некоторые хотят чтобы сайт работал и в IE8. И в вакансиях есть less. И бэкбон, и прочие мёртвые технологии. Я бы с удовольствием сейчас писал на мэйнстрим яваскрипте, но на моей текущей работе от меня требуют поддержки не меньше IE10 и только недавно я выбил >=IE11.

Пока что понял, что через эти библиотеки можно выводить контент в html.

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