Я не совсем понял, ко мне ли обращен ваш ответ, если ко мне, то я не знаю кто и зачем что-то пересобирает просто ради смены фреймворка. Если что-то решается одним фрилансером-верстальщиком и готовым шаблоном вордпресса, то так и надо делать.
Клиентские фреймворки берут для проектов, требующих поддержки и доработок под специфические требования. Кроме валидации там еще много чего, чего нет в вордпрессе - он ведь не SPA и там нельзя легко навесить на разметку те же банальные обработчики, которых может быть очень много.
Ну и клиентская валидация не равна серверной, серверные валидации гораздо сложнее, могут опираться на кучу third-party систем, о которых фронтенду знать не нужно. Клиентские фреймворки поддерживают и клиентскую и серверную валидацию, в том числе одновременно.
На вордпрессе без спец. решений на мало мальски сложных формах уже можно начать сходить с ума если руками писать все это.
Если ориентироваться на список запущенных проектов на ее сайте в портфолио, то так и есть. Это то, что обычно называют "сайт на вордпрессе под ключ". Только зачем-то самописное, вордпресс давно уже покруче будет чем вся эта простенькая HTML5 валидация, нативные алерты, подключенный скрипт-тегом фэнсибокс (мило).
Можно ли так делать проекты для малого бизнеса за три копейки? Да вполне, хотя и непонятно чем ворпдресс не угодил.
Стоит ли поливать помоями тех, кто делает что-то иначе? Это на совести авторки.
Почему-то ни одному разработчику интерфейсов (а сайт - это пользовательский интерфейс) вне веба не приходит в голову перерисовывать полностью весь вьюпорт при частичных изменениях (не считая GUI immediate-режима). Потому что это видно глазами, а в вебе еще и создает задержки на скорость взаимодействия.
Ограничения веба - это именно ограничения, и то что их обходят - это хорошо. А треш - это то что вы описываете.
Эти генераторы позволяют писать SPA, получая на выход статическую разметку. У них есть своя область применимости, например писать лендинги на таких генераторах гораздо удобнее, чем с помощью описанного вами подхода. Как раз за счет технологического стека вокруг SPA.
У вас подход "без ТЗ результат ХЗ", у меня же подход с заботой о заказчике и здравом смысле. Заказчик не обязан знать все эти нюансы. И это одна из причин почему разработка всегда затягивается. Потому что всем всё равно.
Это значит, что вы выполняете роль бизнес-аналитика. Если вы им при этом по специализации не являетесь, то не факт, что качественно. Зачем перекладывать эту роль на разработчиков - непонятно.
Опять же если речь не о масштабах лендинга для забегаловки (хотя и там за фасадом часто скрыты серьезные бизнес-процессы).
Корпорации и другие компании у которых бюджет побольше, чем у пиццерии на углу, тоже запускают стартапы. И там к ним могут быть совсем иные требования. Например там могут быть дизайн-гайдлайны к продукту. Необходимость поддержки смены темы под требования партнеров. И еще куча всего, что в представлении заказчика обеспечит конкурентность при выводе продукта на рынок.
То, что вы понимаете под стартапами и MVP какой-то примитив (в технологическом плане), это исключительно ваши представления об устройстве мира.
А пренебрежительное отношение к коллегам на этих представлений, говорит уже лично о вас. И не в положительном ключе.
Судя по тому, что вы пишете - вы разрабатываете заведомо одноразовые проекты. Я не осуждаю - в этом случае можно писать хоть ногами.
Только к чему весь этот негатив про фронтендщиков, еще и с историческим экскурсом. Вы же не занимаетесь фронтендом. А есть масса проектов, где им надо заниматься.
О чем и речь. Так и пишете, что ваш подход работает только на лендингах и админках без дизайна. Не стоит думать, что веб-разработка этим ограничивается.
В шаблонах обычно это предусмотрено, они идут сразу со всеми inputmask, select2 и прочим.
Как может быть предусмотрено, если вдруг ваш select2 в следующей версии добавит селектор, который пересечется с одним из ваших. Сидеть на одном компоненте одной и той же версии? А если незнакомый компонент - надеяться что все будет хорошо?
Зачем копипаст? Это решается шаблонизатором, например jinja2, там есть наследование, includ'ы есть и макросы. Скрипты тоже можно подключать так же, через шаблонизатор.
Покажите пример скрипта, который вы подключаете инклудом. На примере поля формы желательно. Инициализацию конкретного динамического компонента вы же не инклудами подключаете?
Выше написала. Плюс это вопрос про оптимизацию, оптимизацией нужно заниматься по мере необходимости, иначе она преждевременная. Напомню, что мы говорим про стартапы и MVP. По поводу большого бандла - а в SPA он не большой? Да и он кешируется, не вижу проблемы тащить на каждую страницу, скачается один раз.
Если "выше" - имеется в виду ручные инклуды, да судя по всему не один на компонент, да плюс <script> вставки с ручной инициализацией, то это супер решение конечно.
А что на стартапах и MVP не нужно предусмотреть возможность нагрузки? Там не важна скорость первого взаимодействия, которую ваш мегабандл рушит за счет нагрузки на scripting? JS так то однопоточный.
В современных SPA бандл не большой. Он не будет больше аналогичного велосипеда, который вы напишете, когда упретесь в ограничения своего подхода (читай, когда нужно чтото сложнее лендинга и админки на бутстрапе). И кешироваться он будет лучше вашего мегабандла, который будет инвалидироваться на каждую правку.
А если нагрузка вдруг возникнет, все переписывать? Ну открою секрет, тот кто за вами потом переписывает - это я. В целом своими действиями вы развиваете рынок труда, и лично мне грех жаловаться.
Раз вы используете готовые юайкиты, вы не могли не столкнуться с задачей их кастомизации под требования дизайна. Другие паддинги, другие наборы иконок, другая типографика и т.д. Какими корявыми оверрайдами кастомизируются готовые решения, включая бутстрап, знают все, кто пробовал вообще хоть что-то делать по заданным дизайнам.
Если вы не сталкивались - либо у вас нет кастомных дизайнов вообще, либо вы их делаете под бутстрап. Ну либо вам не надо ничего кастомизировать сложнее кнопки и поля ввода.
По второй части как-то даже странно отвечать, но ок:
Нет изоляции стилей. Подрубаете любой готовый компонент, который нецелесообразно самим писать с нуля (скажем, продвинутое поле ввода номера телефона). После чего надеетесь, что он не использует пересекающиеся с вами стили. А если раскорячил и вы заметили - пишете те самые корявые оверрайды. Особенно весело если там :not(div) какой-нибудь.
Нет нормального переиспользования. Тогда вы плодите копипаст, и в случае правок, делаете их не в одном месте, а в нескольких (или в куче, как это обычно бывает) и надеетесь, что нигде не ошиблись.
Нет поддержки жизненного цикла. Ну тут интересно как вы ими вообще тогда управляете. Что-то типа <script>initSlider({ element: '#mySlider' })</script> перед закрывающим body? Ну удачи когда у много таких компонентов на одной странице.
Нет импорта компонента с поддержкой tree shaking? Тогда либо вы их сразу все тащите на каждую страницу одним жирным бандлом, либо делаете эту работу своими руками.
Нужно ли пояснять, что все перечисленное - это как раз время бизнеса, отнятое у его бизнес-задач?
Это даже не касаясь сомнительного утверждения, что 1 фронт + 1 бек дороже аналогичного фулстека. Это не так, за ту же цену или дешевле у вас будет "фулстек" с перекосом в одну из областей, который другую область не будет знать даже на уровне мидла. У вас видно, что перекос в сторону бекенда.
Вы используете при организации кода на сайте компоненты, ui-kitы?
Если да, можете рассказать, как организовать аналог SPA-шного ui-kitа в парадигме MPA? С переиспользованием компонента целиком(а не только разметки), с изоляцией стилей на уровне компонента, с подключением на нужных страницах только тех компонентов, которые на ней используются. +, как организуется их жизненный цикл.
Я не совсем понял, ко мне ли обращен ваш ответ, если ко мне, то я не знаю кто и зачем что-то пересобирает просто ради смены фреймворка. Если что-то решается одним фрилансером-верстальщиком и готовым шаблоном вордпресса, то так и надо делать.
Клиентские фреймворки берут для проектов, требующих поддержки и доработок под специфические требования. Кроме валидации там еще много чего, чего нет в вордпрессе - он ведь не SPA и там нельзя легко навесить на разметку те же банальные обработчики, которых может быть очень много.
Ну и клиентская валидация не равна серверной, серверные валидации гораздо сложнее, могут опираться на кучу third-party систем, о которых фронтенду знать не нужно. Клиентские фреймворки поддерживают и клиентскую и серверную валидацию, в том числе одновременно.
На вордпрессе без спец. решений на мало мальски сложных формах уже можно начать сходить с ума если руками писать все это.
Сперва добейся? (с) Что же из ваших проектов в портфолио нельзя было сделать на готовой CMS?
Если ориентироваться на список запущенных проектов на ее сайте в портфолио, то так и есть. Это то, что обычно называют "сайт на вордпрессе под ключ". Только зачем-то самописное, вордпресс давно уже покруче будет чем вся эта простенькая HTML5 валидация, нативные алерты, подключенный скрипт-тегом фэнсибокс (мило).
Можно ли так делать проекты для малого бизнеса за три копейки? Да вполне, хотя и непонятно чем ворпдресс не угодил.
Стоит ли поливать помоями тех, кто делает что-то иначе? Это на совести авторки.
В случае бесконечной подгрузки как минимум остается возможность браузерного поиска по странице. Я лично им пользуюсь.
Почему-то ни одному разработчику интерфейсов (а сайт - это пользовательский интерфейс) вне веба не приходит в голову перерисовывать полностью весь вьюпорт при частичных изменениях (не считая GUI immediate-режима). Потому что это видно глазами, а в вебе еще и создает задержки на скорость взаимодействия.
Ограничения веба - это именно ограничения, и то что их обходят - это хорошо. А треш - это то что вы описываете.
Эти генераторы позволяют писать SPA, получая на выход статическую разметку. У них есть своя область применимости, например писать лендинги на таких генераторах гораздо удобнее, чем с помощью описанного вами подхода. Как раз за счет технологического стека вокруг SPA.
Это значит, что вы выполняете роль бизнес-аналитика. Если вы им при этом по специализации не являетесь, то не факт, что качественно. Зачем перекладывать эту роль на разработчиков - непонятно.
Опять же если речь не о масштабах лендинга для забегаловки (хотя и там за фасадом часто скрыты серьезные бизнес-процессы).
Корпорации и другие компании у которых бюджет побольше, чем у пиццерии на углу, тоже запускают стартапы. И там к ним могут быть совсем иные требования. Например там могут быть дизайн-гайдлайны к продукту. Необходимость поддержки смены темы под требования партнеров. И еще куча всего, что в представлении заказчика обеспечит конкурентность при выводе продукта на рынок.
То, что вы понимаете под стартапами и MVP какой-то примитив (в технологическом плане), это исключительно ваши представления об устройстве мира.
А пренебрежительное отношение к коллегам на этих представлений, говорит уже лично о вас. И не в положительном ключе.
Судя по тому, что вы пишете - вы разрабатываете заведомо одноразовые проекты. Я не осуждаю - в этом случае можно писать хоть ногами.
Только к чему весь этот негатив про фронтендщиков, еще и с историческим экскурсом. Вы же не занимаетесь фронтендом. А есть масса проектов, где им надо заниматься.
Ответ на вполне конкретный вопрос - ни о чем.
Круто че. А если встретятся? Ну вдруг ваш стартап, который вы так дешево и грамотно написали, стрельнет? Видимо у вас таких не было, раз так пишете?
Так о каких стартапах речь тогда? О лендингах с формой обратной связи и админкой на готовый компонентах?
Можете показать крупный проект яндекса, с жирной клиентской логикой, на котором применяется описанный вами подход?
О чем и речь. Так и пишете, что ваш подход работает только на лендингах и админках без дизайна. Не стоит думать, что веб-разработка этим ограничивается.
Как может быть предусмотрено, если вдруг ваш select2 в следующей версии добавит селектор, который пересечется с одним из ваших. Сидеть на одном компоненте одной и той же версии? А если незнакомый компонент - надеяться что все будет хорошо?
Покажите пример скрипта, который вы подключаете инклудом. На примере поля формы желательно. Инициализацию конкретного динамического компонента вы же не инклудами подключаете?
Если "выше" - имеется в виду ручные инклуды, да судя по всему не один на компонент, да плюс <script> вставки с ручной инициализацией, то это супер решение конечно.
А что на стартапах и MVP не нужно предусмотреть возможность нагрузки? Там не важна скорость первого взаимодействия, которую ваш мегабандл рушит за счет нагрузки на scripting? JS так то однопоточный.
В современных SPA бандл не большой. Он не будет больше аналогичного велосипеда, который вы напишете, когда упретесь в ограничения своего подхода (читай, когда нужно чтото сложнее лендинга и админки на бутстрапе). И кешироваться он будет лучше вашего мегабандла, который будет инвалидироваться на каждую правку.
А если нагрузка вдруг возникнет, все переписывать? Ну открою секрет, тот кто за вами потом переписывает - это я. В целом своими действиями вы развиваете рынок труда, и лично мне грех жаловаться.
Раз вы используете готовые юайкиты, вы не могли не столкнуться с задачей их кастомизации под требования дизайна. Другие паддинги, другие наборы иконок, другая типографика и т.д. Какими корявыми оверрайдами кастомизируются готовые решения, включая бутстрап, знают все, кто пробовал вообще хоть что-то делать по заданным дизайнам.
Если вы не сталкивались - либо у вас нет кастомных дизайнов вообще, либо вы их делаете под бутстрап. Ну либо вам не надо ничего кастомизировать сложнее кнопки и поля ввода.
По второй части как-то даже странно отвечать, но ок:
Нет изоляции стилей. Подрубаете любой готовый компонент, который нецелесообразно самим писать с нуля (скажем, продвинутое поле ввода номера телефона). После чего надеетесь, что он не использует пересекающиеся с вами стили. А если раскорячил и вы заметили - пишете те самые корявые оверрайды. Особенно весело если там :not(div) какой-нибудь.
Нет нормального переиспользования. Тогда вы плодите копипаст, и в случае правок, делаете их не в одном месте, а в нескольких (или в куче, как это обычно бывает) и надеетесь, что нигде не ошиблись.
Нет поддержки жизненного цикла. Ну тут интересно как вы ими вообще тогда управляете. Что-то типа <script>initSlider({ element: '#mySlider' })</script> перед закрывающим body? Ну удачи когда у много таких компонентов на одной странице.
Нет импорта компонента с поддержкой tree shaking? Тогда либо вы их сразу все тащите на каждую страницу одним жирным бандлом, либо делаете эту работу своими руками.
Нужно ли пояснять, что все перечисленное - это как раз время бизнеса, отнятое у его бизнес-задач?
Это даже не касаясь сомнительного утверждения, что 1 фронт + 1 бек дороже аналогичного фулстека. Это не так, за ту же цену или дешевле у вас будет "фулстек" с перекосом в одну из областей, который другую область не будет знать даже на уровне мидла. У вас видно, что перекос в сторону бекенда.
Вы используете при организации кода на сайте компоненты, ui-kitы?
Если да, можете рассказать, как организовать аналог SPA-шного ui-kitа в парадигме MPA? С переиспользованием компонента целиком(а не только разметки), с изоляцией стилей на уровне компонента, с подключением на нужных страницах только тех компонентов, которые на ней используются. +, как организуется их жизненный цикл.
Или все это вам не нужно?
Какая то видимо личная неприязнь к фронтендщикам у автора.
Ускорить работу они могут только если у вас нет дизайна. Если он есть, готовьтесь снова придумывать классы на случай, когда тейлвинда не хватает.
И вжух, у вас теперь и простой CSS, и тейлвинд в одном проекте. Хотя мог бы быть только CSS. Поздравляю.
styled-components - жирный рантайм
tailwindcss просто не нужен
git log -1?