Comments 26
Тут не хватает прослойки — когда Вы говорите о декларировании намерений — типа
Существует список значений true / false, называемый checkboxValues, который показывает, какие поля помечены.
Пример: checkboxValues \u003d [false, false, true, false]
То хорошо было бы ниже это всё продублировать ещё раз (ну или разместить там же) — но уже с демонстрацией того — как это выглядит на REACT (хотя бы в виде частичной записи кусочка, в HTML-подобной структуре — что возвращают функции; ну а части — оставшиеся императивными — так и оставить как они выглядят, в JavaScript-подобной записи кода).
Правильная раскраска синтаксиса для новичков тоже очень важна — понятно, что Habr не поддерживает данный синтаксис. И если нет, возможности показать просто раскрашенный текст — то привели бы хотя бы скриншоты листинга — как делали в начале статьи.
Ну и для полноты — было бы неплохо показать — аналогичное исполнение на других декларативных фреймворках — том же Vue — хотя бы финальный полный пример
На Vue на мой взгляд, получается намного удобней сохранить разделение, при этом добавив в html декларативной логики — появляются по сути просто новые аттрибуты у тегов, с которыми будет взаимодействовать js(можно и через jsx, но если мы говорим о первом знакомстве — vue даёт выбор. Реакт — нет). Так же Vue намного дружелюбней для начинающих — его можно просто подключить на страницу олдскульным методом, без всяких сборок.
Код компонента делиться на три части, три тега:
Ага.переменные в верстка, директивы и ещё множество подобных особенностей, сильно пересекающихся в шаблоне и скрипте. Ничем не лучше функции-рендера в реакте.
И как в процессе всякой эволюции, что-то там отвалилось за ненадобностью, что-то осталось
но жить не мешает, что-то новенькое появляется.
Наши клиенты — браузеры, сегодня очень сложные машины.
W3C как-то потихоньку удается что-то стандартизировать, для HTML и CSS.
ECMA пишет свои стандарты, а вендоры придумывают свои фичи, и свои реализации
стандартов. Собственно и вся эволюция web — просто история конкуренции и компромиссов.
Иногда появляются инициативы типа Web Components, ShadowDOM,
но так же исчезают, или становятся тупиковой веткой. Как-то не очень сегодня мы делаем
проекты на Web Components или WebAssembly. Но мы хотим продавать онлайн, и экономика
по большей части — экономика сервиса. И мы хотим писать ПО быстро и что бы это приносило деньги.
И тогда появляется киллер-react или киллер-vue или еще какой киллер.
Менеджеры нанимают кучу программеров, те учатся быстро писать ПО на киллер-frameworke.
Запутываются, выпутываются, продают продукт. Придумать еще один киллер — не штука.
И переделать его до полной неузнаваемости, тоже не штука. Штука — увидеть во всей этой мешанине
образ нового веба, где будет все красиво, логично и по отдельности. Но чего-то пока таких визионеров
нет (инициатива и самого создателя веб как-то мне не очень). Понятно, что тот кто пишет код на любимом
киллере, смотрит на других немного свысока. Потому, что они пишут код на плохом киллере.
Но похоже, правда в том, что пока не появится новая концепция веб, нам придется
довольствоваться тем, что есть. И это не завит ни от HTML, CSS, javascript или reactа.
И ни от способа смешать это все в коктейль и попробовать продать.
Я не уменьшаю заслуг JavaScriprt- он в своё время очень много дал (в основном за счёт фреймворков, созданных для него) для области web-разработки, да и вообще — для очень многих областей разработки в целом! Но сейчас пришла пора программистам больше обращаться именно к возможностям декларативного программирования. Опускаясь до императивного только для описания отдельных небольших подзадач, или для разработки «нижней» прослойки фреймворков.
И пусть REACT, на мой взгляд, не шибко хорошо демонстрирует эту идеологию, зато, в своё время, он был одним из первых, кто решил вернуть программистов сайтов с императивного пути массового внедрения JavaScript на путь декларативного программирования — который в своё время заложили стандарт HTML, затем CSS, затем XML и активно развивающиеся, с начала нулевых, движки сайтов.
Суть не в киллерах — суть в наставниках — проповедниках — гидах — которые смогут вывести программирование на качественно новый уровень — когда не нужно будет задумываться над тем как это сделать и не нарушить миллион связей — а нужно будет думать о том, что нужно сделать и какие связи настроить!
Со временем в HTML тэгах появилась возможности намешать и стилей и javascript.
В css тоже можно намешать разметки, там до или после, первый потомок div и т.д.
Javascript это универсальный язык программирования, и в него можно намешать чего угодно, благо, что есть DOM и DOM API. А также уже есть и websocket и webRTC и т.д.
В HTML без разницы корзина, пользователь или телефон на странице, css и подавно (нет там селектора телефон). И никто в самом начале не собирался продавать телефоны или показывать кино с помощью HTML или CSS. Поэтому, мы сегодня имеем то, что имеем. И сегодня нет возможности писать приложение, так, что вот это у нас разметка, это стили, а это код реакции на добавить в корзину. Хотя многие пытаются.
Вот красиво это вы пишите. Правда, только что нет никаких таких универсальных для веба языков, пока во во всяком случае. Сегодня есть вообще только два типа языков, вполне изомофных типа Тьюринга и типа Черча. Как писать — это ваш личный выбор. Я люблю писать на языках типа Черч. И в принципе не против и мешать все это дело. Просто я смотрю на так называемые ООП штуки как просто на определения типов. Как вы с ними обходитесь, ваше дело, смотрите на них как на моноиды если удобно, или как на аппликативные функторы или ещё как. Но сегодня как не смотри, в вебе фронтэнда нет выбора. Если хотите заработать пишите на том, что есть. А есть не много, react, нормальный способ, только без JSX .Vue, тоже неплохо, если это не куски кода которые не понятно как друг с другом соотносятся. Ну и дальше по списку. Никак вы сегодня от этой мешанины не избавитесь. Ну хотите чистоты, тогда вам не к нам.
И пусть REACT, на мой взгляд, не шибко хорошо демонстрирует эту идеологию, зато, в своё время, он был одним из первых, кто решил вернуть программистов сайтов с императивного пути массового внедрения JavaScript на путь декларативного программирования
коллеги опять перепутали декларативное программирование и декларативный язык разметки :)
Не думаю, что отдельно подход HTML-in-JS добавил каких-то преимуществ. Мне кажется, что там из js делается html, что был бы просто какой-нибудь template engine с html — примерно одно и то же на выходе получилось бы.
А вот работу дизайнеров это способно усложнить. Ранее они могли одним взглядом пройти по HTML — увидеть полную структуру страницы и по ней писать CSS. Теперь придется проводить полный тест приложения, ведь реакт может внезапно по какому-то условию показать новый блок html. Но если js-разработчик и дизайнер — это одно лицо, то вообще проблемы не будет. Думаю, рынок идет в этом направлении.
Не думаю, что отдельно подход HTML-in-JS добавил каких-то преимуществ. Мне кажется, что там из js делается html, что был бы просто какой-нибудь template engine с html — примерно одно и то же на выходе получилось бы.
А вот работу дизайнеров это способно усложнить. Ранее они могли одним взглядом пройти по HTML — увидеть полную структуру страницы и по ней писать CSS. Теперь придется проводить полный тест приложения, ведь реакт может внезапно по какому-то условию показать новый блок html. Но если js-разработчик и дизайнер — это одно лицо, то вообще проблемы не будет. Думаю, рынок идет в этом направлении.
Но тут интересна сама идея — вывести программирование сложной логики как можно более на декларативный уровень. И это можно делать по-разному.
Лично я, вот, считаю, что дизайн-макет сайта всё-таки нужно стараться описывать как можно более целостно — при этом все эти связи стараться описывать в этой структуре. И тут да — дизайнер всё-таки отчасти должен быть программистом — чтобы суметь прямо в макете описывать простые условия и простые обработчики — которые влияют ИМЕННО на дизайн.
При этом вся более сложная логика — и уж тем более связанная с взаимодействием с бизнес-приложением (где должна быть сосредоточена бизнес-логика) — должна быть полностью вынесена из макета — и, желательно, создаваться другими людьми, в т.ч. с активным применением императивного стиля программирования — это уже вне компетенции дизайнера. Он должен только написать либо прямые вызовы этого API, либо подготовить события — на которые сможет подписаться эта внешняя логика уже без его участия (при интеграции).
Естественно, дизайнер может (и должен) опереться на умные дизайн-компоненты, которые он будет размещать в макете — и вот эти компоненты, уже да, могут и свой код финальный HTML генерит, который дизайнеру не будет виден. Вот ту важно делать такую интеграцию наиболее прозрачной — чтобы именно дизайнер мог активно повлиять на нюансы генерации этого код, напрямую связаны с итоговым дизайном. То есть такие компоненты должны быть очень гибко настраиваемыми с одной стороны, а так же, должен быть какой-то отдельный режим просмотра макета — где такие компоненты смогли бы развернуть дизайнеру код, который они генерируют (хотя бы формальный, не рабочий, но отражающий суть внутренней логики, со всеми ветвлениями) — чтобы он смог как раз-таки его проанализировать.
Замечание1: Пример выше на REACT это не совсем ООП подход — (объектов то там практически нет) — это больше шаблонный подход с кодогенерацией. Но при этом с автоматической генерацией событий изменений в данных к их обработчикам — обновляющим эти данные. Такого нет даже в классическом ООП. Даже АОП не обеспечивает такой гибкости (хоть и немного похож на данный стиль). И, кстати, в ООП таких возможностей очень не хватает даже в обычном программировании! Это именно декларативный стиль программирования.
Замечание2: Применение классического подхода с размещением всей логики в JavaScript алгоритмах дизайнерам не поможет тем более — т.к. там может быть спрятано много логики дизайна именно в императивном стиле кода JavaScript — который дизайнерам воспринимать будет очень сложно. Плюс, сейчас JavaScript активно занимается генерацией и модификацией HTML страниц — что совершенно не добавляет прозрачности для анализа HTML макета дизайнеру. Так что REACT (и, надо полагать, другие фреймворки в большей степени) тут наоборот — повышает ясность и прозрачность, а не снижает её. Понятно — что для сайтов с простой логикой применять такие фреймворки нет смысла (ну разве те, которые работают по принципу, что я описал в начале данного поста) — они лишь усложнят сайт. Но если сайту требуется много JavaScript логики — то плюсы фреймворков будут очевидны, по сравнения с кодированием практически всего сайта на JavaScript).
В последние годы JavaScript-разработчики стали определять структуру страницы в JavaScript, а не в HTMLЭто вполне логичный архитектурный тренд. Думаю причины этому чисто когнитивного характера. Разработчику легче работать с одним типом логики, чем с несколькими. Таким образом всеми слоями можно управлять используя одну «точку опоры».
За счет этого снижается сложность управления, не сложность приложения, заметьте, а именно «бюрократическая» сложность. Вобщем, простое стремление к гибкости, независимости, и доступности контроля.
Почему JavaScript пожирает HTML: примеры кода