Комментарии 36
Учитывая, что я не видел автора в русскоязычном комьюнити Svelte в Телеграм (1К+ участников), делаю вывод, что автор и его команда приложили недостаточно усилий при освоения нового, неизведанного для себя инструмента.
А мы и не хотели прилагать очень большие и долгие усилия и изучать пол года его «костыли». Мы хотели его попробовать в качестве замены нашим текущим инструментам разработки, а именно Vue. Когда Мы попробовали Vue в первые после React даже половины таких проблем как у Svelte сейчас не было. Это было как глоток свежего воздуха, а со Svelte сейчас ты скорее задыхаешься и усложняешь себе жизнь.
Язык или фреймворк должен быть легким в использовании и обучении, с нормальной работающей и не путающей новичков документацией, не создавать препятствий на ровном месте.
Тратить кучу времени на решение тривиальных задач это удел энтузиастов в их проектах но не в энтерпрайзе когда есть сроки, заказчики. И потом еще поддерживать этот продукт.
У Вас есть проекты в энтерпрайзе на Svelte, у нас тоже. Мнения полярные… Мы не догматы в своей работе и поэтому попробовали что-то новое. Но разработчикам тоже должно нравится то, на чём они пишут, и у нас — им не понравилось (по крайней мере сейчас). У Вас — возможно понравилось.
Мне лично определенно понравились некоторые фишки svelte, как я писал в статье. Я бы очень хотел увидеть ивенты в Vue или чтобы через год Svelte «повзрослел».
Svelte может жить и может вытеснить Vue, но не сейчас. На это нужно еще время, спонсоры и комьюнити. Статья была о том, что Svelte пока еще сыроват.
Я написал целую статью для того, чтобы ответить на ваши вопросы. Как видите, этих вопросов просто не существует. Большая часть из них связана с тем, что вы взяли незнакомый для себя сборщик и не удосужились настроить его под нужды своего проекты, либо хотя бы взять более комплексное решение, коих десятки (см. ссылку в статье).
Вы говорите про тот Vue, в котором есть пару-тройку способов навесить event listener на элемент? Или про тот Vue, в котором минимум 4 стиля написания компонентов? По вашему это более понятно новичкам?
Стоп, вы точно пишете на Vue? У меня конечно закрадывались сомнения по ходу чтения всей вашей статьи, но не до такой же степени. Например, когда вы писали что во Vue якобы можно использовать стейт внутри стилей.
Вы хоть в курсе кто сформулировал подход «props down, events up» или когда вы изучали Vue вам тоже «не хотели прилагать очень большие и долгие усилия и изучать пол года»? Изучили как попало и начали ляпать проекты для заказчиков? Серьезно, изучили бы хоть один инструмент досконально, а не прыгали между ними как кузнечики.
Нет статья была о том, что у вас горели сроки, а вы взяли незнакомый инструмент и прогнозируемо огребли некоторые проблемы. Большая часть из которые и не проблемы вовсе, а просто непонимание и незнание инструмента и были бы решены за пару минут в чате сообщества.
Svelte был сыроват в 2017 году, когда мы первый раз взяли версию 0.5x для одного из проектов. В 2019 году 3-я версия Svelte вполне зрелая, но было бы странно желать менять фреймворка как перчатки. Если можно, не изучая инструмент, пересесть на него с другого, возникает вопрос, раз они так похожи, то зачем он нужен вообще?
Язык или фреймворк должен быть легким в использовании и обучении, с нормальной работающей и не путающей новичков документацией, не создавать препятствий на ровном месте.
Вы говорите про тот Vue, в котором есть пару-тройку способов навесить event listener на элемент? Или про тот Vue, в котором минимум 4 стиля написания компонентов? По вашему это более понятно новичкам?
Я бы очень хотел увидеть ивенты в Vue или чтобы через год Svelte «повзрослел».
Стоп, вы точно пишете на Vue? У меня конечно закрадывались сомнения по ходу чтения всей вашей статьи, но не до такой же степени. Например, когда вы писали что во Vue якобы можно использовать стейт внутри стилей.
Вы хоть в курсе кто сформулировал подход «props down, events up» или когда вы изучали Vue вам тоже «не хотели прилагать очень большие и долгие усилия и изучать пол года»? Изучили как попало и начали ляпать проекты для заказчиков? Серьезно, изучили бы хоть один инструмент досконально, а не прыгали между ними как кузнечики.
Статья была о том, что Svelte пока еще сыроват.
Нет статья была о том, что у вас горели сроки, а вы взяли незнакомый инструмент и прогнозируемо огребли некоторые проблемы. Большая часть из которые и не проблемы вовсе, а просто непонимание и незнание инструмента и были бы решены за пару минут в чате сообщества.
Svelte был сыроват в 2017 году, когда мы первый раз взяли версию 0.5x для одного из проектов. В 2019 году 3-я версия Svelte вполне зрелая, но было бы странно желать менять фреймворка как перчатки. Если можно, не изучая инструмент, пересесть на него с другого, возникает вопрос, раз они так похожи, то зачем он нужен вообще?
Может стоит признать наличие проблем? Вам говорят — «погружаться в Svelte тяжело, куча проблем», на что вы даёте ответ «погружаться не тяжело, вы просто читать не умеете или не хотите». Или «вы взяли неправильный роутер, где-то в множестве доступных есть правильный, где он, я вам не скажу, читайте доку и пробуйте сами».
Из этих статей я для себя решил — если svelte, то через пару лет, когда среднестатистическая команда сможет без написания таких статей и без чтения килотонны документации сделать админку.
Погружаться сложно в любой новый инструмент. Оригинальная статья же создает впечатление, что сложно погружаться только в Svelte. Хотя по факту выясняется, что автор просто не хочет погружаться, а хочет на шару, по бырику, стряпать проекты для заказчиков. Отсюда все проблемы со Svelte, отсюда незнание основ Vue и так далее.
Вот вы, полагаю, человек разумный. Наверное прочитали обе статьи. Какие конкретно моменты Svelte остались непонятными после прочтения моего ответа? Или может я как-то супер сложно запаривался чтобы решить их? Остался хоть один конструктивный пункт?
Вот вы, полагаю, человек разумный. Наверное прочитали обе статьи. Какие конкретно моменты Svelte остались непонятными после прочтения моего ответа? Или может я как-то супер сложно запаривался чтобы решить их? Остался хоть один конструктивный пункт?
Время погружения обратно пропорционально опыту в данной и смежных технологиях. Лично я почитал примеры и офф документацию денек и использовал в нескольких проектах. Мне зашло. Наверное основная причина — html-френдли интерфейс. Хотя я долго не хотел подходить к Svelte — пугало слово «магический». Лично мне не хвататет удобства в наследовании компонентов, а может не до конца разобрался. С композицией все супер — слоты, именнованные слоты. Как я понимаю, нет возможности взять и расширить компонент — можно только обернуть его (что скорее является композицией). Или я не прав?
Погружаться сложно в любой новый инструмент.
Попробовали бы вы Ruby on Rails после J2EE и вам стало бы понятно, почему Ruby в свое время завоевал мир бекенда. Вот к чему нужно стремиться. Создать свое первое приложение на Delphi образца начала 2000х годов тоже было очень просто. Создатели этих инструментов в эту простоту осознанно вкладывались. Так что я не могу с вашим тезисом полностью согласиться, есть инструменты, погружение в которые сильно проще чем в другие.
Оригинальная статья же создает впечатление, что сложно погружаться только в Svelte.
У меня возникло другое впечатление. Я много разных инструментов пробовал и пробую и знаю, что такое сырой продукт или продукт у которого маленькое сообщество и небольшая экосистема. Судя по статье в svelte дела обстоят именно так. Ваши комментарии вида «есть много роутеров, вы выбрали плохой, выбирайте лучше» лишь подтверждают мое мнение.
Хотя по факту выясняется, что автор просто не хочет погружаться, а хочет на шару, по бырику, стряпать проекты для заказчиков. Отсюда все проблемы со Svelte, отсюда незнание основ Vue и так далее.
Я все вижу так. Автор хотел сделать UI для админки и напрягаться как можно меньше. Встретился он с относительно новым инструментом, в котором еще не все детские проблемы решены. Автору по этому поводу стало плохо и он пошел жаловаться.
Вот вы, полагаю, человек разумный. Наверное прочитали обе статьи. Какие конкретно моменты Svelte остались непонятными после прочтения моего ответа? Или может я как-то супер сложно запаривался чтобы решить их? Остался хоть один конструктивный пункт?
ИМХО эту критику стоило бы рассмотреть не с позиции «автор ничего не понимает, щас мы ему все объясним и расскажем как читать документацию», а с позиции «автор может быть и мелет чепуху, но зерно истины в этом есть и где-то в Svelte есть проблемы». Такая позиции, мне кажется, намного более выигрышна в долгосрочной перспективе.
Поймите, я не юзер Svelte, но такие статьи не помогают мне сделать выбор в его пользу. Как раз наоборот, они меня пугают, по принципу нет дыма без огня.
Попробовали бы вы Ruby on Rails после J2EE и вам стало бы понятно, почему Ruby в свое время завоевал мир бекенда.
Сравниваете теплое с мягким. Попробуйте Svelte после Angular и ощущения будут точно такие же.
Так что я не могу с вашим тезисом полностью согласиться, есть инструменты, погружение в которые сильно проще чем в другие.
Ваше право, но большая часть людей с которыми я общался на тему Svelte отмечают наиболее низкий порог входа среди всех фреймворков. Также можете почитать для интереса Почему SvelteJS возможно лучший фреймворк для новых веб-разработчиков.
У меня возникло другое впечатление. Я много разных инструментов пробовал и пробую и знаю, что такое сырой продукт или продукт у которого маленькое сообщество и небольшая экосистема. Судя по статье в svelte дела обстоят именно так.
Опять теплое с мягким. Да и вообще можно добавить немного конкретики из статьи, чтобы можно было сделать такие выводы? Сообщество только лишь русскоязычное и только лишь в Телеграм более 1К участников — это по-вашему мало? Тогда посмотрите на сообщество Ember, для примера, хотя назвать его «сырым» язык не поворачивается.
Ваши комментарии вида «есть много роутеров, вы выбрали плохой, выбирайте лучше» лишь подтверждают мое мнение.
Не пойму, по-вашему плохо что есть много альтернативных роутеров или плохо что нет одного официального? Да и почему он должен быть, если Svelte — это чисто UI фреймворк? Имхо, когда есть выбор это скорее хорошо, чем плохо. Проблема выбора трудна, как известно, но надо этому просто учиться. В жизни пригодится, а не только во фронтенде. Да и возможность за пару минут интегрироваться любое решение тоже весьма пригождается.
Я все вижу так. Автор хотел сделать UI для админки и напрягаться как можно меньше. Встретился он с относительно новым инструментом, в котором еще не все детские проблемы решены. Автору по этому поводу стало плохо и он пошел жаловаться.
Автор не хочет напрягаться до такой степени, что даже не знает инструменты, которые якобы уже изучил. И вот вам пример:
Можно создавать свои event в компонентах и избавиться от передачи в child коллбэков функции, для коммуникации между child > parent.
Мне лично определенно понравились некоторые фишки svelte, как я писал в статье. Я бы очень хотел увидеть ивенты в Vue или чтобы через год Svelte «повзрослел».
Но ведь Custom Events это components basics во Vue. Не какой-то там advanced, а basic, понимаете? Также как и концепция «props down, events up». Мы в нашей компании разрабатываем проекты на Vue c 2015 года и сразу узнали о наличии такой фичи, потому что внимательно читали документацию и изучали best practice по конкретно этому инструменту. А тут, люди берут незнакомую штуку, не изучают потому что им неохота напрягаться и начинают за деньги пилить проекты и потом жаловаться. А мы значит должны ко всему этому относиться серьезно и кто-то со стороны, например вы, начинает к этому прислушиваться. Это нормально и профессионально по-вашему мнению?
ИМХО эту критику стоило бы рассмотреть не с позиции «автор ничего не понимает, щас мы ему все объясним и расскажем как читать документацию», а с позиции «автор может быть и мелет чепуху, но зерно истины в этом есть и где-то в Svelte есть проблемы». Такая позиции, мне кажется, намного более выигрышна в долгосрочной перспективе.
Тут могу лишь отметить, что виной тому даже не лень автора, а то что, к сожалению, фреймворка сейчас во многом копируют концепции реакта и создается впечатление что «ничто не ново под луной» и можно бездумно перелазить с одного инструмента на другой не меняя подходы и привычки, а просто выучивая новый синтаксис директив и тп.
В Svelte, при том что он тоже похож на React во многом, так просто не получается сделать, из-за особого подхода ко многим вещами. Мы тоже проходили через это, когда приходится искать новые подходы и решения, которые при этом получаются значительно элегантнее и лаконичнее. В этом и есть сила Svelte, но это и не дает некоторым взять его снаскока, просто имея на плечами React/Vue и это же двигает фронтенд на шаг вперед.
Поймите, я не юзер Svelte, но такие статьи не помогают мне сделать выбор в его пользу. Как раз наоборот, они меня пугают, по принципу нет дыма без огня.
Легко же: NH₃+HCl=NH₄Cl
Погружаться сложно в любой новый инструмент.
Не в любой, а в тот, который плохо сделан, либо имеет плохую документацию, либо имеет непривычную для изучающего концепцию.
Из моего опыта использования некоторых инструментов:
ASP.NET Web Forms — плохо сделан (долго изучать, не очень гибкий, приходится писать костыли для решении проблем, сложно находить причины багов в своем коде). Итог: умер, заменен asp.net MVC.
ASP.NET MVC — гибкий, прост в изучении. Итог: активно живет и развивается уже 10 лет.
Unity3d — очень гибкий, прост в изучении. Итог: активно живет и развивается уже почти 15 лет.
Redux — не очень гибкий, сложен в изучении. Итог: аномально популярен, но со временем стало появляться много отрицательных отзывов. Думаю, ждет та же участь, что и Angular 1.
Mobx — гибкий, средняя сложность изучения. Итог: Аномалия, что он еще не убил Redux) Тем более в Vue есть Vuex, который скорее похож на Mobx, чем на Redux.
Angular 1 — не очень гибкий, сложен в изучении, сложно находить причину багов. Итог: со временем стало появляться много отрицательных отзывов, близок к смерти.
React где-то до 15 версии — приемлемая гибкость, прост в изучении. Итог: убил Angular 1)
Нынешний же реакт стал сложен в изучении, часто скачет от одних best practices к другим. Гибкости особо тоже не прибавилось. Лично я считаю, что он не в том направлении развития пошел. Я с Vue и Svelte не работал, но по беглому взгляду на документацию, это те же яйца, только в профиль. Что-то у них хуже реализовано, что-то лучше. Но в целом недостаточно различий, не настолько одно лучше другого, чтобы менять одно на другое. Лично я жду их убийцу, более гибкий и простой фреймворк)
Всё-таки со стилями вы не совсем правы, разница есть.
Vue принимает стиль как объект, Svelte принимает его как строку. А из этого сразу же следуют три недостатка:
- никто никак не проверит синтаксис стиля на этапе компиляции;
- сложный стиль всегда будет обновляться полностью, а не точечно;
- надо следить за передаваемыми в стиль данными чтобы не допустить CSS-инъекции (XSS через CSS, вроде бы, сделать не получится — но вот следящую картинку злоумышленник добавить сможет).
На самом деле немного не так. Проверки стиля не будет, да, но сами стили компилируются с непосредственные присвоения стилям элемента:
Компилируется в:
Не все это знают, это факт. Как видите Svelte умудрился оставить валидный синтаксис style атрибута и при этом сделать обновления императивными и точечными.
<script>
let name = 'world';
let color = 'red';
let fontSize = 100;
</script>
<h1 style="color: {color}; font-size: {fontSize}px;">Hello {name}!</h1>
Компилируется в:
function set_style(node, key, value, important) {
node.style.setProperty(key, value, important ? 'important' : '');
}
...
set_style(h1, "color", color);
set_style(h1, "font-size", "" + fontSize + "px");
Не все это знают, это факт. Как видите Svelte умудрился оставить валидный синтаксис style атрибута и при этом сделать обновления императивными и точечными.
И даже в этом случае оно сработает?
$: style = ` font-size: ${fontSize}px; color: ${color}; width: ${width}px; `;
В этом случае нет, но если волнуетесь, можно не использовать: svelte.dev/repl/41a7d46d5da943b7b9cd63be1e986ada?version=3.12.1
Я лишь описал одну из возможностей.
Я лишь описал одну из возможностей.
На чем угодно можно постараться и написать плохо. А если очень постараться, то очень плохо. Я так умею!
Это да, но в данном случае "написал плохо" автор поста, на что я ему и указал.
Я не хотел «кидать камни» в вашу сторону, а просто констатирую факт, что у любой технологии есть свои ограничения, которые нужно учитывать. Это было скорее к тону оргинальной статьи)
А вообще если быть честным, то просадка в поизводительности в похожих кейсах будет заметна далеко не всегда, так что вполне такое может уехать в прод и никого не волновать.
А вообще если быть честным, то просадка в поизводительности в похожих кейсах будет заметна далеко не всегда, так что вполне такое может уехать в прод и никого не волновать.
Просто имхо, это не плохо, а один из вариантов. Часто довольно удобный.
Понимаете, просто в Svelte такие вещи пишутся за 5-10 минут и поэтому вообще не вызывают каких-то вопросов. Вот например, пример реализации работы с объектом стилей за 3 минуты через экшн:
И использование:
REPL
Понимаете, просто в Svelte такие вещи пишутся за 5-10 минут и поэтому вообще не вызывают каких-то вопросов. Вот например, пример реализации работы с объектом стилей за 3 минуты через экшн:
export default function(node, styles) {
function update(styles = {}) {
node && Object.keys(styles).forEach(key => {
node.style.getPropertyValue(key) !== styles[key] &&
node.style.setProperty(key, styles[key]);
});
}
update(styles);
return { update };
}
И использование:
<h1 use:asStyled={styles}>Hello {name}!</h1>
<script>
import asStyled from './asStyled.js';
let name = 'world';
let color = 'red';
let fontSize = 16;
let sizeUnit = 'px';
$: styles = {
'font-size': fontSize + sizeUnit,
color
};
</script>
REPL
Уже есть такая: habr.com/ru/post/420113
Правда слегка устаревшая, так как там Svelte 2, но сам принцип никак не изменился. Также можете посмотреть в сторону: github.com/pngwn/svelte-adapter
Правда слегка устаревшая, так как там Svelte 2, но сам принцип никак не изменился. Также можете посмотреть в сторону: github.com/pngwn/svelte-adapter
Например, в том же React:
class MyComponent extends React.Component { constructor(props) { super(props); this.dialog = null; this.loading = false; this.pins = []; this.stitch = null; } render() { return <dialog ref={el=> this.dialog = el} class="mdl-dialog» />; } }
В React это не будет работать. При условии, конечно, что в render будут использоваться this.loading/this.pins, и это не константы. В React Вам нужно явно прописать, какие переменные состояния будут входными (props), какие — собственные (this.state / useState), а какие — выходные (props, c типом функции, обычно начинающиеся с «on»). Просто переменной экземпляра при этом у вас может быть только что-то несвязанное с React, либо пограничное с ним – ref.
Что сразу дает некоторую конвенцию. Не везде логичную, например пока я писал этот комментарий заметил следующие:
1) В пропсах передаются и входные параметры и выходные колбеки, и вроде бы они отличаются типом данных, но есть шаблон render prop, который из общей логики выбивается — с одной стороны передаем в пропсах функцию, с другой она при этом будет входным параметром. К счастью хуки сделали render prop ненужным.
2) Все что используется в render должно быть или в props или в state, но при этом неизменяемые в течение жизни компонента колбеки обычно пишут как просто стрелочные методы экземпляра. Для более явного разделения, собственно лучше стрелочными методами делать только их. Собственно с введением хуков имхо стало по-логичнее: тип стал виден в месте определения, как и бывает у нормальных людей.
Итого. Конвенция не везде стопроцентно строгая. Зачастую многословная (до хуков особенно). Но она есть. И часто без нее компонент просто не будет работать.
В Angular всё еще строже.
В React это не будет работать. При условии, конечно, что в render будут использоваться this.loading/this.pins, и это не константы.
Нигде это условие не упоминалось, поэтому это будет работать. ))) Мы не знаем точное условие задачи. В целом, свои решения я предоставил.
К счастью хуки сделали render prop ненужным.
Недавно в одном из телеграм чатов, мне один товарищ, с пеной у рта доказывал что render props — это вообще лучшее в реакт. Гыг, я тут согласен с вами конечно.
Итого. Конвенция не везде стопроцентно строгая. Зачастую многословная (до хуков особенно). Но она есть. И часто без нее компонент просто не будет работать.
Но весь я специально привел хуки в пример. Потому что по-большому счету хуки двигают React стейт менеджмент в сторону Svelte, а не наоборот. Просто в Svelte это уже следующая ступень. React, из-за своей рантайм природы, просто не может себе этого позволить.
В Angular всё еще строже.
Тут не поспоришь, но, вот лично мне, оно так строго не надо.
Ну свойства-то ничто не мешает в рендере использовать, только следить за их изменениями придётся самому. Или можно взять mobx-react, тогда оно само следить будет.
а в React вообще нет работы со стилями из коробки
Обманываете)
<div style={{ margin: '10px' }} />
Нет, просто вы наверное не уловили контекст идущий из оригинальной статьи. Там речь про полноценные стили компонента, а не про применение классов или отдельных css правил. Во Vue и Svelte компоненты — это завершённые изолированные единицы, так называемые SFC. В React этот концепт немного недоделан из-за отсутствия работы со стилями.
Короче пока попрежнему нет желания даже пет проект пописать на Svelte. Я как-то так уже пописал на Polymer… Тоже было круто и хайпово, прям после google i/o
Почему? Мы уже два года пишем и довольны.
Вот тут хороший список граблей с веб-компонентами, а следовательно и полимером: https://habr.com/en/post/457010/
React + MobX серебренная пуля с 2015 года и по сей день
Мысль была следующая: React и даже Vue — это прежде всего UI фреймворки. Чтобы на их основе построить энтерпрайз проект, необходимо обложить их дополнительными инструментами. Ясное дело, что в экосистеме обоих фреймворков необходимые решения уже имеются, но так как они не являются непосредственной частью фреймворка, часто случаются шероховатности между версиями, да и просто в подходах. В application фреймворках, таких как Angular или Ember, все инструменты подогнаны друг под друга, сразу готовы к использованию и не требуют дополнительных манипуляций для установки и налаживания совместной работы. Хорошим примером может служить Ember Data. Боюсь столь полного и интегрированного во фреймворк решения для того же React или Vue вы не найдете.
Берешь React + MobX и всё, ты можешь с этим построить абсолютно все что хочешь и как хочешь, тут уже зависит от того, умеешь ли ты архитектуру создавать или нет, если нет, то увы, это не твоё в принципе, и максимум что тебе светит это быть обычными разрабом которому диктуют что писать и как писать. Не нравится реакт, берешь голый Vue и Vuex не нужен, нафига иммутальность когда там реактивная мутабильность из коробки, и у тебя будут локальные стейты и глобальные стейты, и всё, этого тоже достаточно чтобы построить все что угодно. И в Svelte из коробки есть абсолютно все, чтобы на нем можно было написать все что угодно. Мораль такая, это не инструменты плохие, это разработчики плохие, которые не могут и/или не знают как этими инструментами воспользоваться, чтобы сделать абсолютно все что захочешь, и если руки растут из правильного места, то в любом из этих инструментов будет красивая легко-поддерживаемая и расширяемая до бесконечности архитектура. Все упирается в целом низкий уровень разработчиков по миру, понятное дело все хотят большую зарплату и в IT идут все кому не лень, но реально работает поговорка «Программистом нужно родиться». та же связка React + MobX ещё с 2015 года позволяет писать быстро, качественно и с минимальным кол-вом кода, плюс оптимизация производительности из коробки за счет мутабельности, в отличии от Redux, где кол-во кода растет с каждой фичей на порядки и так же падает производительность из-за бесконечных перерендеров всего чего не поподя.
>> Ясное дело, что в экосистеме обоих фреймворков необходимые решения уже имеются, но так как они не являются непосредственной частью фреймворка, часто случаются шероховатности между версиями, да и просто в подходах.
В случае с Vue, большинство решений которые могут вам понадобиться(vue-resource, vue-router, vuex, vue-rx) разработаны в большей мере автором самого Vue, Эваном Ю.
В случае с Vue, большинство решений которые могут вам понадобиться(vue-resource, vue-router, vuex, vue-rx) разработаны в большей мере автором самого Vue, Эваном Ю.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
RE: Боль и слёзы в Svelte 3