Заголовок статьи может показаться немного кричащим, впрочем как и сам фреймворк Svelte и те идеи, что стоят за ним. Если вы ещё не знаете ничего про Svelte, пристегнитесь, сейчас мы рванём навстречу революции.
Учтите, что это не урок по началу работы со Svelte. Уже существует прекрасное пошаговое интерактивное руководство от команды Svelte, которое погрузит вас в мир реактивного программирования.
Хайп по Svelte после недавнего релиза 3 версии фреймворка всё-таки имеет место быть, чему свидетельствуют сильно возросшее комьюнити и огромное количество вопросов как в официальном чате, так и в нашем рускоязычном telegram-канале. Всё больше разработчиков украдкой или всерьёз присматриваются к этой технологии и задумываются о её применении в своих новых проектах. Для этих разработчиков и всех прочих интересующихся темой максимально эффективного написания кода, Rich Harris, автор и идеолог фреймворка, опубликовал статью о том, как Svelte помогает разработчику минимизировать усилия при создании современных реактивных web-приложений, перевод которой я и предлагаю ниже.
Буквально на днях произошло большое событие в сообществе SvelteJS, да и вообще, как мне кажется, для всего современного фронтенда — долгожданный релиз Svelte 3! Посему, под катом перевод статьи автора Svelte и прекрасное видео с его доклада на YGLF 2019.
Любой веб-разработчик, который занимается этим хотя бы несколько лет, наверняка день за днем слышит подобный вопрос:
Я действительно хочу стать веб-разработчиком, но я не знаю с чего начать. Есть какие-то предложения?
Лет 10 назад ответ был очень прост. Просто создайте index.html, добавьте туда несколько тегов, сделайте заголовок красным с помощью CSS и подключите JQuery для обработки кликов!
Ох, как же все изменилось. Теперь мы работаем с инструментами сборки, маршрутизацией на стороне клиента, специальными фреймворками с причудливым рантаймом, привязывая везде «this», шаблонными литералами, CSS-in-JS… как же выбрать то, что важнее всего?
Читать полностью »
Привет, хабровчанин! Дизайнеры люди идейные, а заказчики с их бизнес-требованиями, тем более.
Представь, что ты сваял свой самый лучший UIkit на свете на самом крутом %вставить свое% JS фреймворке. Казалось бы, там есть все, что нужно проекту. Теперь-то ты сможешь пить кофе, а все новые задачи закрывать накидыванием компонентов на страницу. Еще лучше, если ты нашел такой UIkit на помойке на просторах NPM и он идеально соответствует текущему UX/UI и его потребностям. Фантастика!
И действительно… кого я обманываю? Твое счастье, скорее всего, будет недолгим. Ведь когда дизайнер прибежит с талмудом новых UI-решений для очередной страницы или «спец-проекта», что-то по-любому пойдет не так.
В этот момент перед разработчиком встает вопрос «DRY или не DRY»? Стоит ли как-то кастомизировать существующие компоненты? Да еще так, чтобы не отхватить регрешн на существующих кейсах. Или же действовать по принципу «работает — не трогай» и написать новые компоненты с нуля. При этом, раздувая UIkit и усложняя поддержку.
Если ты, как и многие, бывал в такой ситуации, загляни под кат!
Всем привет, хочу поделиться результатом размышлений на тему — каким может быть современное веб-приложение. В качестве примера рассмотрим проектирование доски объявлений для комиксов. В некотором смысле рассматриваемый продукт рассчитан на аудиторию гиков и им сочувствующих, что позволяет проявить вольность в интерфейсе. В технической же составляющей, напротив, необходимо внимание к мелочам.
По правде говоря, я ничего не понимаю в комиксах, но люблю барахолки, особенно в формате форума, какие были популярны в нулевых. Отсюда, допущение (возможно ложное), из которого проистекают последующие выводы, только одно — основной тип взаимодействия с приложением — просмотр, второстепенные — размещение объявлений и обсуждение.
Нашей целью будет создание простого приложения, без технических ноу-хау лишних свистелок, однако соответствующее современным реалиям. Основные требования, соблюдения которых хотелось бы достичь:
В последнее время набирает популярность тренд «исчезающих фреймворков», локомотивом которого, без сомнения, можно считать SvelteJS — buildtime-фреймворк и компилятор в ванильный javascript.
Несмотря на то, что концептуально Svelte весьма прост, а в использовании еще проще, многие разработчики задаются вопросом, в чем же killer-фича данного фреймворка, да и подхода в целом? Почему это не «yet another javascript framework»?
В этой статье я расскажу про одну из множества суперспособностей Svelte, которые могут всерьез облегчить вам жизнь.
Давайте разберемся, но сначала я расскажу вам одну легенду…
Эта статья является ответом на статью-перевод «Как сделать поиск пользователей по GitHub используя React + RxJS 6 + Recompose», которая буквально вчера научила нас как надо использовать React, RxJS и Recompose вместе. Что ж, предлагаю теперь посмотреть, как это можно реализовать без оных инструментов.
Вдохновившись статьями SvelteJS: Релиз второй версии, Исчезающие фреймворки и Re: «Сравнение JS-фреймворков: React, Vue и Hyperapp», про «исчезающий» фреймворк Svelte (читается «свелт», а то мало ли), я захотел его попробовать. И для начала решил написать небольшой компонентик с кнопками из Materialize.
Читать полностью »
Это небольшая ответная статья на публикацию «Сравнение JS-фреймворков: React, Vue и Hyperapp». Вообще я не большой фанат подобных сравнений. Однако раз уж речь зашла о таком маргинальном фреймворке, как Hyperapp, в сравнении с мастодонтами, типа React и Vue, я подумал, почему бы не рассмотреть все те же примеры на Svelte. Так сказать, для полноты картины. Тем более, это займет буквально 5 минут. Поехали!
