Кто сказал, что я говнокодю и застрял в одной парадигме?
Точно не я.
Это вы сказали, что у вас даже адаптивной верстки нет в 2020, когда половина пользователей на смартфонах.
А про застревать в одной парадигме – это я про смысл своих статей говорил, а не конкретно про вас.
А вот вы пытаетесь меня лично задеть "сайтами-визитками" и т.п.
У вас есть данные какой рост в конверсии после внедрения Inertia.js?
А при чем тут Inertia.js? Я говорил про Uber, Apple и другие компании, которые вы упомянули. Возможно, им не так важно качество сайта, потому что от отсутствия адаптива и двухметровых бандлов меньше айфонов, скорее всего, покупать не станут. Но говорить, что это значит, что все так должны делать, или просто одобрять такой подход не надо.
Большинство статей, которые я пишу, на схожую тему, а именно — какие есть подходы к разработке web-приложений.
Всё, что я пытаюсь донести, — это "да, можно так, но ещё можно и вот так".
Я не говорил о том, нужен ли SSR, я не говорил о том, что давайте все откажемся от использования API. Я говорю, что есть альтернатива и что она не такая уж и плохая и несёт много новых возможностей. Не надо застревать на месте и, упёршись в одну парадигму, зачастую самую хайповую, игнорировать, что мир движется вперёд. Нужно быть открытым новым идеям, даже хорошо забытым старым, переделанным с учётом нового опыта.
Single-page Application – это веб-приложение, которое имеет лишь одну HTML страницу. Её контент создается и обновляется с помощью JavaScript.
Когда нам нужна какая-либо информация, вместо того, чтобы отправлять запрос на новую HTML-страницу, мы отправляем запрос на получение JSON-файла с необходимой информацией, которую потом вставляем на ту же самую страницу.
У этого есть свои плюсы и есть свои минусы. Один из минусов – мы не может получить сразу какие-то конкретные данные. Так как страница всего одна, нам приходится сначала загрузить её, а уже оттуда посылать нужный нам запрос.
Благо это решается такими библиотеками, как VueRouter. Они симулируют переходы по страницам в URL-строке. И если нам нужно получить какую-то специфическую информацию, мы просто передаем это в URL.
Важно понимать, что, если мы нажмем на тег <a> и не сделаем preventDefault, мы, как обычно, отправим запрос на HTML-страницу по href. Чтобы этого избежать, в таких библиотеках, как VueRouter, используются специальные ссылки (например, во VueRouter – это <router-link>), которые перехватывают запросы к HTML и вместо этого делают запрос на JSON.
Теперь посмотрим что делает Inertia.js (подробнее тут и тут). То же самое! Она с помощью специальных ссылок перехватывает запросы к HTML и вместо этого отправляет запрос на JSON. А где я пишу настройки для роутинга в router/index.js или в routes/web.php значения не имеет.
Если же вы хотите написать очередной тесно свзанный монолит, не используете определение SPA.
Теперь вы, zogxray, расскажите мне, как я неправильно использую понятие SPA.
Хотелось бы, конечно, иметь русскую версию документации для проекта, созданного русскоговорящими людьми. Я сам особых проблем с английским не имею, но, если делается упор на русскоязычное коммьюнити, это, имхо, must-have.
Во-первых, сам автор TailwindCSS говорит в одной из статей, что если вы не готовы отказаться от семантических классов, можете их добавлять просто для удобства поиска. То есть для кнопки добавить класс button. У него нет никаких стилей, он просто для того, чтобы было легче ориентироваться.
Во-вторых, я согласен, что если писать простыню разметки, где всё в одном файле, TailwindCSS очень неудобен. Но проблема не в TailwindCSS, проблема в том, что не надо писать безкомпонентные простыни.
Если не хочется использовать фреймворки, а хочется писать простую статику, я предлагал одно из решений в этой моей статье
Слишком низкоуровнево, в плохом смысле этого слова, т.е. сложно и неудобно.
И не хотелось бы путать теплое с мягким, но, если уж я решу использовать JS для работы с DOM, не лучше ли было бы использовать какой-нибудь Svelte вместо веб-компонентов?
Основное преимущество gulp-file-include, как я уже говорил, — это то, что результат не меняется. Мы компилируем наш раздробленный на компоненты код в обычный HTML-файл, который не вызовет проблем ни с поддержкой браузеров, ни с SEO.
Статические генераторы – дело хорошее. Однако, во-первых, это как минимум сложнее, во-вторых, требует полностью переделывать проект, если он уже написан.
gulp-file-include, в свою очередь, требует минимальных усилий для использования. А сборщик проекта (наподобие Gulp) в любом случае должен быть, это сильно упрощает работу, при этом никак не влияя на конечный результат.
И, по-моему, это удобнее PHP. Да, он не привносит ничего особенно нового, что нельзя сделать на PHP, но при этом не требует сервера, знания другого языка (если ты frontend-only) и тому подобных сложностей.
Хотелось бы поподробнее про последствия в долгой перспективе.
По-моему, проблемы с масштабируемостью возникают, когда код очень связан между собой, когда он раздувается и усложняется и каждое новое изменение может что-то сломать в ранее написанном.
Я ни одной из этих проблем с TailwindCSS не вижу. Код не связан вообще никак, количество классов и сложность не увеличивается.
Как удобнее пользоваться магическими строками вместо переменных и констант.
Всё-таки на любом проекте есть определенная база стилей, которая говорит, что синий у нас такой, а серый такой. Нельзя каждый раз использовать разный серый. Какой серый, вы можете решить сами.
Это к разговору об абстракциях. Тут как раз таки нужна такая абстракция.
TailwindCSS был бы костылем, если бы хоть как-то ограничивал обычный CSS. Но вы можете также продолжать им пользоваться, даже не заметив, что у вас подключен этот фреймворк.
Поэтому мне сложно представить, как "костыли смогут превратится в грабли".
С одной стороны, TailwindCSS никак не мешает писать вам такие абстракции. Другой вопрос, как много таких btn вы хотите создать.
Удобнее будет написать btn-primary-with-a-little-more-horisontal-paddings или btn-primary px-6?
С другой стороны, кто выигрывает от таких абстракций? Они безусловно удобны, когда нужно сделать однотипный интерфейс с помощью, например, Bootstrap. Но объясните мне, какое конкретно преимущество получает разработчик, когда видит btn-primary вместо конкретных стилей.
Вы скажете, что такая инкапсуляция позволяет быстро ориентироваться в больших объемах разметки. Это верно. Однако, по-моему, она сильно мешает при современном компонентом дроблении кода. Если я уже зашел в компонент <Button/>, я не хочу видеть class="btn-primary", я хочу видеть конкретные стили.
Вы правы. Это тот же самый CSS, только в другой обёртке.
Речь как раз о том, что такой способ написания того же самого по сути CSS значительно удобнее и нагляднее, отлично комбинируется с идеей о компонентах как переиспользуемых элементах, из которых собирается приложение.
Ваши стили всегда при вас, они не записаны в каком-то другом файле на чёрт знает какой строке.
Если вам нужно перенести какой-то элемент, например, из старого проекта в новый, вы просто копируете разметку и вуаля, он такой же, каким был и там.
Какую конкретно проблему мы решаем? Автоматизация процесса верстки? Тогда почему вся статья о создании основного макета.
Или мы хотим автоматизировать создание основного макета? Тогда это бессмысленно, учитывая, что сейчас поддержка Flexbox — 98,5%, поддержка Grid — 95% и "руками" все делается достаточно легко.
Я не говорю, что мой подход, — production-ready best practice. Я сам новичок во всем этом. Спасибо за предложение, я обязательно разберусь. Вполне возможно, ваш вариант лучше.
https://windicss.org/features/
Выглядит интересно
Самый большой плюс Angular — на нем сложнее говнокодить.
Самый большой минус Angular — очень плохая документация. Её даже просто "описанием API" только с натяжкой можно назвать.
Спасибо, но я уже посмотрел видео про это на Apple Explained, которое вышло неделю назад
Точно не я.
Это вы сказали, что у вас даже адаптивной верстки нет в 2020, когда половина пользователей на смартфонах.
А про застревать в одной парадигме – это я про смысл своих статей говорил, а не конкретно про вас.
А вот вы пытаетесь меня лично задеть "сайтами-визитками" и т.п.
А при чем тут Inertia.js? Я говорил про Uber, Apple и другие компании, которые вы упомянули. Возможно, им не так важно качество сайта, потому что от отсутствия адаптива и двухметровых бандлов меньше айфонов, скорее всего, покупать не станут. Но говорить, что это значит, что все так должны делать, или просто одобрять такой подход не надо.
И хвастаться тем, что у вас успешно получается говнокодить для гигантских компаний, чей продукт и без ваших сайтов успешно продается, — моветон.
Большинство статей, которые я пишу, на схожую тему, а именно — какие есть подходы к разработке web-приложений.
Всё, что я пытаюсь донести, — это "да, можно так, но ещё можно и вот так".
Я не говорил о том, нужен ли SSR, я не говорил о том, что давайте все откажемся от использования API. Я говорю, что есть альтернатива и что она не такая уж и плохая и несёт много новых возможностей. Не надо застревать на месте и, упёршись в одну парадигму, зачастую самую хайповую, игнорировать, что мир движется вперёд. Нужно быть открытым новым идеям, даже хорошо забытым старым, переделанным с учётом нового опыта.
Single-page Application – это веб-приложение, которое имеет лишь одну HTML страницу. Её контент создается и обновляется с помощью JavaScript.
Когда нам нужна какая-либо информация, вместо того, чтобы отправлять запрос на новую HTML-страницу, мы отправляем запрос на получение JSON-файла с необходимой информацией, которую потом вставляем на ту же самую страницу.
У этого есть свои плюсы и есть свои минусы. Один из минусов – мы не может получить сразу какие-то конкретные данные. Так как страница всего одна, нам приходится сначала загрузить её, а уже оттуда посылать нужный нам запрос.
Благо это решается такими библиотеками, как VueRouter. Они симулируют переходы по страницам в URL-строке. И если нам нужно получить какую-то специфическую информацию, мы просто передаем это в URL.
Важно понимать, что, если мы нажмем на тег
<a>и не сделаемpreventDefault, мы, как обычно, отправим запрос на HTML-страницу поhref. Чтобы этого избежать, в таких библиотеках, как VueRouter, используются специальные ссылки (например, во VueRouter – это<router-link>), которые перехватывают запросы к HTML и вместо этого делают запрос на JSON.Теперь посмотрим что делает Inertia.js (подробнее тут и тут). То же самое! Она с помощью специальных ссылок перехватывает запросы к HTML и вместо этого отправляет запрос на JSON. А где я пишу настройки для роутинга в
router/index.jsили вroutes/web.phpзначения не имеет.Теперь вы, zogxray, расскажите мне, как я неправильно использую понятие SPA.
Хотелось бы, конечно, иметь русскую версию документации для проекта, созданного русскоговорящими людьми. Я сам особых проблем с английским не имею, но, если делается упор на русскоязычное коммьюнити, это, имхо, must-have.
Во-первых, сам автор TailwindCSS говорит в одной из статей, что если вы не готовы отказаться от семантических классов, можете их добавлять просто для удобства поиска. То есть для кнопки добавить класс
button. У него нет никаких стилей, он просто для того, чтобы было легче ориентироваться.Во-вторых, я согласен, что если писать простыню разметки, где всё в одном файле, TailwindCSS очень неудобен. Но проблема не в TailwindCSS, проблема в том, что не надо писать безкомпонентные простыни.
Если не хочется использовать фреймворки, а хочется писать простую статику, я предлагал одно из решений в этой моей статье
Слишком низкоуровнево, в плохом смысле этого слова, т.е. сложно и неудобно.
И не хотелось бы путать теплое с мягким, но, если уж я решу использовать JS для работы с DOM, не лучше ли было бы использовать какой-нибудь Svelte вместо веб-компонентов?
Основное преимущество gulp-file-include, как я уже говорил, — это то, что результат не меняется. Мы компилируем наш раздробленный на компоненты код в обычный HTML-файл, который не вызовет проблем ни с поддержкой браузеров, ни с SEO.
Статические генераторы – дело хорошее. Однако, во-первых, это как минимум сложнее, во-вторых, требует полностью переделывать проект, если он уже написан.
gulp-file-include, в свою очередь, требует минимальных усилий для использования. А сборщик проекта (наподобие Gulp) в любом случае должен быть, это сильно упрощает работу, при этом никак не влияя на конечный результат.
И, по-моему, это удобнее PHP. Да, он не привносит ничего особенно нового, что нельзя сделать на PHP, но при этом не требует сервера, знания другого языка (если ты frontend-only) и тому подобных сложностей.
Хотелось бы поподробнее про последствия в долгой перспективе.
По-моему, проблемы с масштабируемостью возникают, когда код очень связан между собой, когда он раздувается и усложняется и каждое новое изменение может что-то сломать в ранее написанном.
Я ни одной из этих проблем с TailwindCSS не вижу. Код не связан вообще никак, количество классов и сложность не увеличивается.
Как удобнее пользоваться магическими строками вместо переменных и констант.
Всё-таки на любом проекте есть определенная база стилей, которая говорит, что синий у нас такой, а серый такой. Нельзя каждый раз использовать разный серый. Какой серый, вы можете решить сами.
Это к разговору об абстракциях. Тут как раз таки нужна такая абстракция.
TailwindCSS был бы костылем, если бы хоть как-то ограничивал обычный CSS. Но вы можете также продолжать им пользоваться, даже не заметив, что у вас подключен этот фреймворк.
Поэтому мне сложно представить, как "костыли смогут превратится в грабли".
С одной стороны, TailwindCSS никак не мешает писать вам такие абстракции. Другой вопрос, как много таких
btnвы хотите создать.Удобнее будет написать
btn-primary-with-a-little-more-horisontal-paddingsилиbtn-primary px-6?С другой стороны, кто выигрывает от таких абстракций? Они безусловно удобны, когда нужно сделать однотипный интерфейс с помощью, например, Bootstrap. Но объясните мне, какое конкретно преимущество получает разработчик, когда видит
btn-primaryвместо конкретных стилей.Вы скажете, что такая инкапсуляция позволяет быстро ориентироваться в больших объемах разметки. Это верно. Однако, по-моему, она сильно мешает при современном компонентом дроблении кода. Если я уже зашел в компонент
<Button/>, я не хочу видетьclass="btn-primary", я хочу видеть конкретные стили.Вы правы. Это тот же самый CSS, только в другой обёртке.
Речь как раз о том, что такой способ написания того же самого по сути CSS значительно удобнее и нагляднее, отлично комбинируется с идеей о компонентах как переиспользуемых элементах, из которых собирается приложение.
Ваши стили всегда при вас, они не записаны в каком-то другом файле на чёрт знает какой строке.
Если вам нужно перенести какой-то элемент, например, из старого проекта в новый, вы просто копируете разметку и вуаля, он такой же, каким был и там.
Какую конкретно проблему мы решаем? Автоматизация процесса верстки? Тогда почему вся статья о создании основного макета.
Или мы хотим автоматизировать создание основного макета? Тогда это бессмысленно, учитывая, что сейчас поддержка Flexbox — 98,5%, поддержка Grid — 95% и "руками" все делается достаточно легко.
Тоже верно. Для портфолио даже то, что я сделал — оверкилл. Моё старое было на Gatsby и хостилось на бесплатных мощностях Zeit Now/Vercel.
Я не говорю, что мой подход, — production-ready best practice. Я сам новичок во всем этом. Спасибо за предложение, я обязательно разберусь. Вполне возможно, ваш вариант лучше.
Мы все делаем вид, что unstated-next не существует, я правильно понимаю?