Comments 61
UFO just landed and posted this here
Небольшое уточнение. По состоянию на дату публикации расшифровки, последняя версия — 3.3.4
Все верно, это транскрибация моего доклада с FrontendConf 2018, который был уже полгода назад. Почти месяц назад вышел Svelte 3, подробнее о котором можно почитать тут.
И хотелось бы услышать что есть из готовых компонент, сколько пришлось писать с нуля, что взяли уже готового. Потому что фреймворк интересный, но писать все с нуля банально можно не успеть.
Готового пока откровенно мало, именно потому что довольно мало людей пользуются им в продакшн. У нас такой проблемы нет, потому что интерфейсы по большей части кастомные, а доработка готовых UI-китов, в наших условиях, давно показала свою неэффективность.
Svelte довольно лаконичный и в тоже время мощный, поэтому компоненты на нем пишутся очень быстро.
Похоже кто-то с камнями бесконечности поигрался)
Спасибо за презентацию, подход Svelte интересен, хотя бы с теоретической стороны. Вообще JS хреноват как язык для такого подхода как статический анализ, так что разработчикам мое почтение. Может и другие их подход подхватят.
P.S. все-таки тут
bundlephobia.com/result?p=react-dom@16.8.6 — 103.7KiB* (+6.5KiB от react@16.8.6)
bundlephobia.com/result?p=vue@2.6.10 — 63.5Kib
bundlephobia.com/result?p=jquery@3.4.1 — 86Kib
Vue даже с Vuex весит меньше jquery. React весит по-больше, но не прям на много. Даже с MobX — менее 200KiB. Еще есть Preact, который сам по себе — менее 10KiB
* здесь и далее не сжатая, но минифицированная версия.
P.S. все-таки тут
Страниц весом несколько мегабайт становится больше, и существенная часть этого объема — фреймворк сам по себе.автор перетолстил.
bundlephobia.com/result?p=react-dom@16.8.6 — 103.7KiB* (+6.5KiB от react@16.8.6)
bundlephobia.com/result?p=vue@2.6.10 — 63.5Kib
bundlephobia.com/result?p=jquery@3.4.1 — 86Kib
Vue даже с Vuex весит меньше jquery. React весит по-больше, но не прям на много. Даже с MobX — менее 200KiB. Еще есть Preact, который сам по себе — менее 10KiB
* здесь и далее не сжатая, но минифицированная версия.
Это все равно съедает или приличную долю, или весь ваш бюджет для мобильной страницы при условии неустойчивого соединения.
Если вы сидите в офисе, и к вашей док-станции подходит шнурок с гигабитной сеточкой — то проблемы, действительно, почти нет. Упираемся лишь в производительность слабых ноутбуков.
Не могу сказать про современные фреймворки, но вот с jquery есть такая фишка, что добавив jquery однажды, вам сложно остановиться. Вы ведь хотите модальные окна? jquery-ui. Может быть, вывести табличку рекордов? jquery-grid. Добавить мультиязычность?…
Я слежу за одним проектом, там у человека уже несколько мегабайт зависимостей.
Если вы сидите в офисе, и к вашей док-станции подходит шнурок с гигабитной сеточкой — то проблемы, действительно, почти нет. Упираемся лишь в производительность слабых ноутбуков.
Не могу сказать про современные фреймворки, но вот с jquery есть такая фишка, что добавив jquery однажды, вам сложно остановиться. Вы ведь хотите модальные окна? jquery-ui. Может быть, вывести табличку рекордов? jquery-grid. Добавить мультиязычность?…
Я слежу за одним проектом, там у человека уже несколько мегабайт зависимостей.
автор перетолстил.
Возможно лишь немного сгустил краски, хотя:
Один небезызвестный проект.
Vue даже с Vuex весит меньше jquery. React весит по-больше, но не прям на много. Даже с MobX — менее 200KiB. Еще есть Preact, который сам по себе — менее 10KiB
Боюсь, если фреймворк занимает 100Кб, при этом вы не написали на строчки кода, то бюджет в 130Кб будет выжжен очень и очень быстро.
Заголовок не соответствует содержимому.
Еще одна статья о том какой клевый фреймворк Svelte, причем состоящая из материалов с сайта svelte.dev
Еще одна статья о том какой клевый фреймворк Svelte, причем состоящая из материалов с сайта svelte.dev
Заголовок не соответствует содержимому.
Если вы имеете ввиду, что большая часть доклада посвящена именно Svelte, то могу отметить, что это одна из причин наличия слайда «Чего не должно быть в докладе». Я действительно хотел сделать доклад более обезличенным в плане фреймворка, но процессе работы над ним, понял что без конкретных примеров будет совершенно не ясно. Так как все подобные штуки работают по-разному, рассказать хватило бы времени только о том, что знаешь лучше всего. В целом не вижу в этом ничего дурного.
Кроме того сам термин «изчезающий фреймворк» был придумал именно как tagline для Svelte и по-большому счету имеет к остальным компилируемым фреймворкам лишь опосредованное отношение.
Еще одна статья о том какой клевый фреймворк Svelte, причем состоящая из материалов с сайта svelte.dev
Это не так. Во-первых, svelte.dev — это сайт для Svelte 3, а доклад по Svelte 2. Во-вторых, доклад основа на моем личном опыте использования Svelte в реальных проектах на протяжении почти 1,5 лет.
Я вот писал в свое время на Qt, потом трогал реакт, и понял, что вот — наконец графику можно писать удобно. JSX в сочетании с JS неплохо себя показал, потом видел либу с расто макросами для этого же. И тут я подумал, что в принципе не долог тот день когда это станет как удобно так и быстро. Наличие большого выбора, означает лишь то, что идет работа над различными решениями. Во времена когда я был в школе, я мог собрать код только в GCC а сейчас есть компиляторов 5-6. Сейчас есть wasm, а ведь webassembly умер, но оказалось умер потому, что или плохо или не нужно было. Все будет но не сразу, и там наверное не нужно будет даже умирать.
Спасибо больше автору за статью. В общем подход понятен, но остается парочка вопросов которые почему-то не освещены:
1. Насколько удобно отлаживать JS код после такой «кодогенерации»?
2. Как компилятор Svelte генерит код специфический для того или иного браузера?
1. Насколько удобно отлаживать JS код после такой «кодогенерации»?
2. Как компилятор Svelte генерит код специфический для того или иного браузера?
Эти вопросы так или иначе фигурировали уже после доклада во время вопросов. Если кратко:
1) Для этого есть вполне рабочие source maps
2) Никак не генерит. Компилятор Svelte вообще генерирует ES6 код. Далее, если вам нужен даунгрейд до каких-то таргетов, вы можете использовать Babel как обычно и подключаете полифилы, типа corejs.
1) Для этого есть вполне рабочие source maps
2) Никак не генерит. Компилятор Svelte вообще генерирует ES6 код. Далее, если вам нужен даунгрейд до каких-то таргетов, вы можете использовать Babel как обычно и подключаете полифилы, типа corejs.
Svelte — магически исчезающий фреймворк. WAT?
Почему фреймворки стали исчезать?
Вот именно, тупость полная написана.
Вот именно, тупость полная написана.
А можно чуть раскрыть мысль?
Во-первых, исчезающие фреймфорки — это если бы фрейморки для js перестали существовать, это какой-то кликбейт.
А во вторых, «магически исчезающий» такого понятия нет и это выглядит как бред.
А в третьих, называть компиляцию исчезновением, такой же бред как называть языки, которые можно скомпилировать в машинный код, исчезающими.
А во вторых, «магически исчезающий» такого понятия нет и это выглядит как бред.
А в третьих, называть компиляцию исчезновением, такой же бред как называть языки, которые можно скомпилировать в машинный код, исчезающими.
Во-первых, исчезающие фреймфорки — это если бы фрейморки для js перестали существовать, это какой-то кликбейт.
А во вторых, «магически исчезающий» такого понятия нет и это выглядит как бред.
Это понятие уже неоднократно встречалось как в сети в целом, так и на хабре в частности. Правда, почти всегда речь шла о Svelte v1-v2.
А в третьих, называть компиляцию исчезновением, такой же бред как называть языки, которые можно скомпилировать в машинный код, исчезающими.
Фреймворк — это средство и инструменты для унификации, стандартизации, ускорения разработки приложения. При компиляции эти средства и инструменты пропадают, остаётся только ванильный JS, который мы могли бы написать и без фреймворка, но без всего вышеперчисленного. Традиционным фреймворкам все эти средства приходится тащить в рантайм, иначе не работает.
Можно назвать магически исчезающей типизацией процесс транпcиляции typescript->javascript. Это просто красивые слова.
Даже страшно подумать, как вы прокомментируете «кибернетически улучшенные веб-приложения»)))) Простите, но вообще звучит как какое-то занудство.
Кто объяснит такую простую вещь, почему в Рунете только от PaulMaly мы слышим про Svetle?
Почитал про фреймворк (с месяц назад, время было разобраться) — да, подход к синтаксису — примерно, как у Vue (есть специальные атрибуты), для моей задачи не потребовалось, когда был нужен минимальный порог вхождения в проект для продолжателей, плюс к тому, вместо mobX/Redux там что-то оригинальное предлагают, обойтись тем, что в фреймворке есть.… Скорее всего, работать будет и чуть быстрее из-за компилируемости, но, естественно, мало наработок компонетов таблиц и вебформ всяких по сравнению с Реактом и тем же Вью. Звёзд на Гитхабе много. Документировано отлично, на сложные вопросы отвечает основной разработчик (Rich Harris). Серверный рендеринг — тоже есть. (Ну совсем сомнительно, почему же он не порвал всех с 2016 года?) Почему в бизнес-задачах в России не берут и не пользуются?
У евангелиста, может быть, работа такая, и он не скажет, что со Свелтом «не то»? Может кто-то пояснить, кто пробовал и натыкался на проблемы?
UPD: эта статья смахивает на ту же евангелистскую. Про проблемы: "… Конечно, есть проблемы, но не больше, чем в других фреймворках". Всё. А какие проблемы? Какие специфические и конкретные проблемы он имеет?
Почитал про фреймворк (с месяц назад, время было разобраться) — да, подход к синтаксису — примерно, как у Vue (есть специальные атрибуты), для моей задачи не потребовалось, когда был нужен минимальный порог вхождения в проект для продолжателей, плюс к тому, вместо mobX/Redux там что-то оригинальное предлагают, обойтись тем, что в фреймворке есть.… Скорее всего, работать будет и чуть быстрее из-за компилируемости, но, естественно, мало наработок компонетов таблиц и вебформ всяких по сравнению с Реактом и тем же Вью. Звёзд на Гитхабе много. Документировано отлично, на сложные вопросы отвечает основной разработчик (Rich Harris). Серверный рендеринг — тоже есть. (Ну совсем сомнительно, почему же он не порвал всех с 2016 года?) Почему в бизнес-задачах в России не берут и не пользуются?
У евангелиста, может быть, работа такая, и он не скажет, что со Свелтом «не то»? Может кто-то пояснить, кто пробовал и натыкался на проблемы?
UPD: эта статья смахивает на ту же евангелистскую. Про проблемы: "… Конечно, есть проблемы, но не больше, чем в других фреймворках". Всё. А какие проблемы? Какие специфические и конкретные проблемы он имеет?
Почему в бизнес-задачах в России не берут и не пользуются?
За всю Россию не скажу, но есть моменты, по которым я пока на Svelte не ставлю.
В React можно выбирать между Babel, Typescript или ванильным JS с рантайм-хелпером. Это позволяет более гибко развивать проект, можно переключаться между инструментами, и не надо переписывать его с нуля, если захотелось добавить тайпинги, например.
А Svelte это монолитный инструмент, фреймворк и билд-тул в одном флаконе. Тут свой особый формат файлов, с которым обычный тулинг работать не научен. Все целиком завязывается на понимание формата svelte-файлов. Поэтому работа стопорится на базовых элементах, вроде прикручивания линтера.
Кто объяснит такую простую вещь, почему в Рунете только от PaulMaly мы слышим про Svetle?
Наверное потому что у меня типа много свободного времени ;-) А если серьезно, должен же кто-то. Как начиналась моя первая статья про Svelte в 2017 году:
Довольно странно, но до сих пор на Хабре нет ни одной статьи об этом, как минимум, очень интересном инструменте разработки. Возможно это связано с тем, что данный фреймворк довольно молод, также как и идея, лежащая в его основе. А может быть все дело в постоянном хайпе разжигаем вокруг «большой тройки» фронтенда и закрывающем обзор альтернативных решений. Точно не знаю, но постараюсь исправить данный просчет в этой статье. Не переключайтесь.
До сих пор суть думаю не изменилась.
Почему в бизнес-задачах в России не берут и не пользуются?
По-сути до Svelte 3 сам автор не сильно пиарил свой же фреймворк, потому что первая версия — была скорее проверкой концепции, вторая все еще несла в себе часть «легаси» подходов из предыдущего фреймворка RactiveJS и выглядела недостаточно аутентичной. Мне кажется после пропыва, который комьюнити сделало со Svelte 3, теперь сам автор почувствовал, что основные шероховатости сглажены и можно выходить более активно. Отсюда и нарастающий хайп.
У евангелиста, может быть, работа такая, и он не скажет, что со Свелтом «не то»? Может кто-то пояснить, кто пробовал и натыкался на проблемы?
UPD: эта статья смахивает на ту же евангелистскую. Про проблемы: "… Конечно, есть проблемы, но не больше, чем в других фреймворках". Всё. А какие проблемы? Какие специфические и конкретные проблемы он имеет?
Самые «страшние» проблемы, которые известны мне. В основном из комментариев на Хабре и вопросов к моим докладам:
- Нет и никогда не будет, поддержки JSX. Мне этого не понять, но для многих это жирный минус.
- Нет поддержки Typescript. Есть экспериментальный препроцессор, который впрочем дает TS только в скрипте, но не шаблонах.
- Мало готовых решений и слабо развитый туллинг.
- Мало легаси кода, поэтому зачастую бывают breacking changes.
- Нельзя пуляться инициализированными компонентами в пропсы, только передавать их класс и инициализировать уже внутри компонента. Либо через slot'ы.
- Страшная вещь, но нельзя напихать кучу компонентов в один файл. Всегда один файл — один компонент.
- Еще одна страшная вещь, 2way-binding для input type=number автоматом приводит значение к number, а пустую строку к undefined. Если нужно другое поведение, надо использовать (страшно сказать) обработчик события oninput или onchange
Есть такая фраза «innovators must die», которая означает, что все кто придумал что-то новое, должны усыпать дорогу своими трупами для тех, кто идет за ними. Так произошло с Ractive, подражатель которого, Vue, очень даже не плохо себя чуствует. Вижу своей задачей, чтобы такое не случилось со Svelte, потому что не считаю что это правильно.
которая означает, что все кто придумал что-то новое, должны усыпать дорогу своими трупами для тех, кто идет за нимиСкорее потому, что vue пиарился гораздо сильнее.
Спасибо, хорошо перечислено. Мне как раз тоже критично было наличие JSX, т.к. это — устоявшиеся правила шаблонизации, т.е. не надо с новым фреймворком заапоминать новый метаязык. Со Свелтом — как раз надо из-за подхода кодирования функций в атрибутах, как у Vue.
// почему в Рунете только от
я не могу раскрывать данные, но могу свидетельствовать, что видел проект на Svelte для одной крупной компании, сделанный одним из ведущих JS-разработчиков Рунета (он является организатором одной из крупных конференций по JavaScript).
я не могу раскрывать данные, но могу свидетельствовать, что видел проект на Svelte для одной крупной компании, сделанный одним из ведущих JS-разработчиков Рунета (он является организатором одной из крупных конференций по JavaScript).
UFO just landed and posted this here
UFO just landed and posted this here
В целом все написано верно и по делу. Спасибо. Несколько дополнений:
Да, но только если переменная используется в шаблоне. Svelte старается держать DOM и стейт всегда синхронизированным и констентным без неободимости разработчику участвовать в этом. Обычно это удобно и очевидно.
Это сделано еще и для того, чтобы скронять работать с массивами/объектами в иммутабильной манере, потому что там Svelte эффективнее трекает изменения. Зная, чтоб arr.push(item) не перерисует DOM, начинаешь писать arr = [ ...arr, item];
Это синтаксический сахар над обсерверабл, которыми являются сторы, чтобы сделать работу с ними визуально синхронной. Очень удобно, жаль лишь работает только внутри компонентов. Из плюсов — этот сахар будет работать для любых обсерверабл, например RxJS или Effector.
Так, операция присвоения может вызывать сайд-эффект обновления компонента.
Да, но только если переменная используется в шаблоне. Svelte старается держать DOM и стейт всегда синхронизированным и констентным без неободимости разработчику участвовать в этом. Обычно это удобно и очевидно.
И если мы проводим операцию над объектом или массивом, например, arr.push(value), то Svelte не заметит её, пока мы явно не покажем ему присвоение:
Это сделано еще и для того, чтобы скронять работать с массивами/объектами в иммутабильной манере, потому что там Svelte эффективнее трекает изменения. Зная, чтоб arr.push(item) не перерисует DOM, начинаешь писать arr = [ ...arr, item];
Ещё один нюанс: $ перед именем переменной в Svelte работает не как обычный символ идентификатора, каким он является по стандарту EcmaScript, а полноценным спецсимволом для доступа к переменным стора:
Это синтаксический сахар над обсерверабл, которыми являются сторы, чтобы сделать работу с ними визуально синхронной. Очень удобно, жаль лишь работает только внутри компонентов. Из плюсов — этот сахар будет работать для любых обсерверабл, например RxJS или Effector.
А разве замена библиотеки или фреймворка готовыми кусками pure-JS-кода в перспективе роста проекта не ведёт к тотальному увеличению объема? Подобный "Компилятор" в итоге многократно продублирует множество единообразного JS-кода но в разных вариациях, разве нет?
Тоже об этом подумал. Для простого виджета или ToDo профит возможно есть, но для большого корпоративного портала весом несколько МБ будет сгенерировано много шаблонного кода для работы с DOM. В таком случае сотня КБ библиотек/фреймворков будет предпочтительнее.
Кто-то(Александр Федотов?) уже достаточно давно проводил исследование, что размер JS бандла Свелта сравняется с размером JS бандла Реакта примерно при 600 компонентах. Но врятли кто-то будет доводить до такого количества компонентов на одной вьюшке — тут явно будет сплиттинг кода — а тут у Svelte преиумущество — ему не надо рантайм прицеплять к каждому из этих кусочков.
В бандле код не дублируется — всё что переиспользуется, конечно, оптимизируется. Так что, о совсем нулевом рантайме Свелт, говорить — лукавство. Но в каждый бандл идёт только то, что реально используется, поэтому всё очень компактненько.
Пруф
Подобный «Компилятор» в итоге многократно продублирует множество единообразного JS-кода но в разных вариациях, разве нет?
Нет, общий код не дублируется в пределах одного бандла. Косты на размер каждого конкретного компонента не очень велики.
Каждый раз одни и те же вопросы, поэтому не обессудьте, дам свой обычный ответ: как правило, когда мы заканчиваем проект на Svelte, размер бандла меньше или сопоставим с размером обычных фреймворков, без кода приложения.
Называется также, но нужен для другого и делает другое) Кстати, именно из-за ангуляровского AoT, автор Svelte старается избегать этого термина. Хотя по сути это тоже AoT конечно.
В том-то и дело что позиционируется как киллер фича, но даже на самом сайте svelte как-то все очень обтекаемо написано, а главное не понятно что это мне как разработчику даёт в итоге.
I think of Svelte as writing the “framework” at compile time based on the specific needs of your application.
Вау круто конечно. Но непонятно.
UFO just landed and posted this here
UFO just landed and posted this here
Micro-frontends ready. Это очень хорошо для микро-фронтендов. У нас даже есть небольшой опыт, когда на каждой странице, которая отдавалась с сервера с помощью обычного PHP, находилось полностью независимое Svelte-приложение. притом, что общая кодовая база была единая. Мы просто набирали из разных компонентов, для каждой страницы собирали отдельно и получали абсолютно независимые приложения.
Давно полюбил такой подход. На него хорошо ложится «библиотечность» react-а, без всяких обвязок в виде роутера, стейт-менеджмента и т.д. Встроенного нового контекста и хуков хватает пока за глаза.
Использую такой подход для развития, рефакторинга и поддержки внутреннего symfony-приложения которое написали бекендеры, а бизнесу вдруг понадобилось чуть больше интерактивности и поддерживаемости чем может дать jquery + серверный form-builder.
Делается удобно и постепенно. Компоненты прекрасно переиспользуется между страничками. При этом сами реакт и реакт-дом подключаются отдельным бандлом, в результате чего при переходе между страничками — библиотека кешируется браузером, а грузится только написанный бизнес-код для конкретной страницы. Если заморочится, можно и часто используемые глупые компоненты в отдельный бандл сложить для кеширования. Получается более «нативный» code-splitting..)
То, что сейчас пилится в Angular под названием IVY — это не то же самое? Кажется, это можно даже уже пощупать там в каком-то приближении… Если есть у кого-то сравнительный анализ, было бы интересно послушать.
Шаблоны на js?
потому что они сделаны так, что в бандл добавляется только тот код, который вам нужен изначально
В банд будет добавляться тот код, что использовался когда-либо — https://github.com/webpack/webpack/issues/4453
Ух ты, баг двухгодичной давности про то, что вебпак неправильно делает tree shaking (о прекрасностях tree shaking в вебпаке обычно из каждого утюга несется). Спасибо за ссылку, у нас тут как раз есть проектик, который вскорости будет апгрейдиться с дремучего легаси, и который бы обязательно в этот баг вляпался бы.
А что делать-то?
Можно попробовать взять Rollup, который бандлит максимально эффективно, но с ним будут другие проблемы, например при импорте циклических зависимостей: https://github.com/rollup/rollup-plugin-commonjs/issues/278
Вот и остается выбор – либо выбираем webpack, который бандлит хоть и не оптимально, зато надежно, либо берем rollup, который бандлит на отлично, но иногда производит бажный код.
Sign up to leave a comment.
Исчезающие фреймворки