Fullstack Founder

Метка: react

  • Local-First веб-приложения

    Local-First веб-приложения

    Пропал интернет и приложение перестало работать, потому что все данные оно получало с удалённого сервера. Сообщения не прочитать, документы не отредактировать, а таск-трекер сломался. Знакомая картина?

    Большинство веб-приложений остановит работу, но не все. Набирает популярность новая (или хорошо забытая старая) парадигма Local-First: веб-приложение всегда работает с локальной базой данных, а интернет нужен только для синхронизации.

    Подход внедряют у себя Linear, Miro, Trello, Figma, Notion, Excalidraw, Replit, Obsidian и растущее множество веб-приложений.

    Чтобы реализовать Local-First, разработчикам нужно решить ряд технических вопросов:
    – В какой локальной базе хранить данные?
    – Как приложение должно себя вести при отключении от интернета?
    – Как синхронизировать изменения без конфликта?

    Для всех этих ситуаций есть теоретическая база — структуры данных CRDT и алгоритмы синхронизации, написаны библиотеки для фронтэнда на React и Vue, разработаны базы данных.

    Выигрыши для пользователя:
    – Высокая отзывчивость интерфейса и моментальное сохранение изменений у пользователя.
    – Непрерывные сеансы работы в приложении — выше продуктивность.

    Замечу, что пользователь ожидает, что ваше приложение будет отзывчивым и поддерживать оффлайн-режим. Внедрение улучшит пользовательский опыт, но вряд ли станет главной фичей. Скорее всего, Local-First подход скоро станет частью фреймворков разработчиков и незаметно распространится.

  • Фуллстек парадокс

    Фуллстек парадокс

    В начале 2000-х в веб-разработке не было фронтэндов или бэкэндов.
    Была профессия вебмастер. Этот человек мог сделать сайт целиком. Он умел общаться с полиграфическим дизайнером про внешний вид сайта, верстать HTML таблицами, оптимизировать графику, писать java script. Стек был небольшой и было мало слоёв абстракции.
    Если было нужно что-то покруче, звали программиста и он писал CGI-скрипты на Perl, PHP или C.

    Прошло 25 лет. В этом году искал для клиента fullstack-разработчика. Вакансии такие на рынке есть. Например, одновременно с моей вакансией продвигали объявление от Теремка на такой же стек. На такую вакансию массово откликаются фронтэнд-разработчики. Почему так?

    В момент, когда фронт научился писать запросы к базе данных и создавать API-методы, он достиг своей полноты. В его мировоззрении всё жизненное пространство в этот момент освоено. Всё так, но для бэкэнд разработчика уровень фронтов на его территории — Intern или Junior.

    Современный бэкенд разработчик часто знает HTML, CSS и Java Script. Может так случиться, что был у него опыт разработки на React, но он не будет считать это значительным достижением. Хорошо, если в резюме укажет. Его территория упирается с одной стороны в серверное администрирование и облака, с другой находится уровень железа: производительность процессора, работа с памятью, операции чтения и записи на жесткий диск. Пляж фронтэндов находится на периферии его владений и занимает небольшой участок с выходом в море.

    Зрелый бэкенд разработчик может в море не плавает, но может залезть в код на фронте, сделать необходимое “чтобы работало” и пойти делать свои дела. Вряд ли он уделает фронта на его территории, но у него есть ощущения “тут всё понятно”.

    Количество абстракций в процессе разработки выросло. У пирога было три слоя, а в современном рецепте их пятнадцать. Изобретают новые фреймворки, меняются библиотеки и подходы. Рынок делает веб-программирование всё более абстрактным и сложным.

    Практические выводы:
    – Если вам нужен в команду разработчик с полным спектром знаний — ищите сеньора бэкендера, у которого был опыт работы на фронте. Вакансии Веб-разработчик, Программист или Backend-developer. Но делать фронт его руками очень дорого.
    – В команду нужно брать и фронтов и бэков. Бэки будут ворчать и не хотеть делать задачи фронтов, фронты не владеют всей картиной происходящего на бэке.
    – LLM уже сейчас помогает бэкендерам делать сносный фронтэнд. Скоро всё перемешается снова.

  • Какой язык программирования учить в 2025 году?

    Какой язык программирования учить в 2025 году?

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

    Я бы порекомендовал начинать с HTML, JavaScript и SQL. При этом только один из них полноценный язык программирования.

    Объясняю выбор:
    HTML — простейший язык разметки, а не программирования. Все сайты сделаны на нём. Он описывает по очереди все блоки страницы: где заголовок, где картинка, где ссылка. Его родитель XML встречается всё чаще по мере погружения в IT. На нём построен промышленный обмен данными: маркетплейсы со своими форматами, 1С со своими, RSS-подписки, конфигурация роутера. Даже SVG-картинки, разметка интерфейса в Android, сообщения в телеграме — это частные случаи XML.

    JavaScript — содержит все основные логические конструкции и прост в изучении. Живучий как таракан. Я работал с ним с 2001 года в форматах JavaScript для сайтов, ActionScript в приложениях на уже устаревшей технологии Flash, Google Apps Script для автоматизации Google Sheets. Популярные React, Vue, MongoDB и повсеместно используемый JSON — тоже экосистема этого языка. Я уверен, что поменяются все технологии и устройства, а какая-то разновидность JavaScript будет применяться и там.

    SQL — язык запросов к базам данных. Знание его принципов и логики позволяет вытаскивать полезную информацию из баз данных, а также лучше проектировать таблицы в Excel. Пригодится программистам всех видов, аналитикам и дата сайнтистам.

    Когда освоитесь с этой базой и начнёте писать простые проекты — тогда уже стоит выбирать основной язык для дальнейшего углубления.

    Дальше уже можно углублять знания и практику, переходить на TypeScript, Python, Java, C#, Rust, Go или Ассемблер. А если задача узкая и прикладная: Erlang, R, Lua, Cobol или Solidity — все несут за собой конкретную практическую область.
    Программисты переключаются с языка на язык гораздо легче, чем кажется не-программистам. И даже могут под специфическую задачу изучить новый язык до приемлемого уровня за несколько вечеров.

    Но чтобы вы не изучали из “взрослых” языков и IT-систем — эту троицу совсем избежать не получится. А лучшее время, чтобы начать изучать программирование — вчера.

  • Почему WordPress — это хорошо

    Почему WordPress — это хорошо

    Почему WordPress — это хорошо.

    Идут баталии React vs Vue, у новичков стоит вопрос выбора Python/TypeScript/PHP/Rust/Go.

    В это же время из 200 миллионов активных сайтов 43% работают на WordPress. Нет более популярной CMS.

    На WordPress работают сайты NASA, New York Times, Techcrunch и каждый второй сайт, который вы открываете.

    WordPress как лидер рынка накопил множество претензий, большинство из которых связаны с плохой реализацией проектов на нём, а не с самой платформой. Если вы не любите WordPress, то вы просто не умеете его готовить.

    Самые частые жалобы:
    – Медленный? Посмотрите на лидеров рынка с огромной посещаемостью и настройте кэширование.
    – Взламывают? Надо было приложить небольшие усилия, настроить сервер и обновить плагины.
    – Неудобный? Большая часть удобства состоит из привычки, а не из “интуитивности”.

    WordPress действительно несколько опоздал на фестиваль современных технологий. Но догоняет всеми силами.
    Под капотом вы найдёте привычные и любимые разработчиками инструменты. React и REST API — из коробки. Консольную утилиту WP-CLI. Поддержку продвинутого кэширования с помощью Redis, memcached и php-op.
    Пара шагов чуть глубже и появится возможность использовать git, composer, s3, CI/CD, пре-процессоры и сборщики JS/CSS. А как насчёт использования blade-шаблонизатора от Laravel и классов Symfony?

    Старичок живой, весёлый и развивается, несмотря на скандалы, брюзжание и выход из моды.

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

    Если ваш сайт можно сделать с помощью WordPress — скорее всего, это будет оптимальным выбором.

  • React vs Vue

    React vs Vue

    Сегодня получил замечательный вопрос, что выбрать — React или Vue для фронтэнда в стартапе. Кто не в курсе, это две доминирующие технологии для создания динамических интерфейсов. Их используют социальные сети или большие веб-сервисы.
    Замечательный он тем, что сегодня я на него отвечу по-разному, в зависимости от того, кто спрашивает.

    Спрашивает новичок-разработчик — выбирай Vue.
    – Он проще устроен, его легче изучить.
    – По отзывам нескольких команд и десятка разработчиков, на нём приятнее писать.
    – Он быстрее собирается и быстрее работает во время разработки. Разница не очень большая, но это приятно.
    – С ним проще начинать новые проекты.
    – Легче использовать повторно внутренние компоненты.
    – Vue-разработчиков меньше, чем у React. А значит меньше конкуренция и выше шансы попасть в хорошую команду.

    Спрашивает стартап — выбирай React.
    – На рынке больше разработчиков, значит конкуренция будет выше и будет проще найти хорошего сотрудника.
    – Как следствие — легче масштабировать команду.
    – Развитая экосистема — скорее всего, самые сложные технологические вопросы в экзотической области уже решены. Часто достаточно будет установить готовую библиотеку или плагин.
    – Реакт более узнаваемое слово, что может сыграть вам на руку при общении с инвесторами.

    Спрашивает опытный разработчик — он не спрашивает, он попробовал и сам вам расскажет почему нужно взять именно этот фреймворк.

    Правильного выбора здесь нет. React, Vue, Svelte, Ember, Preact, Solid, Alpine, Livewire, Angular, Backbone, Ext JS…

    Лучший фреймворк тот, который ваша команда уже знает и знает хорошо. Если у вашей команды есть ответ на чём писать — пишите на этом. Скорость важнее, а MVP в любом случае будет значительно переосмыслено и переписано через время.

    Посмотрите на цикл хайпа Gartner — он хорошо показывает, насколько технология готова к применению на практике. Не выбирайте самую новую технологию, не выбирайте самую хайповую. Берите ту, которая уже немного надоела и у которой очень высокая доля рынка. Выбирайте взрослое и популярное, это хотя бы безопасно. Именно скучные, хорошо знакомые технологии чаще всего приводят к выпуску продукта, а не к вечному рефакторингу.