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