Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 7

Сейчас эпоха offline-first PWA приложений и игр. Они работают одновременно и на десктопе, и мобиле и в браузере (причем написанные один раз адаптивной версткой). Устанавливаются как нативные приложения.

Бекенд нужен для сложных вычислений, для синхронизации между устройствами, для предоставления данных, а не для отрисовки фронтенда. Бэкенд и фронтенд лучше разделить, а фронтенд скомпилировать в статические ресурсы и положить в CDN.

Если устали от сложных фреймворков, то посмотрите в сторону Фьюзора. Он задумывался как убийца Реакта и остальных фреймворков. Простая библиотека с 2 функциями - создать и обновить DOM элемент. Всё! Стейт менеджер подключаете свой если нужен. А если не нужен можно обычные переменные использовать.

При грамотной верстке, SEO прекрасно рабоает уже с 2018 года, в том числе и для SPA приложений.

Как человек, много лет пушущий на htmx+hyperscript (тот же что альпайн, вид сбоку, интерактивность), могу сказать очевидное:

HTMX вполне работоспособен для одиночки-разработчика, для человека без команды, для человека пишущего и бэк (у меня это Го+его темплейты) и фронт в одно лицо.

Всё.

При любых иных условиях это древний, первобытный, ад лапши из кода фронта и бэка, на мешанине кода, который работает только пока ТЫ ЛИЧНО помнишь как он работает.

Зато в той описанной нише он прекрасен.

Я бы ещё в списочек к HTMX и AlpineJS добавил Lit.js. Помимо состояний у кнопочек нужны и сами кнопочки (можно и button использовать, но вдруг кастомное что надо?), а чтобы нормально и красиво их изолировать - можно использовать Shadow DOM. Можно и нативно, конечно, но Lit.js, судя по их заявлениям - упрощает это дело и позволяет полифиллиться.

похож на Vue .. так то так система реактивности Vue полная и чувак вдохновлялся им . еще есть petite-vue.

Куча *** от, предположительно, судя по содержанию, "модно-молодежного" веб-программиста.

  • "позволяют писать фронтенд без SPA фреймворков. "

    Я в конкртеном шоке: оказывается кто-то или что-то НЕ позволяет мне писать мои поделки без SPA... Мне их нужно удалить с особым цинизмом? Ну это... чтобы не нарушать какие-то законы... или что там нарушают те, кто пишет фронтенд без SPA.

  • "тоской по временам, когда задачи решались с помощью PHP и jQuery. "

    Нет никаких проблем с тем, чтобы, в настоящее время, решать задачи с помощью PHP и jQuery, кроме особо специфичных.

  • "Я всю жизнь писал JSON API и SPA интерфейсы"

    Это понятно из содержания опуса. Это печально...

  • "SSR v1 (Web 2.0, эпоха PHP)"

    В "модно-молодежных" меня больше всего раздражает не то, что они всегда пишут глючные SPA (кто я такой, чтобы указывать...), а то, что они не способны даже изучить куцую историю Web-разработки, но при этом поучают других людей (не запрещено ,конечно же, но... выглядит странно...).

    PHP использовался задолого ДО массового распространения JavaScript, которое, де-факто, и обозначило наступление эпохи Web 2.0. Некоторые считают, что 2.0 связано чисто с асинхронщиной, но это не меняет сути.
    Кроме того, PHP используется и сейчас побольше "модно-молодежного" шлака. Да и web 3.0 так и не наступил до сих пор, т.е. мы сейчас в том же 2.0 находимся.

    Не поверите, но crud можно и сейчас писать без js, кроме случаев, когда нужно 100500 опций вывести для селекта. Здесь без js будет очень громоздко и неудобно.

Дальше ниАсилил...

Я слона не заметил!!!
Причем типичного для SPAшников (и APIшников из бекендеров) слона. Только эти "специалисты" могут такое написать: "Он не поддерживает локальное состояние — весь state хранится на сервере. Все, что вы ввели в форму, все меню которые вы открыли, все это будет сброшено, после перезагрузки страницы."

По дефолту - не сохранялось. Но несколько строк кода решало эту проблему.

Невежество современных веб-программистов понятно - откуда им, с этими их SPA и API, знать про древние, как говно мамонта, сессии, в которых можно что угодно сохранять, а потом при перезагрузке страницы доставать? Причем доставать можно вообще на другой странице.

Про то, что кол-во приседаний, для организации аутентификации с хранением identity куки в сессии, значительно меньше (даже без фреймворков), чем при этих ваших токенах, которые вы гоняете туда-сюда, периодически устраивая срачи на тему "где хранить токен на фронтенде", а для смягчения проблемы секурной дырявости еще и сразу два токена создаете.

P.S.: Я в курсе CSRF. Только эта проблема решается намного проще(во всех попсовых php-фремворках давно уже решена и лежит под капотом), чем весь этот кардебалет с токенами.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации