Большие языковые модели, такие как GPT-4, с угрожающей скоростью становятся все более эффективными. Через пару лет нам больше не понадобятся разработчики!
...Или, по крайней мере, такая позиция становится вирусной в Твиттере. Я гораздо более оптимистично смотрю на то, что эти достижения ИИ означают для будущего разработки программного обеспечения.

Тут нет правильного варианта ответа, это вкусовщина. Единственная цель этой статьи – узнать ваше мнение по этому вопросу и окончательно сформировать своё, потому что сейчас я в сомнениях.

Не знаю, какие там проблемы в других сферах программирования, мой вопрос касается фронтенда.

Независимо от того, каким фреймворком вы пользуетесь, и пользуетесь ли вообще, у нас есть HTML-шаблон и JavaScript-код. Код частично залезает в шаблон, и тут и появляется наша проблема. От чего отталкиваться при названии функций?

Вы знаете, как пишутся SPA на Laravel? Если коротко, не очень удобно. Конечно, можно использовать любой фронтенд-фреймворк. Традиционно принято работать со связкой Laravel + Vue.js.

Мы пишем весь фронтенд на Vue.js в resources/js, а Laravel используем как API.

Примерно вот так:

Vue.js

// resources/js/pages/Users.vue
<template>
    <div v-for="user in users" :key="user.id">
        <a :href="`/users/${user.id}`">
          {{ user.name }}
        </a>
        <div>{{ user.email }}</div>
    </div>
</template>

<script>
    export default {
        data() {
            return {
                users: []
            }
        },
        methods: {
            async loadUsers() {
                const { data } = await this.$axios.get('/api/users');.
                this.users = data;
            }
        },
        async beforeMount() {
            await this.loadUsers();
        }
    }
</script>

Laravel

// routes/api.php
Route::get('/users', function index(User $user) {
    return $user->all();
});

То есть сначала мы создаем на бэкенде эндпоинт, а затем на фронте получаем с него данные через AJAX-запрос.

Удобно ли это? Смотря для кого. Фронтендерам не привыкать. AJAX на сегодня – самый классический способ получения данных с сервера. Но, если вы до этого много работали с Blade, вы понимаете, насколько это больше телодвижений.

Современные фронтенд-фреймворки дают удивительные возможности. React, Vue, Angular и другие созданы делать то, что раньше было невозможно, – веб-приложения. В 2020 скачивать и устанавливать приложения уже необязательно. Зачем, если всё можно сделать на сайте?

Однако с большой силой приходит большое количество зависимостей. И находятся энтузиасты, которые решают, что поднять большой фреймворк для своего небольшого проекта, – не такая уж плохая идея. Даже если это просто лендинг.

В этом вопросе я поддерживаю "консерваторов". Не нужно писать лендинги и многостранички на Create-React-App, для этого пойдет и обычная статика.

Однако я также прекрасно понимаю тех, кто делает иначе. Современные фронтенд-фреймворки дают не только множество нового функционала, они очень удобны в использовании. А если мне нужно сделать простой сайт с парой страниц, у меня оказывается не очень то много выбора.

Что делать? Писать простыню HTML-разметки в одном файле? Хранить данные во view? Это не сделать шаг назад, это сорваться и упасть в пропасть. Это не просто неудобно, это идет вразрез с современной парадигмой фронтенд-разработки.

Во-первых, data-driven. Данные во главе угла, а внешний вид – лишь их отображение. Пользователь делает действие, данные меняются, вслед меняется отображение. Так работают все современные фреймворки.

Еще один элемент современного подхода – компонентность. Делим приложение на мелкие самодостаточные переиспользуемые куски. Больше переиспользуемости – меньше кода. Меньше кода – меньше багов.

До этого мы уже обсуждали, как реализовать data-driven минимальными усилиями. Мой выбор – Alpine.js. Что же делать с компонентностью? Для простых статических сайтов я предлагаю самый простой вариант – gulp-file-include.

Очевидно, я бы не стал писать эту статью, если бы считал, что TailwindCSS – просто очередной фреймворк. Я считаю, что он кардинально отличается от всех других фреймворков и создает отдельную парадигму web-стилизации. И при этом выполняет все поставленные перед ним задачи, делая это лучше и удобнее других.

Тех, кто еще не знаком с TailwindCSS, я постараюсь завербовать в ряды его поклонников. Тех, кто против него, я постараюсь заставить в этом усомниться и пересмотреть своё мнение.

Я также хотел узнать ваше мнение по этому поводу. TailwindCSS – это шаг вперед, назад или просто топтание на месте? Свой ответ вы можете оставить в опросе в конце статьи. А если вам есть, что добавить по теме, пожалуйста, сделайте это в комментариях.

Решил я тут своё портфолио сделать на Laravel 7. Чтобы главная страница была лендингом, а всю информацию на ней можно было менять с помощью админки. Не суть. Дело дошло до деплоя. Нашел пару хороших туториалов, как это сделать на полноценном сервере со всеми заморочками. В деплое я не очень силен, я вообще больше фронт, чем фулстек. И, если писать и тестить на PHP я еще могу, то до управления сервером и т.п. я еще не дорос. Но пришлось разбираться.

Сейчас пройдемся по всем шагам, начиная с запуска через SSH и заканчивая рабочим сайтом. Постараемся обойти все подводные камни.

Возможно, вы сможете найти аналогичные инструкции в интернете. Ведь я же в конце концов нашел. Правда не в одном месте, не без помощи StackOverflow и вряд ли на русском. Я помучился. Поэтому решил вам жизнь упростить.

Давайте поговорим о том, что внутри, под капотом Alpine.js. К концу статьи вы узнаете, как происходит создание современного реактивного фронтенд фреймворка путем написания оного своими руками. Это легче, чем вам кажется.

Эта статья – вольный перевод мини-курса Building AlpineJS от создателя библиотеки Caleb'а Porzio на Laracasts. Если вы в нормальных отношениях с английским и больше любите видео, чем текст, – милости прошу. 4 из 6 уроков бесплатны, остальные по подписке. Статья затрагивает только бесплатные уроки. В принципе, их нам будет достаточно, чтобы понять, что там внутри.

В прошлый раз, когда мы делали to-do на Alpine.js, меня очень сильно расстроило, что, хоть я и могу создавать вложенные компоненты, я не могу получать данные из родителя. Через какую-нибудь переменную, $parent, например.

Поэтому мне пришлось запихивать все яйца в одну корзину. Свойства и методы, отвечающие за добавление новых задач, перемешались со всеми остальными. Я хотел выделить отдельный компонент, но необходимость доступа к массиву todos меня ограничивала.

Если вы подумали, что это не очень хорошо, то вы не правы. На самом деле, это ужасно.

Всё, расходимся? Нет. Я еще раз полистал документацию и вспомнил про магическое свойство $dispatch. Ну, конечно… однопоточная связь, проброс событий. Ну давайте попробуем. А потом еще переосмыслим всё с глобальным store.

Во Vuex есть одна популярная практика — не использовать mapState и mapMutations. Вообще. Вместо это мы сразу же при создании нового значения в store делаем для него геттер, а для каждой мутации – экшен.

Что-то наподобие:

export default new Vuex.Store({
  state: {
    // 1
    count: 0
  },
  getters: {
    // 1
    count: (state) => state.count
  },
  mutations: {
    // 2
    increment(state) {
      state.count++;
    }
  },
  actions: {
    // 2
    increment({ commit }) {
      commit('increment');
    }
  }
});

Холивара не избежать. Это уже доказала вот эта статья. Опять в интернете кто-то не прав, и я должен доказать почему. И я докажу.

Возможно, вы уже слышали про Alpine.js. Если нет, то это "Vue.js на минималках". "Angular 1 для миллениалов". Называйте, как хотите, главное, чтобы вам было понятно.

Зачем нам еще один фреймворк? Ну, Alpine хорошо вписывается в свою нишу. По факту, он – альтернатива большим фреймворкам для сайтов, где эти большие фреймворки не нужны. Например, меня, модного web-developer'а, запрягли писать многостраничный сайт. Мне нужно элементарно сделать форму и всякий другой интерактив. Что я буду делать? Возьму jQuery – друзья не поймут, на чистом JS всё писать тоже не комильфо. К тому же я уже знаю реакты, ангуляры и вью, знаю, что такое data-driven подход. Как мне теперь данные до отправки в HTML хранить?

Тут и приходит на помощь Alpine.js. Можно, конечно, Vue или React прикрутить. Но React без JSX никто в здравном уме писать не будет, а Vue минифицированный через CDN весит 34 kB (против 8.1 kB у Alpine). Так и получается, что выбор падает на Alpine.