— Эй, я бы хотел научиться писать крутые веб-приложения. Слышал, у тебя есть опыт.

— Да, я как раз занимаюсь фронтендом, юзаю пару тулз.

— Круто. Я щас делаю простое приложение — обычный TODO-лист, используя HTML, CSS и JavaScript, и планирую заюзать JQuery. Это норм?

— Не-не-не. Это олдскул. Джиквери мёртв — никто не использует его теперь! Тебе нужен React. Это будущее.

— Окей, лады. А что это?

— React это новый способ разработки веб-приложений. Оно базируется на Virtual DOM и позволяет писать JSX-код.

— Virtual-что? JSX? Что это за..?

— JSX — это HTML на стероидах. Это расширенная версия JavaScript, где вы смешиваете XML и JS в одном коде. VirtualDOM означает, что у тебя есть дерево объектов представляющих часть реального DOM, и оно дает возможность манипулировать им очень быстро без необходимости работать с DOM напрямую.

— Зачем смешивать XML и JS?

— Ну как зачем. Реакт это будущее. Он позволяет создавать переиспользуемые компоненты.

— Типа как в Backbone, да?

— Нет. Бэкбон мёртв. Щас теперь все будет на компонентах.

— Ну так мне не нужно заморачиваться про JSX или VirtualDOM?

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

— Окееей, я начинаю слегка теряться. Итак, у нас есть некая шняга для написания компонентов, называется React. Могу я использовать её с JQuery?

— Ну, ты можешь написать одну часть приложения на React, а другую на чём захочешь. Но я ж говорю тебе — JQuery мёртв. Кстати, тебе стоит обратить внимание на Webpack, чтобы склеивать компоненты вместе при сборке.

— ОК. Что это такое?

— Это бандлер модулей. Ты пишешь кучу файлов, как если бы это были модули Node — и затем комбинируешь их в один монолитный файл (или разбитый на части) для отправки клиенту. Тебе даже не понадобятся react-tools, можешь обойтись одним Babel для компиляции JSX.

— Babel?

— Ага, Babel. Это клевая хрень, которая транспилирует твой ES6+/JSX код в читабельный ES5 код, с поддержкой sourcemaps. Это широко распространено, даже в Фейсбуке это используют.

— ES6+?

— ES6/ES2015 это следующая версия ECMAScript, там очень много новых фич, типа классов, стрелочных функций, Maps, Sets и так далее… Щас почти все юзают ES6+.

— Это настолько хорошая вещь?

— Спрашиваешь! ES6+ + транспиляция это будущее.

— Ну ладно. Как мне это заюзать?

— Начни с установки Node...

— Установить Node? О, нет. Ты ведь говорил что-то про React и компоненты.

— Ну да. Дальше ты берешь Flux архитектуру и начинаешь создавать actions, stores и компоненты.

— Flux?

— Во Flux ты выстраиваешь свое приложение как набор stores, actions и view, где данные «текут» в одном направлении. Views вызывают actions, они проходят через dispatcher, а stores подписываются на события dispatcher и выдают change events, на которые подписан view.

— Ага. Как в MVC?

— Нет. MVC мёртв. Flux это будущее. Сейчас очень много реализаций flux.

— Что? Реализаций Flux?

— Да, ведь Flux это просто паттерн. Зырь, Alt, Flummox, marty, fluxxor, fluxible, и т.п… И даже есть фейсбучная реализация Dispatcher.

— Мне нужно это все использовать?

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

— Ладно. Мне бы не хотелось писать эту жесть самому.

— Я ж говорю, реализаций дофига.

— А что насчёт Angular?

— Фу.

— Фу?

— Фу.

— Смотри. Мне реально не хочется возиться с установкой, настройкой и допиливанием чего-то сложного.

— Ваще-то это легко. Существуют готовые киты/репозитории для новичков, или можешь заюзать генераторы Yeoman, которые сделают это за тебя.

— Мне нужен генератор? Yeoman? Что это еще такое?

— Он может сгенерировать код за тебя, и ты можешь заюзать его для создания нескольких приложений сразу. Используй поддержку DLL в новом Webpack, и можешь компилировать каждое приложение отдельно от других.

— У меня будет только одно приложение, одна страничка, один компонент, одно что-угодно. Только одно.

— Нет. Изучи комбинируемые компоненты. Это то, как мы делаем всё сейчас. Тебе нужно разбить всё на компоненты — по одному на каждую отдельную маленькую фигню.

— Кажется, что это избыточно.

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

— Hot Reload? Типа как livereload?

— Не. Webpack поддерживает эту замечательную фичу, она называется горячей перезагрузкой модулей, и есть плагин react-hot-loader для реакта, так что ты сможешь менять код отдельного компонента без перезагрузки всей страницы. А вместе с Flux ты сможешь делать ваще башнесрывные вещи типа прокрутки истории изменений в данных туда-обратно — одновременно с горячим редактированием кода.

— Итак. Теперь у меня десятки различных инструментов и библиотек для упаковки, сборки, транспилирования и чего угодно. Еще что-то?

— Как я уже говорил, Flux дает возможность выстраивать хорошую архитектуру приложений. Но с Observables и Immutable.js данными всё становится намного лучше и интереснее.

— Observable? Мне нужен Immutable?

— Тебе нужны observables чтобы удобно работать с событиями и асинхронностью, а Immutable.js нужен для персистентности, эффективности и простоты. Observables это типа как массивы, только асинхронные. Они возвращают значения с помощью async-генераторов из ES2016.

— Что за async generator?

— Ну смотри, обычный генератор дает возможность функции возвращать серию значений, а с модификатором async ты можешь возвращать значения в будущее. Правда, автор этого, Джафар Хусейн, уже отозвал свой proposal и работает с Кевином Смитом над более узкоспециализированным es-observable для ES7.

— Кхм. Я просто хочу запустить простое приложение. Насколько же глубока кроличья нора?

— Ну, ты можешь использовать RxJS, который ближе к оригинальным observable. Оно широко распространено и годится для продакшена.

— RxJS? Чем же он полезен?

— Работает с твоими уже написанными promises и событиями. Ты можешь создать Observable из любого асинхронного кода, и работать с ним как с обычным значением. Но вообще-то, если ты ищешь что-то по-настоящему реактивное и интересное, позырь фреймворк Cycle.js, разработанный Andre Staltz.

— WTF. Мне всего лишь нужно написать и запустить простое приложение. Смогу я сделать уже это или нет?

— Конечно, хотя деплоинг это отдельный интересный вопрос, но мы уже почти закончили.

— Окей, «сегодня мы многое поняли». Спасибо за объяснения.

— Отлично! Нет проблем.

— Давай я повторю тогда, чтобы мы удостоверились, что я все правильно понял. Итак, мне нужно разбить код своего приложения на actions, stores и компоненты, выстроить однонаправленный dataflow, писать ES6+ код чтобы поиметь все последние языковые фичи, позволяющие мне писать чистый код, затем использовать Babel для транспиляции этого ES6+ кода в ES5 код, пригодный для всех браузеров, использовать webpack, чтобы склеить все части моего приложения, написанные как модули node в один файл, использовать ImmutableJS для представления моих данных и подключить RxJS для описания событий и других асинхронных функций.

— Да. Разве это не восхитительно?

— И, да, я еще кажется забыл про статику и минификацию.

— Не проблема вообще. Webpack умеет импортировать их. Все что тебе нужно, это настроить несколько загрузчиков, плагинов — и вот уже почти и всё. Ты можешь импортировать CSS и картинки. Кстати, есть еще альтернативы CSS, которые позволяют описывать стили в JS...

— Я возвращаюсь к JQuery.

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

>>692592
Ты наверно ещё не вникал в компонентные подходы (BEM, Atomic), от этого и твоя загвоздка.

>Тупой вопрос конечно

С умными вопросами пиздуй, перед мамкой выёбывайся. А тут прекращай прибедняться.

>я ничего не нагуглил

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

В разметке HTML ты больше не указываешь никаких стилей (раньше для твоего случая был в разметке тег <font>, но его похоронили, как и другие похожие, которые только про внешний вид), ты не думаешь о внешнем виде вообще (стили, и только стили, будут в CSS; не смешивай, держи это проще https://ru.wikipedia.org/wiki/KISS_(принцип) ). В разметке ты только сообщаешь о смысле (семантике) каждого отдельного фрагмента (элемента). Например, ты обозначаешь элемент как список <ul> не для того, чтобы просто точечки сбоку появились у него. А чтобы дать понять всяким читалкам (парсерам), от поисковских до инвалидских, что вот эти строчки вместе представляют собой список. Мол, читалки, взаимодействуйте с этой группой строчек соответствующе списку.
Если задачи взаимодействовать с читалками нет, то похуй всем на твою разметку (смыслы элементов), её больше никто не увидит. Можешь вообще все элементы дивами хуярить, Господь найдёт своих. Да хоть всё заголовками внутри заголовков. Одинаково работать будет. Нет смысла указывать смысл, когда смысл бессмыслен (выебнулся, да). Но ты наверно же хочешь творить красоту, а не «хуяк-хуяк-прокатит».
Точечки у тех строк (которые так-то тоже блоки, а не строки, но это уже сбивающие с толку тонкости, для ясности так пишу), которые ты семантически сгруппировал-обозначил как список, появляются потому, что это свойство подставляет браузер как значение по-умолчанию для такого элемента-списка (на случай того, если голый HTML придёт, или просто кто-то проебался, а вменяемо отобразить же как-то надо). Посмотреть браузерные значения (средние по больнице, у каждого браузеры есть ещё немного своего видения прекрасного, в рот его ебать) можно например тут:
http://www.w3schools.com/cssref/css_default_values.asp
Там мы видим для <ul> есть {list-style-type: disc;}. Вот отсюда и берутся точечки для списочных элементов блока-списка (только для <li>, ведь в той же таблице умолчаний есть <li>{display: list-item;}, что заставляет его у родителя стиль списка искать; у других элементов внутри блока <ul> точечек не будет, ведь у других другое display по-умолчанию).
Но тебе же не нужны стили по-умолчанию, у твоего творения есть свой прекраснейший и неповторимый внешний вид. Вот для этого ты уже создаёшь к смысловой разметке HTML отдельный (чтоб не смешивать и не запутаться) файл стилей CSS, связываешь его по классам с разметкой. Ты держишь в голове, что есть какие-то значения по-умолчанию, но тебе на них похуй. Ты описываешь все свойства, соответствующие твоему элементу. Делаешь внешний вид списка, значит у него есть тип стиля списка, который ты решаешь определить как никакой (никаких точечек в твоём макете нет), так и записываешь. Есть отступы, которые у тебя нулевые (это же не значит, что их не существует), ты их так и пишешь, не взирая на то, какие они там подставляются по-умолчанию и подставляются ли вообще. Получается, что у тебя внешний вид и смысловое содержание вообще никак не связаны. Если завтра придёт SEO, даст пизды и скажет поменять список на секцию, а строчки списка на заголовки, то тебе нужно будет поменять только смысловые HTML-теги и всё будет дальше отлично работать и выглядеть. И я охуел от того, насколько это мудро. Десятки лет понадобились, чтобы к этому всем миром придти; так что не переживай насчёт себя, надеюсь, быстрее осилишь.

Перейдём конкретно к твоей проблеме.
Представь, что ты бы обозначал строчки списка как <div>'ы, а не как список, только для того, чтобы у них точечки не появлялись. Глупо было бы наверно. Вот именно это сейчас ты пытаешься сделать с заголовком.
С заголовками такая беда тут часто всплывает; да и сам я на ней застрял в своё время, отсюда и вся эта писанина. Всё дело в уёбски написанных спецификациях, но это тема для отдельного разговора.
Когда читалка пробегается по странице, она выстраивает заголовки в оглавление, в список-дерево. Иерархия заголовков (1-6) нужна только если эти заголовки на одном уровне в общем родитель, тогда они в дереве будут правильно вкладываться по смыслу (типа [1 [2 [3, 3], 2], 1] ). Но на каждом новом уровне вложенности элементов заголовки начинаются с начала, с первого уровня, потому что ну дурость, если по-другому. Представь, у тебя есть блок с заголовком внутри блока с заголовком (теперь твоя разметка официально прокачана! xzibit) типа div > h1 + div > h1. Да-да, второй заголовок ты тоже делаешь h1, ведь выглядеть в дереве он будет типа как 1.1, что таки две большие разницы; они не равнозначны с первым, он вложен в первый. Ты уже наверно понимаешь, почему не стоит использовать сразу h3 из-за того, что «ну у h1 размер шрифта чёт слишком большой». Со всеми стилями ты пиздуешь в таблицу стилей; сейчас мы говорим только о правильной семантичной разметке и хуй кладём на значения по-умолчанию для внешнего вида.
Сами заголовки это блоки. Ты и сам мог догадаться без всяких нудных списков значений по-умолчанию по тому, что они с новой строки начинаются. Строка с текстом лежит внутри блока, строка это строка, блок h1 это для строк обёртка (типа div, только со смыслом заголовка). Так что в удивительном мире зануд-выёбщиков правильно было бы делать <h1><span>Заголовок</span></h1>. Но мы здоровые люди и нам можно так не делать, тут строка и так слишком очевидна, она автоматически создается (и наследует подходящие свойства блока-родителя) и без конкретной разметки.

Хуясе, я понаписюкал. Хоть тут и говорили, что я дурно пишу, но надеюсь, ты теперь и сам понимаешь решение своей заморочки. Держи мой вариант. Всей структуры ты не показал, я представлю, что у тебя там статья про творчество твоих сотрудников.
https://codepen.io/anon/pen/QERaQR

>разбить его на три h2

Теперь то ты сам понимаешь, какой бы это был говнокод?
У тебя было бы в оглавлении три раздела. Два пустых, один с именем "проджект" и текстом.

>>692595
Забудь про них ещё надолго. Это тёмная сторона. Хорошо, когда у тебя маленький документик и инлайн можно отловить. А когда у тебя их будут сотни больших, ты в каждый инлайн будешь лезть? Не делай так больше, не пытайся выкрутиться. Ищи проблему, ищи концепцию, ищи понимание. Всё уже давно продумано и придумано.

Вот и рассвет встретил, копирайтер мамин. Буду теперь опять целый день от Кантора засыпать.