Любой веб-разработчик, который занимается этим хотя бы несколько лет, наверняка день за днем слышит подобный вопрос:
Я действительно хочу стать веб-разработчиком, но я не знаю с чего начать. Есть какие-то предложения?
Лет 10 назад ответ был очень прост. Просто создайте index.html, добавьте туда несколько тегов, сделайте заголовок красным с помощью CSS и подключите JQuery для обработки кликов!
Ох, как же все изменилось. Теперь мы работаем с инструментами сборки, маршрутизацией на стороне клиента, специальными фреймворками с причудливым рантаймом, привязывая везде «this», шаблонными литералами, CSS-in-JS… как же выбрать то, что важнее всего?
Все это привело к бесчисленным вариациям того, с чего можно начать с различной степенью «просто введите это сейчас, а я объясню позже». Некоторые побуждают новичков сразу изучать React или Vue, чтобы начать работу с современными практиками. В то время как другие кричат ??с вершин гор, что новичкам всегда следует начинать с основ. По правде говоря, у обоих подходов есть свои достоинства. Первый может вызвать у новичков восторг от таких штук как hot-reloading и компоненты, рискуя оставить слишком многое в стороне. В то время как второй заставляет новичков понять, как DOM работает под капотом, в то же время, возможно, отвлекая людей сложностью ванильного JS, от которой мы давно абстрагировались.
Вот почему нам нужна золотая середина. Способ начать работу с основами, в то же время впитывая в себя современные концепции, такие как разработка на основе компонентов, изолированный vs каскадный CSS, шаблоны, декларативные функции и т.д. и т.п.
Svelte, к вашим услугам
SvelteJS — довольно новый патрон в обойме js фреймворков, который только начинает привлекать к себе внимание. Кто-то может знать его после публикации State of JavaScript 2018. Если кратко, Svelte призван быть фреймворком, который на самом деле не является фреймворком. В его основе лежит инструмент для компиляции компонентов на этапе сборки, позволяющий загрузить на страницу лишь необходимое для отображения вашего приложения. Это означает, что нет виртуального DOM, нет фреймворков поверх фреймворков и нет фреймворка в рантайме.
Все это довольно серьезные аргументы для более опытных разработчиков, но большинство новичков, вероятно, не смогли прочитать последний абзац без отрыва башки. К счастью, не волшебство компиляции делает Svelte настолько дружелюбным к новичкам, а его синтаксис.
Если вы никогда не видели компонент Svelte, вот простой пример:
<p class="pretty">Here's some markup <strong>written by {name}!</strong></p>
<style>
/* здесь изолированный CSS */
.pretty {
color: red;
}
</style>
<script>
/* ...и переменные к которым есть доступ из разметки */
let name = "Ben";
</script>
Давайте разберемся в этом. Итак, во-первых, стоит отметить, что все это можно писать хоть в обычном .html файле, хоть в .svelte файле, если вашей душе угодно. Также мы видим некоторые знакомые теги, напоминающие разработку без фреймворка: style и script. Стили и JS код пишутся в этих тегах для правильного построения компонентов. Кроме того, это позволяет подсветке синтаксиса работать без дополнительных плагинов для редактора, таких как решения для CSS-in-JS. Кроме того, компилятор Svelte достаточно умен, чтобы по-умолчанию изолировать любые специфичные для компонента стили. Поэтому у вас не будет стилей протекающих между компонентами.
Вы также видите как что-то магическое происходит с JavaScript переменной name. Это блестящая новая концепция для Svelte 3, где любая переменная в скрипте вашего компонента доступна из разметки. У нас нет специального синтаксиса, который нужно изучать для управления состоянием. Нет ни Angular $scope, ни React this.state, ни data из Vue. Вместо этого, мы можем просто использовать обычные переменные для описания состояния, вызывая повторный рендеринг всякий раз, когда их значения изменяются.
Эта свобода от этого синтаксического «жаргона» означает, что создание компонента начинает походить на создание CodePen, только без необходимости задумываться о том, как подключить декларативную функцию JS к какому-то DOM селектору.
Еще одна приятная вещь заключается в том, что компоненты Svelte импортируются также легко, как и традиционные компоненты. Вы можете просто импортировать .html, так как Svelte знает как его развернуть:
<div>
<Wizardry />
</div>
<script>
import Wizardry from './wizardry.html';
</script>
Круто, но погодите минутку...
Некоторые читатели могут посчитать эту концепцию настолько же умопомрачительной, как и я. В то же время, другие, вероятно, имеют свои доводы против использования подобного подхода для обучения начинающих. Разве им не интересно как на самом деле работают манипуляции с DOM?
Ответ… возможно. Но когда кто-то только начинает (по крайней мере, из личного опыта), можно принять небольшую абстракцию ради более быстрого создания классных вещей.
Кроме того, так же как некоторые языки, например, Java и JS, абстрагировали управление указателями с помощью сборки мусора, большинство современных инструментов веб-разработки абстрагировались от манипуляций с DOM. За исключением более сложных крайних случаев, которые новичкам, вероятно, не понадобятся. Кстати, если вы ломаете голову над тем, что такое управление указателями, я думаю, что это лишь доказывает мою точку зрения. Таким образом, вместо того, чтобы заставлять новичков манипулировать DOM или осваивать специфичные для фреймворка способы управления состоянием, почему бы просто не позволить им обращаться к переменным напрямую из разметки? Теперь они могут изучать основные принципы управления состоянием компонентов не впадая в траур.
Хорошо, я вижу базовый пример, но у Svelte должны быть какие-то специфические особенности, чтобы все это работало
Без сомнения, это правда, но этого намного меньше, чем вы думаете. Одна часть синтаксиса Svelte предназначена для итеративного и условного отображения элементов DOM. Это работает очень похоже на map из JSX, но без всех этих вложенных скобок, в которых новички (и я) могут легко потеряться. Вот базовый способ, который генерирует список элементов из массива:
<ul>
{#each profiles as profile}
<li>{profile.name}: {profile.role}</li>
{/each}
</ul>
<script>
const profiles = [
{name: 'Wes Bos', role: 'React extraordinaire'},
{name: 'Chris Coyier', role: 'Father of CodePen'},
{name: 'Cassidy Williams', role: 'Letting you know it's pi time'}
];
</script>
Опять же, я понимаю любую критику в отношении синтаксиса, но мне нравится то, насколько легко понять это. Вместо того, чтобы вкладывать JavaScript в наш HTML-код, мы просто говорим: эй, давайте сделаем цикл по этому массиву и создадим элемент для каждого из них.
Стоит упомянуть еще одну особенность Svelte, от которой я нахожусь не в таком восторге: синтаксис передачи пропсов компонентам. Да, он полностью функционален и прост в освоении, но, в тоже время, может показаться слишком магическим на вкус некоторых людей. Для обработки пропсов мы просто передаем их компоненту, куда бы он ни импортировался…
<!-- somewhere.html -->
<Profile coolGuy="Scott Tolinski" />
… и получаем эту переменную как экспортированный «let»:
<!-- profile.html -->
<p>{coolGuy}</p>
<script>
export let coolGuy = '';
</script>
Я полностью понимаю, что некоторым это покажется злоупотреблением «экспортом». Но по крайней мере, это соответствует тому, как начинающие должны концептуализировать модули: мы экспортируем то, к чему должны получить доступ за пределами компонента, и импортируем то, что хотим использовать в нашем компоненте.
Я мог бы преодолеть эту странность… но как насчет обязательного шага сборки?
Итак, еще одна критика по поводу начала работы с фреймворками — это необходимость использовать менеджер пакетов. Что означает… черт, использовать терминал!
Послушайте, я понимаю, что открывать эту штуку может быть крайне пугающим, с ее моно-шрифтом и жутким «cd» для перехода по каталогам. Но, честно говоря, это действительно не большое препятствие, когда вам нужна только одна команда для запуска. Кроме того, встроенный терминал в VS Code упрощает начало работы. Он даже открывается в нижней части окна прямо в вашем каталоге проекта!
На самом деле Svelte предлагает скачиваемый стартер, но я создал свой собственный стартовый шаблон, который просто использует Rollup для прямой загрузки. На самом деле, файл конфигурации длиной менее 30 строк! Для базового проекта Svelte это все каталоги и файлы, которые вам нужны:
/public
index.html
/src
index.html
app.js
rollup.config.js
package.json
Просто добавьте команду для запуска шага сборки в package.json, и все готово! Можно, конечно, сказать, что все дополнительные модули и файлы, которые нужны другим фреймворкам, не являются проблемой, если новичок их не трогает, но, на мой взгляд, чем меньше дополнительных вещей, тем лучше для новичков.
Ок, хорошо, это круто и удобно для начинающих. Но насколько это стабильный фреймворк?
Это очень актуальный вопрос для такого молодого фреймворка, как Svelte. Все примеры, которые я показал, используют синтаксис Svelte версии 3, которая на момент написания этой статьи все еще находится в бете. Как бы это ни было захватывающе, я бы подождал еще несколько месяцев, прежде чем спешить с ним на семинары по программированию. Тем не менее, Svelte предлагает действительно лаконичную страницу документации для версии 3, которая может облегчить начинающим работу.
Итак, давайте рассмотрим некоторые основные преимущества для изучения веб-разработки со Svelte:
- Это компонентный фреймворк с 0 дополнительными плагинами
- Он управляет состоянием без всякого обычного хлама
- Использует изоляцию стилей без использования CSS-in-JS (поэтому не нужны плагины для редактора или дурацкий синтаксис)
- Чтобы начать работу нужен лишь очень простой скрипт сборки
- В базовом проекте практически нет никаких дополнительных файлов
Конечно, это совершенно нормально, если мне не удалось убедить вас в этой статье. Все хорошие статьи разжигали небольшую полемику! Но я надеюсь, что эта статья, по крайней мере, показала вам, насколько чертовски крутым и простым Svelte может быть для изучения.
Спасибо что прочли это!
Я — фронтенд веб-разработчик-в-процессе-обучения, всегда возящийся с чем-то новым. Я постараюсь регулярно публиковаться здесь, так что напишите, если вам понравилось!
***
От переводчика:
Спасибо что почитали данный перевод! Надеюсь эта статья сподвигнет вас посмотреть в сторону Svelte в качестве инструмента для обучения или даже нового проекта.
Приходите на мой 2-х часовой воркшоп по Svelte 3 на HolyJS Piter 24-25 мая. Кто хочет просто следить за развитием Svelte — welcome в русскоязычный телеграм канал SvelteJS. Будем рады вам!
И небольшой опрос, без привязки к фреймворку и технологии. Просто интересно ваше мнение.
Комментарии (129)
stardust_kid
30.03.2019 15:41Начинающему (и не только) разработчику нужно изучать фреймворки, которые востребованы рынком, и в которых применяются технологии стандартные для индустрии. Unidirectional data flow, реактивность, иммутабельность и т. д. А все эти статьи, типа посмотрите какой забавный кунтшюк выделывает эта либа, вызывают недоумение. Ну потратит человек сотню часов на изучение, а какой выхлоп в конце? Хз.
PaulMaly Автор
30.03.2019 19:54+2Когда-то рынком были восстребованы BackboneJS, AngularJS и ExtJS. Как думаете, те кто в 2013 году стали изучать React сильно пожалели об этом?
shm-vadim
30.03.2019 20:03+1Ну, «реактами» в итоге стали очень немногие, по пальцам одной руки пересчитать можно. А сколько умерло по дороге… Так что теория вероятности, наверное, все же не на вашей стороне. :)
PaulMaly Автор
30.03.2019 20:12-1Думаю вероятность тут как всегда 50x50. Может станет, может нет. Время покажет.
stardust_kid
31.03.2019 13:36Стал изучать реакт потому, что мы решили на нем виджеты для сайтов клиентов в 2013. Angular тяжелый для этого был, и не понятно как прикручивать. Не жалею.
DarthVictor
03.04.2019 11:49Как думаете, те кто в 2013 году стали изучать React сильно пожалели об этом?
Если это были джуны, которые в итоге не смогли найти работу на React в 2013, то предполагаю, что да, пожалели.
rumkin
30.03.2019 22:21Разработчику необходимо изучать лучшие практики. То, что сегодня востребовано рынком, завтра умрет.
Плюс поставил за кунштюк.
megahertz
30.03.2019 16:21+1У стороннего от разработки человека может сложиться ощущение что Vanilla JS это какой-то Rocket science, чуть легче чем удаленно перепрограммирование марсохода. На самом деле текущий DOM API и его поддержка браузерами находятся на таком хорошем уровне, что можно обезьяну научить за неделю писать простенькие скрипты, которые способны решать большинство типичных задач. Уже не надо помнить конструкции вроде
или.main { display: inline-block; *display: inline; zoom: 1; }
if (!window.addEventListener) { ... }
Сегодня это все стало гораздо проще. Сложновато разве что найти достойное актуальное руководство для начинающего среди огромного многообразия. Зато полученные знания не превратятся в тыкву через пол года.
Существует еще одна проблема для новичка, решившего сразу начать с фреймворков. Современные фреймворки в основном используют декларативный подход. Это сильно затрудняет переход от HelloWorld к решениям реальных задач. Императивный подход проще для новичка за счет отсутствия внутренней магии.JustDont
30.03.2019 19:31+1Современные фреймворки в основном используют декларативный подход.
Я бы так сильно не утверждал. Ни реакт, ни ангуляр, ни вью — какой-то особой декларативщиной не страдают. Ей часто страдают авторы примеров и всяких тудушек — «Ой, нам надо параметры передать? Ну давайте навернём сверху компонент!»; «Ой, нам надо куда-то логику приложения положить? Давайте положим её в компонент и прибьем гвоздями к хукам жизненного цикла!». В то время как сам фреймворк ничего этого не диктует, и выносить логику из компонентов везде можно без особого труда. MVC в общем-то не зря придумали, и зацикленность людей на V — это не от большого ума или опыта.
Ну а декларативность в той мере, чтоб какая-то шаблонизация была и тому подобное — это неизбежность, потому что голый императивный код очень быстро перестаёт масштабироваться и поддерживаться. Знать, как там руками подёргать DOM — для общего развития пригодится, но вот именно в реальных задачах — скорее всего нет.
AlexxNB
30.03.2019 19:38+2С Vanilla всё хорошо, пока это действительно задачки для новичка. Как только она начинает перерастать во что-то покрупнее, уже начинается неразбериха в коде и прочие трудности. В этом месте разарботчик либо пишет свой фреймворк, либо выбирает из существующих. Нужно рассматривать фреймворк не как набор всевозможных функций, а как средство для структурирования разработки и мыслей, которое существенно облегчит создание большого проекта, особенно, если разработчик не один, а целая команда.
В таком контексте, Svelte — это просто средство для написания ванильного Javascript, но в хорошо структурированном виде.
А так, конечно, соглашусь, что начинать обучение всё-таки стоит с основ. Я жене в декрете купил книжку «JavaScript для детей» — когда освоит, покажу как применить свои начальные знания в Svelte.
vintage
30.03.2019 18:29+3Как у этого «лучшего на свете нефреймворка» обстоят дела с тайпскриптом?
PaulMaly Автор
30.03.2019 19:31+1Я правильно понял, раз это единственный ваш вопрос в контексте статьи, вы считаете эта самым важным для новичков?
serf
30.03.2019 19:36+1А вы считаете этот «магически исчезающий фреймворк» пригодным только в роли букваря для новичков?
PS оно вроде как на TS напиисано github.com/sveltejs/svelte/tree/master/src но только частично (например каталоги internal и motion на JS). Надеюсь JS со временем ичезнет из проекта совсем. Кроме этого github.com/sveltejs/svelte/blob/master/tsconfig.json меня не слишком впечатлил. Но автор вроде как принимает идеи TS и можно ожидать что дела наладятся github.com/sveltejs/svelte/issues/1639#issuecomment-442974572PaulMaly Автор
30.03.2019 19:44А вы считаете нормальным, что уже нельзя написать статью про javascript без обязательного вопроса о typescript в комментариях, даже если эта статья для новичков?
Если бы всем поголовно во фронтенд сообществе нужны были бы статические типы, они давно бы уже стали частью стандарта. Раз этого не происходит, значит нужны они далеко не всем. А если бы я хотел написать/перевести статью про typescript, я бы отметил ее соответствующим тегом.
typescript !== javascript и давайте закончим на этом.serf
30.03.2019 20:04Если бы всем поголовно во фронтенд сообществе нужны были бы статические типы, они давно бы уже стали частью стандарта.
Стандартизирование типизации в JS на данное время не иммет смысла потому что там постоянно нужно что-то допиливать, развивать и улучшать так как нельзя просто так взять и сразу типизировать всю мощь javascript. Посмотрите для примера как активно развивается typescript.PaulMaly Автор
30.03.2019 20:14А мне почему-то кажется, что Javascript — это язык с динамической слабой неявной типизацией и ровно таким он и останется. Вот и все. Если вы не заметили, то все что добавляется в стандарт — это лишь «сахар» и свистелки для удобства.
impwx
30.03.2019 21:30Если бы всем поголовно во фронтенд сообществе нужны были бы статические типы, они давно бы уже стали частью стандарта.
Далеко не все принимают решение об использовании строгой типизации или отказе от нее на основе фактов и логики. Очень часто это просто предрассудки из серии «типы замедляют разработку», «типы — это сложно», «типы мешают мне самовыражаться в коде» и прочее. Так что их внедрение не происходит по другим причинам: даже если 90% за, оставшиеся 10% могут орать так громко, что инициатива пойдет ко дну.PaulMaly Автор
30.03.2019 21:57Далеко не все принимают решение об использовании строгой типизации или отказе от нее на основе фактов и логики.
Полностью согласен. Я например, начинал с разработки под C++, так что довольно неплохо представляю себе, что такое типы, работа с указателями и ООП на классах. При этом я совершенно не считаю, что статическая типизация на фронтенде нужна настолько, чтобы со всех статьях про Javascript начинать обсуждать Typescript. А те кто считают, часто имеют бекграунд где-то в районе Java/C#, так чему тогда удивляться?
Очень часто это просто предрассудки из серии «типы замедляют разработку», «типы — это сложно», «типы мешают мне самовыражаться в коде» и прочее.
Именно так я и думаю. Большинство тех, кто сейчас внедряет TS не до конца понимают зачем это нужно именно их проекту. Просто «на хабре пишут что без ts фронтенд будет глючить» вот наиболее частый довод. А дальше мы получаем доклады от Яндекса типа этого.vintage
30.03.2019 23:07+1Я например, начинал с разработки под C++, так что довольно неплохо представляю себе, что такое типы, работа с указателями и ООП на классах.
Боюсь опыт работы с языком тридцатилетней давности не может давать вам представление о работе с современными статически типизированными языками.
А те кто считают, часто имеют бекграунд где-то в районе Java/C#, так чему тогда удивляться?
Те, кто считают, имеют опыт разработки и поддержки больших проектов, не помещающихся в одну голову целиком.
PaulMaly Автор
30.03.2019 23:22Боюсь опыт работы с языком тридцатилетней давности не может давать вам представление о работе с современными статически типизированными языками.
А вы не бойтесь, последняя версия стандарта вышла в 17-м году. Но вообще да, наверное лет 10 назад с ним и работал в послединий раз. Расскажете, что такого я упустил за это время, что заставит меня поменять свою точку зрения на статическую типизацию во фронтенде?
Те, кто считают, имеют опыт разработки и поддержки больших проектов, не помещающихся в одну голову целиком.
То есть по-вашему это как-то зависит от языка? Вообще, я заметил что такие люди часто ходят «в чужой монастырь со своим уставом». Хорошо ли это для фронтенда? Не думаю.vintage
30.03.2019 23:54А вы не бойтесь, последняя версия стандарта вышла в 17-м году.
Основа его дизайна с тех пор почти не поменялась. Даже препроцессор до сих пор не выпилили.
Расскажете, что такого я упустил за это время, что заставит меня поменять свою точку зрения на статическую типизацию во фронтенде?
Видимо вы пропустили рассвет и закат JsDoc. Это когда описание типов занимало в 2 раза больше строк, чем собственно код, чтобы IDE хоть что-то понимала в том, что нафигачил программист.
То есть по-вашему это как-то зависит от языка?
Слышали про гипотезу Сепира-Уорфа?
Вообще, я заметил что такие люди часто ходят «в чужой монастырь со своим уставом». Хорошо ли это для фронтенда?
Я как бы больше 10 лет во фронтенде. Уж наверно я в своём монастыре. Но это не точно.
PaulMaly Автор
31.03.2019 00:12Видимо вы пропустили рассвет и закат JsDoc. Это когда описание типов занимало в 2 раза больше строк, чем собственно код, чтобы IDE хоть что-то понимала в том, что нафигачил программист.
А как это связано со статической типизацией в языках со статической типизацией? Кроме того, JsDoc вполне себе и сейчас работает и используется совместно с ts-check.
Слышали про гипотезу Сепира-Уорфа?
Слышал про то, что когда есть что сказать и аргументировать, люди так и делают. Могу интерпритировать ваш пример так: именно то, что некоторые языки (фреймворки/что угодно) написаны сложно и концепции лежащие в их основе сложны, они фомируют у людей соответствующее восприятие, фактически заставляя решать простые задачи сложными способами.
Я как бы больше 10 лет во фронтенде. Уж наверно я в своём монастыре. Но это не точно.
Это точно, что не точно. Особенно, учитывая насколько популярны ваши решения во фронтенде. Вы там свой «геморрой» то вылежили? Не похоже что-то.vintage
31.03.2019 00:55Это связано со статической типизацией в динамически типизированном языке. Что лишний раз показывает, что без неё никак.
Скорее о том, что разруха в языке порождает разруху в головах.
Ага, давайте измерять качество решения популярностью.PaulMaly Автор
31.03.2019 11:12Это связано со статической типизацией в динамически типизированном языке.
Стоп, вы мне писали что мои знания насчет статической типизации для статически типизированного языка устарели. Напомню, я писал про C++. Что мол сейчас то статическая типизация ого-го и я сразу захочу ее иметь на фронтенде. Ну и? Что такого супер нового мне дает Typescript по сравнению с C++ в плане типизации?
Что лишний раз показывает, что без неё никак.
Нет, это лишь показывает, что крутить статическую типизацию к динамически типизированному языку может быть больно. Нашли чем удивить. Но я и говорю ровно об этом, не нужна она для абсолютного большинства фронтенд проектов. Для энтерпрайзов, да пожалуй. Там выгоднее всего сейчас Angular смотрится. Но далеко не все пишут энтерпрайзы.
Скорее о том, что разруха в языке порождает разруху в головах.
Это работает в обе стороны. И видно даже на вашем примере.
Ага, давайте измерять качество решения популярностью.
А мы ничего не говорили про качество. Лишь про то, насколько вы человек из фронтенда. Сложно считать себя собакой среди собак, если ты мяукаешь, а все вокруг гавкают.
babylon
31.03.2019 12:51Лучший пример, что без статической типизации никак это ручной проброс контекстов
impwx
31.03.2019 13:38+1Что такого супер нового мне дает Typescript по сравнению с C++ в плане типизации?
Воу-воу, вы серьезно?
- Структурная типизация против номинальной
- Частичная типизация
- Типы-пересечения и типы-объединения (алгебра типов)
- Типы-отображения
- Условные типы
- Тип this
- Вывод типов на основе анализа потока управления
PaulMaly Автор
31.03.2019 14:22Вижу вы очень старались, но увы не получилось. Практически все из перечисленного либо есть в C++, либо просто решается по-другому, либо полная ересь в контексте языка.
Зачем все это на фронтенде, кроме разве что очень крупных проектов, все еще не ясно.
Еще раз предлагаю вам посмотреть доклад: Цена типизации. По-моему, там довольно доступно рассказано, когда все это действительно нужно, а когда является лишь лишним усложнением.vintage
31.03.2019 14:50Вкратце для тех, кому лень смотреть сорокаминутное видео…
Чел пол часа с пеной у рта разглагольствует о том, что статическая типизация не нужна. А потом, без тени взаимоисключающих параграфов на лице, предлагает использовать ts-check (то есть статическую проверку типов) полагая, что этот ts-check найдёт все ошибки (афайк не найдёт и половины из-за вылезающего тут и там неконтролируемого any). А под конец предложил вообще писать тайпинги для своего JS кода в отдельных d.ts файлах.PaulMaly Автор
31.03.2019 15:25Вкратце для тех, кому лень читать ваш длинный комментарий…
Вы как всегда самый умный и все понимаете. Все вокруг дураки, ниче не шарящие и непонятно как вообще их в Яндекс взяли.
В целом все тоже самое, что мы читаем во всех ваших комментах. Единственное что мне до сих пор не понятно, а где же ваши искрометные выступления?vintage
31.03.2019 16:14Мои выступления тут: https://www.youtube.com/playlist?list=PLXyFFhv8ucKSC96WOd7Ju2HmEWTA3jPa5
AndreasCag
31.03.2019 22:34Пытались взять на слабо, но не получилось :D
Про объектное реактивное программирование понравилось
PaulMaly Автор
02.04.2019 23:07Мои выступления тут: www.youtube.com/playlist?list=PLXyFFhv8ucKSC96WOd7Ju2HmEWTA3jPa5
Кстати, не смотря на нашу полемику, мне понравились видео. Спасибо, много правильных идей.
impwx
31.03.2019 17:53Практически все из перечисленного либо есть в C++
Ссылки на документацию или аргументы почему это не нужно, пожалуйста, или слив засчитан.
Зачем все это на фронтенде… все еще не ясно.
Просто выразительная система типов: «А или B», «и A и B», «как A, только с промисами». Никакого рокет-сайенса.
KanuTaH
31.03.2019 19:10Ссылки на документацию или аргументы почему это не нужно, пожалуйста, или слив засчитан.
Ну я попробую. Хотя я и редко пользуюсь ВСЕЙ мощью шаблонной магии C++, поэтому могу что-то не сообразить сходу, но, может, кто-то дополнит и углубит.
1. Структурная типизация против номинальной
Что-нибудь типа такого:
template<typename Iter, typename Val> requires Input_iterator<Iter> && Equality_comparable<Value_type<Iter>, Val>
? То есть привязка не к имени типа, а к каким-то его свойствам.
2. Частичная типизация
Что-то типа std::any?
3. Типы-пересечения и типы-объединения (алгебра типов)
Множественное наследование и std::variant?
4. Типы-отображения
Сходу не могу придумать, аналог, да. С другой стороны, «A common task is to take an existing type and make each of its properties optional», серьезно? Common task? Не лучше построить нормальную иерархию наследования? :)
5. Условные типы
std::enable_if? Причем он не ограничен отношением extends, но и в него могет, через std::is_base_of или std::is_convertible.
6. Тип this
Не очень понял, в чем прикол в контексте C++. Возврат this? Эка невидаль. Видимо, тут ноги растут из «странностей» JS в отношении поведения this в функциях, но в C++ такие проблемы в принципе отсутствуют.
7. Вывод типов на основе анализа потока управления
Тот же std::enable_if или концепты (из первого примера, с requires) плюс перегрузки в случаях, подобных требованию «pet is Fish» к аргументам функции из примера по ссылке? Плюс typeid и dynamic_cast (в случае, если мы имеем дело с иерархией) для примеров ниже с typeof/instanceof?impwx
31.03.2019 21:18+2Во, отлично, наконец-то разговор перешел в область фактов и обоснованных утверждений!
1. Структурная типизация подразумевает, что объект удовлетворяет интерфейсу, если у него есть все необходимые свойства. При этом на момент объявления класса объекта этот интерфейс указывать не надо. Я не знаю С++ настолько, чтобы понять ваш пример, но подозреваю, что с ним есть несколько проблем: он очень вербозный, он наверняка дает непонятные сообщения об ошибках, и без наличия в языке object literals он в целом не так полезен.
2. Если я правильно понимаю, тоstd::any— это что-то типаvoid *, т.е. перед использованием значения вам нужно все-таки привести его к конкретному типу? Если так, то нет.Anyв TS больше похоже наdynamicв шарпе. Просто вызываете методы и обращаетесь к полям, как будто вы пишете на голом джиесе и типизации не существует, а оно либо работает, либо падает в рантайме.
3. Множественное наследование с состоянием чревато известной проблемой ромба, объединение типов такое не дает.std::variant, насколько я понимаю, позволяет хранить одно значение из возможного списка, но это не то же самое, что пересечение: оно требует реализации нескольких интерфейсов одновременно. Например, можно сделать функцию, которая будет объединять два объекта в один, и тип результата будет строго выведен.
4. Это common task, потому что TS призван помочь обуздать хаос в существующем коде на JS, а там и функциональщина, и прототипное наследование, и манки-патчинг…
6. Это когда вы в базовом классе объявляете метод, который возвращаетthis, и при вызове его на объектах-наследниках возвращаемый тип не будет сбрасываться до базового. В плюсах это можно сделать костылем типа CRTP, а в TS поддерживается более элегантно.
В целом я верю, что на плюсах можно очень многое наворотить. Все-таки, шаблоны — это отдельный тюринг-полный язык. Но есть два значимых момента. Во-первых, плюсы изначально язык со статической типизацией и многие вещи принято изначально решать иначе. TS же наводит порядок в существующем коде на джиесе, и, судя по популярности, делает это довольно успешно. Во-вторых, стоит поставить рядом аналогичные куски кода на С++ c шаблонами\препроцессором и на TS, а также сообщения об ошибках, и многие вопросы сразу отпадут сами собой.KanuTaH
31.03.2019 21:37но подозреваю, что с ним есть несколько проблем: он очень вербозный, он наверняка дает непонятные сообщения об ошибках, и без наличия в языке object literals он в целом не так полезен
Вербозность — это вопрос вкуса. Зато гибко.
Если я правильно понимаю, то std::any — это что-то типа void *, т.е. перед использованием значения вам нужно все-таки привести его к конкретному типу?
Переменная типа std::any может хранить внутри себя вообще любой тип, а также быть пустой. Для вызова чего-то конкретного из того, что она хранит в данный момент, нужно проверить, что она не пуста, через вызов has_value(), а затем привести ее к нужному типу через any_cast, типа такого:
std::any a = 1; if (a.has_value()) { std::cout << std::any_cast<int>(a); }
Можно еще получить инфу о типе хранимого значения через метод type(), типа a.type().name(), например. Это все работает в рантайме. В compile time есть auto, который можно использовать, если компилятор может вывести тип, с auto все проще, никакие касты не нужны, можно написать просто:
std::string f() { [...] } auto s = f(); cout << s.length();
без всяких лишних кастов.
Множественное наследование с состоянием чревато известной проблемой ромба
Это решается через виртуальное наследование:
class A { [...] } class B : public virtual A { [...] } class C : public virtual A { [...] } class D : public virtual B, public virtual C { [...] }
но это не то же самое, что пересечение: оно требует реализации нескольких интерфейсов одновременно. Например, можно сделать функцию, которая будет объединять два объекта в один, и тип результата будет строго выведен
Несколько интерфейсов одновременно — это и есть множественное наследование. std::variant — это когда на данном месте может быть ЛЮБОЙ ИЗ каких-то типов, то есть это «или», а множественное наследование — это «и».impwx
31.03.2019 22:01Зато гибко.
Спорный момент. Я предпочту систему, которая позволяет хорошо решать частые проблемы и плохо редкие, чем любые — средне.
std::any может хранить внутри себя вообще любой тип
Это я понял, но это не то же самое, чтоany. Считайте, чтоany— это запасной план на экстренный случай, когда вы говорите компилятору «не лезь, я беру ответственность на себя, этот код точно будет работать» — и он ничего не проверяет. По поводуauto— это вообще локальный вывод типов. В TS он работает при объявлении любой переменной по умолчанию, хотя можно указать и явно :)
Это решается через виртуальное наследование
Понял, принимается, но опять же — вербозно. Вам нужно описывать все эти типы самостоятельно, и вы не можете написать функцию, которая создаст новый тип из существующих. Максимум вы можете подставить или вытащить тип из шаблона. TS же позволяет делать нечто вроде зависимых типов, хотя и очень ограниченное по меркам языков с настоящими ЗТ (типа Idris).
sergeysy
02.04.2019 23:05+1плюсы сейчас и 30 лет назад это совершенно разные языки. а вообще за последний год много на чем разрабатывал и заметил одну тенденцию: языки со статической типизацией берут вещи из языков с динамической типизацией, и наоборот
impwx
30.03.2019 23:37+1При этом я совершенно не считаю, что статическая типизация на фронтенде нужна настолько, чтобы со всех статьях про Javascript начинать обсуждать Typescript.
Вы не считаете — и поэтому остальные не должны это обсуждать? Серьезно?
Статическая типизация улучшает поддерживаемость и облегчает рефакторинг для любого мало-мальски серьезного проекта, и в TS она реализована совсем не так сковывающе, как в C++ — особенно если вы имели в виду более старые стандарты. Возможно, вам стоит освежить знания?
Большинство тех, кто сейчас внедряет TS не до конца понимают зачем это нужно именно их проекту.
Даже если TS им не зайдет — так у них хотя бы будет опыт в обоих подходах, с которым потом можно будет обоснованно решать, какой выбрать.PaulMaly Автор
31.03.2019 00:21-2Вы не считаете — и поэтому остальные не должны это обсуждать? Серьезно?
Нет, просто если статья про один язык программирования, то я упорно не понимаю, почему любители другого языка считают что нужно обязательно зайти на огонек и поучить всех жить. Еще раз — если бы я хотел написать про Typescript, я бы так и сделал.
Статическая типизация улучшает поддерживаемость и облегчает рефакторинг для любого мало-мальски серьезного проекта
Вы где-то это прочитали, да?
Возможно, вам стоит освежить знания?
А с чего вы взяли, что я не писал на TS? Ну ей богу, смешно как-то рассуждаете.
Даже если TS им не зайдет — так у них хотя бы будет опыт в обоих подходах, с которым потом можно будет обоснованно решать, какой выбрать.
Не дешевый такой опыт, которые при этом часто никак не обоснован. Если бы речь шла о JsDoc или Flow, когда «попробовать» не значит переписать весь проект на новом языке, я бы еще понял.
Еще раз, давайте договоримся: Typescript !== Javascript !== Dart !== Clojurescript
Статья про Javascript.rumkin
31.03.2019 02:54Svelte тоже не чистый JS, если уж на то пошло. Так что не стоит включать борца за чистоту крови.
И раз уж зашло обсуждение TS, то до появления CoffeeScript, JS активно стагнировал без свежих идей. CS заставил комитет подсуетиться и начать какие-то телодвижения. Это привело к реальным изменениям в языке, иногда более продуманным, чем в источнике.
Если вы посмотрите, то сегодня в комитете началась гонка идей. Так например вместо того, чтобы решить проблему с кривым механизмом формирования ошибок и единым форматом трейса, комитет двигает скрытие кода функции от вывода через toString (я серьезно). Последняя фича уже добралась до Stage 2, а обработка ошибок за два года не смогла выйти из Stage 1.
Я это к тому, что TS – это важная веха в развитии JS и, он сегодня делает для JS, возможно, даже больше, чем разработчики JS. О его значимости говорит количество проектов, которое однажды перерастет в качество. А самое главное, делает он это, чтобы однажды умереть, оставив после себя след в самом JS.
И да, мне не нравится порождаемая им фрагментация, как и хайп вокруг чего бы то ни было (кроме WASM, кончено). Но лучше экспериментировать в отдельной ветке, а не в мастере, как JS.
PaulMaly Автор
31.03.2019 12:58Svelte тоже не чистый JS, если уж на то пошло. Так что не стоит включать борца за чистоту крови.
А вы проверьте JS код Svelte компонента и компонента написанного на TS через JS валидатор и посмотрите. Сам по себе синтаксис внутри компонента Svelte — это вполне валидный ES6+. Никакие дополнительные, неустановленные языком конструкции не используются. Поэтому с точки зрения самого синтаксиса — это чистый JS. То есть чтобы начать писать код, не нужно знать никаких иных вещей, кроме JS (в отличии от TS).
Другое дело, что после компиляции он обрастает дополнительным функционалом, но это уже особенность фреймворка. Но даже после компиляции, мы можете совершенно свободно открыть итоговый компонент и прочитать его как есть, без проблем, потому что внутри все тот же ванильный хорошо читаемый JS.
Так что тут я не согласен. Svelte не привносит ничего нового в синтаксис, просто дополняет его новыми возможностями о которых мы всегда мечтали.
Я это к тому, что TS – это важная веха в развитии JS и, он сегодня делает для JS, возможно, даже больше, чем разработчики JS.
Послушайте, я ведь совершенно не имею ничего против TS как такового. У нас даже были проекты на нем. Для некоторых видов проектов, например, энтерпрайзов без него писать реально было бы сложнее.
Я лишь против того, чтобы любая статья про Javascript превращалась в срачь про Typescript и необходимость статической типизации для 100% проектов. Все это не так.rumkin
31.03.2019 20:36Так что тут я не согласен. Svelte не привносит ничего нового в синтаксис, просто дополняет его новыми возможностями о которых мы всегда мечтали.
Вы об одном мечтаете, мы о другом. Мне бы хотелось, чтобы JS вообще транспилирвоать не приходилось. Svelte не чистый JS, хоть и в меньшей степени его видоизменяет, но транспиляции все равно требует. Особой разницы я не вижу, можно спорить о степени, но это бессмысленно.
Я лишь против того, чтобы любая статья про Javascript превращалась в срачь про Typescript...
Обращаю ваше внимание на то, что срач устроили именно вы. На вопрос закрытого типа про поддержку TS, можно было ответить односложно.
PaulMaly Автор
02.04.2019 15:16Вы об одном мечтаете, мы о другом.
То есть вы никогда не мечтали о нативной реактивности? Или вот когда меняешь переменную и если в DOM есть зависимые ноды, они тоже обновляются, сохраняя 100% консистентность, не? Если не мечтали, тогда пожалуй да.
Мне бы хотелось, чтобы JS вообще транспилирвоать не приходилось.
Можете не транспилировать. После компиляции вы получаете чистый ES6. Если вам не нужны браузеры без ES6, тогда зачем вам транспиляция? Более того, ни babel ни buble в стартер-шаблоне Svelte нет.
Обращаю ваше внимание на то, что срач устроили именно вы. На вопрос закрытого типа про поддержку TS, можно было ответить односложно.
Это не так. Я лишь удивился тому, что в статье для новичков единственный вопрос это TS. Хотя TS кстати, по секрету вам скажу, поддерживается примерно также как в том же Angular, только без прямой привязки на него. То есть в скриптах можно завести, но в шаблонах типизации не будет (это кстати проблема TS).
Дрочева на TS я не понимаю, это правда. Сам компилятор Svelte написан на TS по понятным причинам — это инструмент, который идет лишь dev-зависимостью.vintage
02.04.2019 20:15То есть вы никогда не мечтали о нативной реактивности?
Боюсь это несбыточная мечта в мире JS.
Или вот когда меняешь переменную и если в DOM есть зависимые ноды, они тоже обновляются, сохраняя 100% консистентность, не?
И работает это исключительно с локальными переменными. Причём объявлены они должны быть так:
$: foo = 123;
Очень нативненько. А стоит импортировать что-то из внешнего модуля и всё, закончилась реактивность, лепи костыли руками.
в скриптах можно завести, но в шаблонах типизации не будет (это кстати проблема TS)
Если у нас что-то не работает, то это не наша проблема? Удобная позиция :-)
Сам компилятор Svelte написан на TS по понятным причинам — это инструмент, который идет лишь dev-зависимостью.
То есть для дев-зависимостей статическая типизация понятно зачем, а для приложений — не понятно?
Svelte безусловно интересный проект, но порой вас сильно заносит в попытке выставить его недостатки за достоинства.
PaulMaly Автор
02.04.2019 22:53Рад что вы спросили)))
Боюсь это несбыточная мечта в мире JS.
Пожалуй, но Svelte позволяет разработчику получить похожий DX.
И работает это исключительно с локальными переменными. Причём объявлены они должны быть так:
Это не так, вы просто не разобрались.
<h1>Hello {name}</h1> <script> export let name = 'world'; ... name = 'vintage'; // DOM auto-magically updated </script>
И даже снаружи компонента через инстанс:
import HelloWorld from './HelloWorld.svelte'; const hw = new HelloWorld({ ... }); hw.name = '$mol'; // DOM auto-magically updated
Очень нативненько.
Во-первых, это обычный JS Label, то есть чисто с точки зрения синтаксиса вполне валидно. Во-вторых, это не способ сделать реактивную переменную, а сделать реактивную декларацию, которая зависит от других реактивных переменных. Раньше это называлось вычисляемое свойство и можно было лишь сохранять в свойство. Теперь можно делать даже так:
let foo 1, bar = 2, baz = 3, qux, quux; $: { // пересчитается только если изменятся foo или bar qux = foo + bar; quux = bar * 4; // any js expression or side-effect }
А стоит импортировать что-то из внешнего модуля и всё, закончилась реактивность, лепи костыли руками.
Это тоже не так. Во-первых, все что импортируется может быть сразу использовано везде, даже в шаблонах. Например, если мы импортируем функцию, то она будет пересчитываться вместе с параметрами по pull-принципу:
<h1>Hello {getLocaleName(name)}</h1> <script> import { getLocaleName } from './helpers.js'; export let name = 'world'; </script>
Кроме того, есть еще реактивный сторы, которые можно импортировать в разные компоненты и использовать:
// Component1.svelte
<input bind:value={$name}> <!-- пишем тут --> <script> import { name } from './store.js'; </script>
// Component2.svelte
<h1>Hello {$name}</h1> <!-- обновлятся везде --> <script> import { name } from './store.js'; </script>
Если у нас что-то не работает, то это не наша проблема? Удобная позиция :-)
А у кого-то TS работает в шаблонах? Слышал вроде в Angular что-то сами они пилили для этого под каким-то флагом, но глубоко не вникал. Но базово TS не поддерживает такую кастомизацию из коробки и это прежде всего его ограничение. Так как в Svelte нет упора на TS, а отличии от Angular, нет смысла тратить на это ресурсы чтобы патчить его. Кстати, а как вы type-checking в tree-view заставили работать?
То есть для дев-зависимостей статическая типизация понятно зачем, а для приложений — не понятно?
Я не это сказал. Автору может нравиться TS и вероятно для компилятора TS даже имеет смысл. Но большинству разработчиков из Svelte сообщества TS не особо нужен, поэтому было бы странно со стороны автора делать упор на TS в зависимостях. Пока он в dev-зависимостях, это никого не парит, но если бы TS шел зависимостью в стартере и мне пришлось бы его выпиливать, чтобы начать нормально работать со Svelte, я был бы печальнее.
Svelte безусловно интересный проект, но порой вас сильно заносит в попытке выставить его недостатки за достоинства.
Так что за недостатки то, вы так и не сказали. Кстати, отвечая на ваш первый вопрос про TS — поддержка в скрипте есть, в шаблонах нет, по причинам описанным выше. Какие еще недостатки я выставляю за достоинства?vintage
02.04.2019 23:33вы просто не разобрались.
Неужели надо документацию прочитать перед использованием? Я-то думал, что везде всё интуитивно понятно, и только в $mol треш и угар.
это обычный JS Label, то есть чисто с точки зрения синтаксиса вполне валидно.
А ведёт себя не как JS вообще. Это даже хуже, чем JSX, где хотя бы видно, где JS, а где что-то ещё.
Например, если мы импортируем функцию,
А если импортируем объект, то изменения в нём никто не протрекает.
она будет пересчитываться вместе с параметрами по pull-принципу
Я бы не хотел, чтобы она пересчитывалась на каждый чих.
есть еще реактивные сторы
Вот и обсерваблы подъехали :-)
Кстати, а как вы type-checking в tree-view заставили работать?
Транспиляцией в TS.
мне пришлось бы его выпиливать, чтобы начать нормально работать
То есть мнение разработчика вашего любимого фреймворка для вас не аргумент в том, как этот фреймворк лучше использовать?
вопрос про TS — поддержка в скрипте есть
Как мы уже выяснили, Svelte использует свой язык программирования, внешне похожий на JS. TS анализатору потока исполнения это определённо снесёт крышу.
PaulMaly Автор
02.04.2019 23:52Неужели надо документацию прочитать перед использованием? Я-то думал, что везде всё интуитивно понятно, и только в $mol треш и угар.
Полагаю вы просто и не пытались. То бишь не прилагали никаких усилий. Между прочим я в свое время приложил некоторые усилия чтобы понять как работает TreeView и даже написал небольшой компонент. Просто не зашло в итоге все равно.
А ведёт себя не как JS вообще
К сожалению, в JS нет существует destiny operator'а. Можно было пойти по пути $mol/treeview и придумать полностью кастомный синтаксис, либо навесить новые смыслы на существующий. Так как сообществу очень понавилась эта идея, так и сделали. Меня сперва тоже смущало, но в итоге когда поюзал, оказалось настолько удобно, что «верно-не-верно» отошло на второй план.
Это даже хуже, чем JSX, где хотя бы видно, где JS, а где что-то ещё.
Здесь только JS, ничего «еще» нет. Просто некоторые конструкции перегруженны.
А если импортируем объект, то изменения в нём никто не протрекает.
Да, причем Svelte даже не пытается это делать. Только по принципу иммутабильных структур. Обычно этого и не надо. Данные используются максимально плоско в рамках компонента. Если нужно вглубь работать, то идет разбиение на подкомпонент и уже он отвечает на новый уроверь вложенности. Просто и понятно.
Вот и обсерваблы подъехали :-)
По сути да, но они очень простые, во-первых. Во-вторых, магия компилятора дает возможность работать с ними удобно.
Транспиляцией в TS.
Ну мне пожалуй это не надо. Уверен, если сообщество будет требовать, сделать это можно. Одна фигня компиляция идет. Можно ведь и TS код генерировать.
То есть мнение разработчика вашего любимого фреймворка для вас не аргумент в том, как этот фреймворк лучше использовать?
А какое у него мнение? У него мнение, что в компонентах TS не нужен. Собственно и мне он там не нужен и видимо большей части сообщества, раз никто не занимается этим.
Как мы уже выяснили, Svelte использует свой язык программирования, внешне похожий на JS. TS анализатору потока исполнения это определённо снесёт крышу.
Это не так. В 2-ке да, были проблемы, но в Svelte 3 в скрипте по сути находится произвольный JS код. Чтобы все работало нормально, нужно TS код транспилировать в JS код до компиляции Svelte. Это можно сделать с помощью прероцессора.
impwx
31.03.2019 11:37если статья про один язык программирования
С чего вы взяли, что статья про конкретный язык программирования? JS — это платформа с множеством инструментов поверх нее, и нет ничего плохого и удивительного в том, что люди интересуются взаимодействием с собственным инструментарием. Если кто-то напишет крутую библиотеку на Scala, наверняка многим будет интересно, как ее можно вызвать из проекта на Java / Kotlin / Groovy.
Любой нормальный алгоритм, подход или структуру данных можно строго типизировать с помощью достаточно мощной системы типов. Если это не получается, то есть три варианта. Первый — нужно дорабатывать сам TS. Второй — некий гениальный алгоритм, который можно использовать с типамиany. И третий, самый часто встречающийся — программист написал какую-то фигню :)
Вы где-то это прочитали, да?
Прочитал и подтвердил на собственном опыте.
Не дешевый такой опыт, которые при этом часто никак не обоснован.
Во-первых, отсутствие опыта часто обходится дороже, чем его получение. Во-вторых, если вы не видите обоснований или не согласны с ними — это совсем не значит, что их нет. Существует много историй о том, как крупный проект перевели с чистого джиеса на TS / Flow или даже Reason и поимели с этого профит. А вот чтобы наоборот — такого я практически не встречал.VolCh
31.03.2019 16:26С другой стороны, есть истории, где никакого профит от перехода на ТС не замечают, а недостатки замечают.
Fenzales
31.03.2019 12:50-1А вы считаете нормальным, что уже нельзя написать статью про javascript без обязательного вопроса о typescript в комментариях, даже если эта статья для новичков?
А чего ненормального? Новичок, может, typescript тоже хочет изучить.
serf
30.03.2019 19:57Нет ни Angular $scope
В Angular нет $scope.
Опять же, я понимаю любую критику в отношении синтаксиса, но мне нравится то, насколько легко понять это.
Подобного вида шаблоны с кастомным синтаксисом появляются/умирают/существуют уже десятки лет в самых рзличных фреймворках и библиотеках.
Вместо того, чтобы вкладывать JavaScript в наш HTML-код, мы просто говорим: эй, давайте сделаем цикл по этому массиву и создадим элемент для каждого из них.
Как раз для новичков полноценно освоить обычный JS было бы полезнее чем учить язык размерки определенного фреймфорка и здесь JSX ближе к стандартному JS чем svelte и многие другие фреймворки. Но я JSX не перевариваю.
Для узких задач, например внедрить виджет куда-то в чужую систему, возможно это решение удобное. То есть я бы рассматривал этот фреймворк как средство решения специализированных задач. Для крупных проектов с большой командой не вижу смысла выбирать нишевые вещи. К тому же новичкам будет проще найти работу зная что-то о react/angular/vue чем фокусироваться на svelte.PaulMaly Автор
30.03.2019 20:09+1Если вы пытаетесь на полном серьезе апеллировать к тезисам статьи, надеюсь вы обратили внимание что это перевод.
В Angular нет $scope.
Уверен автор имел ввиду AngularJS. Думаю он просто не в курсе концепции авторов ангуляра о том, как различать Angular 2+ и первую версию.
Подобного вида шаблоны с кастомным синтаксисом появляются/умирают/существуют уже десятки лет в самых рзличных фреймворках и библиотеках.
Не сказал бы что прям умирают. Думаю примерно в половине фреймворков используется DSL подобного вида. Тот же Angular. Другая половина раверное используется «типа Javascript», в виде JSX, который точно такой же DSL.
JSX ближе к стандартному JS
А мне кажется именно то, что JSX позиционируется как просто Javascript путает еще больше. Потому что раз это Javascript, тогда где же мои if/else, for/while, etc? А раз их нет, тогда какой же это JS и как понять, что можно использовать, а что нет?
Для узких задач, например внедрить виджет куда-то в чужую систему, возможно это решение удобное. То есть я бы рассматривал этоn фреймворк как средство решения специализированных задач. Для крупных проектов с большой командой не вижу смысла выбирать нишевые вещи.
Можете уточнить, с чего вы взяли, что на Svelte не получится написать все тоже самое, что на Vue или React, например? Желательно обоснованно.
К тому же новичкам будет проще найти работу что-то зная и react/angular/vue чем фокусировать на svelte.
Например, в нашей компании мы уже почти 2 года используем Svelte совместно с Vue и Ractive. Многие вещи на Svelte пишутся даже быстрее и удобнее.
Спорить про кол-во вакансий я не буду, потому что это правда. Но ведь лет 5 назад кол-во вакансий по Backbone/AngularJS/Ember/ExtJS было в разы больше чем по React, а сейчас где они все? Сейчас даже по Vue не так много вакансий (кроме Китая), так что из вашей логики делаем вывод, что все должны писать на React. А как же прогресс?
serf
30.03.2019 20:16Если бы всем поголовно во фронтенд сообществе нужны были бы статические типы, они давно бы уже стали частью стандарта.
А где я написал что не получится? На чистом JS очевидно тоже можно сделать все то же что и на фреймворках, вопрос в целесообразности. Дело ведь не просто в том чтобы написать, но развивать, поддерживать, рефакторить, оптимизировать, интегрировать, использвать множество существующих совместимых модулей, нанимать новых мемберов в команду и тд.PaulMaly Автор
30.03.2019 20:22Мне почему-то кажется, что вы выбрали неверную цитату, но я вроде бы понял на что вы отвечаете.
На чистом JS очевидно тоже можно сделать все то же что и на фреймворках, вопрос в целесообразности. Дело ведь не просто в том чтобы написать, но развивать, поддерживать, рефакторить, оптимизировать, интегрировать, использвать множество существующих совместимых модулей, нанимать новых мемберов в команду и тд.
Именно так. Поэтому мы и выбрали Svelte в свое время, очень довольны, а с выходом 3-ки станем еще больше. Код пишется невероятно быстро и точно. Протестированный код требует минимум поддержки, а его простота позволяет любому новому программисту быстро понять, как все это работает. Рефакторинг практически моментальный, опять же из-за лаконичности и простоты кода.VolCh
31.03.2019 11:13-1Такой простой рефакторинг как переименование свойства как делаете? Чтоб интересней условие: 100 и портов компонента в проекте, половина из них с переименованием
PaulMaly Автор
31.03.2019 13:26У нас с вами видимо разные представления о рефакторинге, но я постараюсь ответить на ваш вопрос, если вы его уточните. А еще лучше конкретизируете примером на другом фреймворке.
python273
31.03.2019 12:02А мне кажется именно то, что JSX позиционируется как просто Javascript путает еще больше. Потому что раз это Javascript, тогда где же мои if/else, for/while, etc? А раз их нет, тогда какой же это JS и как понять, что можно использовать, а что нет?
JSX это синтаксический сахар к вызову
React.createElement, соответственно можно использовать только то, что и при обычных вызовах функций
https://reactjs.org/docs/introducing-jsx.html#jsx-represents-objects
PaulMaly Автор
31.03.2019 12:43Это я знаю, но часто его позиционируют именно как «просто JS», но по факту это не так. Это такой же DSL, только с JS-подобным синтаксисом. А ведь JS — это по большей части императивный язык, а HTML — чисто декларативный. Поэтому нет никакого удобства создавать DSL для декларативной предметной области на основе императивного синтаксиса. Такое положение дел зачастую вызывает больше проблем у новичков, чем запомнить 3 конструкции DSL, которые присутствуют в Svelte, удобно встроены (нет лишних скобок и тп) в предметную область (html) и делают ровно то, что нужно.
justboris
31.03.2019 14:07Потому что раз это Javascript, тогда где же мои if/else, for/while, etc?
if/else
if(condition) { return <div>Condition is met</div> } else { return <div>Not met</div> }
for
const elements = []; for(const item of items) { elements.push(<div>Element {item}</div>) }
JSX просто добавляет вам еще один литерал в дополнение к стандартным литералам массивов и объектов.
1c80
30.03.2019 20:20+3Если бы я был новичком, то лучше потратил бы время на изучение нативного JS.
А потом выбрал бы тот фрэймворк(и), который в тренде и на котором реально заработать можно.
Не зная основ, можно очень легко увязнуть в этой магии, если что то пойдет не так.
А изучить все фрэймворки, голова лопнет, они хоть и похожи, но каждом куча нюансов.PaulMaly Автор
30.03.2019 20:28С вами сложно не согласиться. Собственно автор статьи и рассуждает на эту тему. Его основной довод — в реальных проектах уже давно мало кто пишет на ваниле и все абстрагировано донельзя. Svelte в этом смысле наоборот наиболее ванильный фреймворк, по сравнению с остальными, где магия спрятана в дебрях рантайма. В Svelte вы можете открыть скомпилированный компонент и посмотреть как манипуляции в DOM работают напрямую, а не завернутые в абстракции типа VDOM.
Второй довод автора — очень просто можно перегореть, когда начинаешь разбираться в разработке с нуля. Да, вроде как принято сперва информатику изучать в теории, но если не начать достаточно быстро решать интересные и практические задачи, можно и не завершить обучение вообще. Лично я за итеративное обучение, а не последовательное. Когда на разных этапах, мы как бы возвращаемся к оному и тому же, только на новом уровне познания. Как по спирали.
uvelichitel
30.03.2019 20:53+1Чтобы привлечь внимание к Svelte стоит упомянуть что его автор — Rich Harris на счету у которого Rollup и Ractive примененный в The Guardian.
serf
30.03.2019 21:23Ractive примененный в The Guardian
Вполне логично ведь Rich Harris работал в The Guardian судя по этому материалу shoptalkshow.com/episodes/349PaulMaly Автор
30.03.2019 21:42Именно так, а сейчас он работает в NYT и там используют Svelte. Не знаю как, но крупные издания с высонагруденными сайтами почему-то доверяют ему и его разработкам. И даже оплачивают занятия open-source проектами в рабочее время.
serf
30.03.2019 21:46Вполне допускаю что например админка в NYT написана на других фреймворках, там легковесность и неконфликстость с другими решениями на странице особенно не важны. А штуковины сделанные на svelte что называется user facing, легковесные виджеты встраиваемые например в страницы статей. Также могу предположить что на svelte сделаны виджеты которые встраивают себе другие ресурсы.
PaulMaly Автор
30.03.2019 22:34Не знаю по поводу админки, но уверен, что публичный сайт любого серьезного издания — это довольно большой легаси, построенных еще на классических способах сайтостроения, где SSR привалирует. Но это же и одна из сильный сторон Svelte.
На нем не только можно написать SPA приложение любой сложности, но и встроить в существующий сайт в качестве виджетов. Более того, можно его компоненты встроить вообще в любое приложение, написанное хоть на React, хоть на Angular. Мы например, такое делали для легаси приложений на Ractive. Благодаря своей концепции, Svelte также прекрасно работает поверх концепции микрофронтендов.VolCh
31.03.2019 11:14Кстати, как у него с SSR?
PaulMaly Автор
31.03.2019 12:50+1Прекрасно. Это же компилятор. В данный момент он поддерживает компляцию в DOM (ванильные DOM манипуляции) и SSR (html строка), а также дополнительную опцию customElement если нужно получать DOM код в виде готового веб-компонента. Поддержка стандарта 100%.
Однако, так как формат Svelte-компонентов обобщен, в будущем, возможно, эти же компоненты можно будет скомпилировать и в другие таргеты, например, в нативные мобильные приложения. Все это конечно зависит от того, куда пойдет развитие.
Конкретно по поводу SSR есть готовый к использованию изоморфный фреймворк поверх Svelte где все настроено из коробки: https://sapper.svelte.technology
rudinandrey
30.03.2019 21:40+1пока читал не покидало ощущение дежавю, что если бы я не видел названия Framework'а, то я бы подумал что это о RiotJS :-) и код даже частично похож. И к слову, я считаю что RiotJS действительно лучший JS фреймворк. К слову, ушел на RiotJS с RactiveJS в свое время, это по моему родитель Vue фреймворка. По крайней мере они очень похожи. В ReactJS считаю очень много магии, дополнительных компонентов Babel, Redux и т.п.от которых он зависит. А вот Riot самодостаточный, легкий, быстрый и максимально простой, хотя откровенно говоря что он очень походит на React
serf
30.03.2019 21:52-1Легкость и простота подходят для легких/простых/однорзовых задач. Для задач другого плана подходят другие инструменты.
PaulMaly Автор
30.03.2019 22:13И к слову, я считаю что RiotJS действительно лучший JS фреймворк. К слову, ушел на RiotJS с RactiveJS в свое время,
Мы тоже пробовали Riot в свое время, когда еще Muut пытались его пиарить. Тогда он был еще сыроват и местами глючил. Поэтому мы так и не сделали его альтернативой Ractive. А после после выхода Vue 2 добавили его в стек. В 2017-м добавили еще Svelte и перестали писать новые проекты на Ractive, несмотря на то, что он до сих пор развивается.
это по моему родитель Vue фреймворка. По крайней мере они очень похожи.
Да, Vue изначально очень многое взял от Ractive. Сейчас клонирует решения из Angular/React. Вообще, китайский менталитет чуствуется конечно)))
Кстати, Single File Components, которые в том или ином виде реализованы в Vue, Svelte, Riot, первыми появились в Ractive тоже: component-spec.
Могу добавить, что вы смотрите только на синтаксис и не концентрируете внимание на главной особенности Svelte — нет никакого svelte.min.js в рантайме.
alsii
31.03.2019 00:28нет никакого svelte.min.js в рантайме.
он есть. просто он тщательно перемешан с вашим кодом, а не находится в отдельном файле.
PaulMaly Автор
31.03.2019 11:17Это не совсем так. Есть небольшой набор хелперов, которые выполняют рутинные операции с DOM, но это сложно назвать фреймворком. Основная особенность Svelte, в этом плане, в том что у него наиболее полная AoT-компиляция, среди всех известных фреймворков. Иными словами он не только прекомпилирует декларативные шаблоны в js, как делают многие, но статически анализирует все связи между данными и DOM, заранее обсчитывая все возможные манипуляции при изменениях и генерируя готовый к испольнению ванильный код, не требующий расчетов в рантайме.
Это очень похоже на то, как если бы вы вдруг захотели сами написать приложение полностью на ваниле. Скорее всего делали бы примерно тоже самое, только руками. К тому же неминуемо столкнулись с «комбинаторным взрывом». Svelte позволяет вам писать ванильные приложения без необходимости писать на ваниле и решать все эти проблемы вручную.alsii
01.04.2019 13:40готовый к испольнению ванильный код
такой же который лежит дистрибутиве фреймворка?
код, не требующий расчетов в рантайме.
не совсем понял, что это такое.
Вообще на мой взгляд это выглядит примерно так: "При программировании на C мы не будем использовать stdin. Вместо этого у нас есть очень умный препроцессор, который разворачивает все stdin-подобные вызовы в vanilla-C код. При этом он проводит статический анализ исходного кода и генерирует максимально эффективный выходной код для каждого случая".
Я не спорю, что такой подход имеет право на жизнь. Вот только совершенно не очевидно, какие это дает преимущества по сравнению с фреймворком/библиотекой.
PaulMaly Автор
02.04.2019 14:46такой же который лежит дистрибутиве фреймворка?
Код, который можно прочитать как есть, на месте, который внутри не использует интерполяцию строк или еще что-то, а напрямую манипулярует с DOM через API.
не совсем понял, что это такое.
Ну это что-то вроде метапрограммирования наверное. В итоге вы пишете декларативно так:
<h1>Hello {name}!</h1> <script> export let name = 'world'; </script>
После компиляции это превращается в что-то вроде (всевдокод):
... const h1 = document.createElement('h1'), t1 = document.createTextNode('Hello '), t2 = document.createTextNode(name), t3 = document.createTextNode('!'); ... if ('name' in changed) { t2.nodeValue = name; } ...
То есть максимально понятно и прямолинейно, без каких-либо вычислений в рантайме. В тоже время вы сами не захотите писать такой код руками, несмотря на то, что он очень эффективный. В этом и смысл — вы дикларативно описываете бизнес-логику на высоком уровне абстракции, а Svelte генерирует максимально эффективный код с минимальным кол-во вычислений в рантайме.
Вообще на мой взгляд это выглядит примерно так: «При программировании на C мы не будем использовать stdin. Вместо этого у нас есть очень умный препроцессор, который разворачивает все stdin-подобные вызовы в vanilla-C код. При этом он проводит статический анализ исходного кода и генерирует максимально эффективный выходной код для каждого случая».
Я бы не сказал, что это какой-то супер уникальный подход. Метапрограммирование существует много лет. Есть даже целые языки, которые на это заточены.
Я не спорю, что такой подход имеет право на жизнь. Вот только совершенно не очевидно, какие это дает преимущества по сравнению с фреймворком/библиотекой.
Ну можно взять например VDOM, который на каждое изменение стейта стоить виртуальное DOM дерево просто чтобы вычислить что изменилось и как нужно пропатчить реальный DOM. Это большая рантайм абстракция, которое еще и память нехило кушает. В Svelte вместо этого будет что-то вроде того, что я привел выше — просто сразу патчим DOM. Все потому VDOM вычисляет изменения в рантайме, а Svelte во время компиляции.vintage
02.04.2019 20:42В Svelte вместо этого будет что-то вроде того, что я привел выше — просто сразу патчим DOM.
Это тоже не правда. Он не может никак протрекать, что именно вы изменили в дереве объектов и какие именно части приложения нужно обновить, поэтому он пойдёт реконцилировать всё, что прямо или косвенно зависит от изменённой переменной.
В частности, будут проблемы следующих типов:
Если вы измените объект так, что это не будет выглядеть как изменение с точки зрения компилятора (например, вызов
setMonth()уDate), то компилятор не сможет протрекать это изменение.
Чтобы понять надо ли что-то перерендеривать, ему придётся дёрнуть все выражения, для всех мест, что прямо или косвенно зависят от изменённой переменной, что может быть очень медленно (например,
toLocaleString()уDateдля каждой задачи в списке, при изменении, например, названия любой из них).
PaulMaly Автор
02.04.2019 23:01Это тоже не правда. Он не может никак протрекать, что именно вы изменили в дереве объектов и какие именно части приложения нужно обновить, поэтому он пойдёт реконцилировать всё, что прямо или косвенно зависит от изменённой переменной.
Неа, вы видимо не понимаете как это работает.
Если вы измените объект так, что это не будет выглядеть как изменение с точки зрения компилятора (например, вызов setMonth() у Date), то компилятор не сможет протрекать это изменение.
Все это решается как и везде — иммутабильным изменением объектов. Svelte вообще ничего не трекает. Он делает простое сравнение !== и все. Все эти реконсилейшены и не нужны. KISS.
Чтобы понять надо ли что-то перерендеривать, ему придётся дёрнуть все выражения, для всех мест, что прямо или косвенно зависят от изменённой переменной, что может быть очень медленно (например, toLocaleString() у Date для каждой задачи в списке, при изменении, например, названия любой из них).
Медленно или нет это мерить надо. Svelte конечно не самый быстрый и микрооптимизациями не страдает. Но быстрый достаточно для любых видов задач. Плюс у него неплохие все остальные метрики. Если вы пришли сюда опять письками мериться, то давайте закончим этот диалог. Мне это не интересно.vintage
02.04.2019 23:45Неа, вы видимо не понимаете как это работает.
Svelte вообще ничего не трекает.
реконсилейшены и не нужны.Да уж представьте себе почитал код, который он генерит. Характерный пример:
function submit(event) { items[editing].description = event.target.value; $$invalidate('items', items); }
И понеслись проверки каждого айтема, не изменилось ли что. Это и есть реконциляция.
PaulMaly Автор
03.04.2019 00:15И понеслись проверки каждого айтема, не изменилось ли что. Это и есть реконциляция.
Какая же это реконциляция если он только строгое сравнение делает? Если вы это называете реконциляцией, то ок. Но это очень быстро и дешево.
alsii
31.03.2019 00:33React можно и без Babel и без Redux. Просто не используйте JSX и храните state в компонентах. Не обязательно во всех. Можете вытащить его в root-компонент. Да, не получите некоторых фишек, но не всегда и не везде они так уж нужны...
megahertz
31.03.2019 11:07Всегда интересно было, на React без jsx кто-нибудь писал что-нибудь посерьезнее hello world?
VolCh
31.03.2019 11:25-1Компоненты без jsx попадались, но не могу однозначно сказать, был это результат компиляции или ручной код.
alsii
01.04.2019 12:13а в чем собственно проблема? JSX — всего лишь синтаксический сахар над
React.createElement. Нужели разница между следующими фрагментами настолько существенна?
JSX
<MyComponent count="{count}" onClick="{handleClick}"> <span>Hello World</span> </MyComponent>
прямой вызов React.createElement
const e = React.createElement ... e(MyComponent, {count, onClick:handleClick}, e('span', {}, 'Hello World'), )megahertz
01.04.2019 12:27Вопрос не о том что такое jsx, а про реальные примеры без него. Ваш пример как-раз из разряда hello world. Под реальными примерами я подразумеваю какие-то открытые проекты. Ну или просто упоминание, на подобие «мы в своем проекте содержащем 100+ компонентов не пользуемся jsx».
alsii
01.04.2019 12:58+1Я просто хотел показать, что технологически это вполне возможно и сложности не добавляет.
мой, не очень характерный случайЯ использую такой стиль чтобы добавить возможности react на отдельные страницы в классическом web-приложении (php и рендеринг на стороне сервера, у клиента — чистый HTML). Приложение большое, старое (около 5 лет разработки), используется внутри компании. Переписывать полностью как SPA нет ни особого смысла, ни возможностей. А вот добавить «жизни» на некоторые странички иногда оказывается полезным.
Разворачивать полный стек для front-end (nodejs, npm, webpack и т.д.) особого смысла я так же не вижу, как и усложнять для этого процессы деплоя. Возможно, когда будет накоплена некоторая критическая масса, это будет иметь смысл. Переписывать же то, что уже написанно без JSX не придется.
Изначально на некоторых страницах использовался jQuery, но там, где логика становится достаточно сложной, jQuery-код имеет сильный привкус спагетти. Поэтому новый вещи делаются на react. Вообще в приложении js-кода очень немного, так что в далеких планах есть пункт о том, чтобы вообще избавиться от jQuery, хотя бы в самых сложных случаях.
Вот такой у меня получился case.megahertz
01.04.2019 13:41Спасибо. Много такого кода на реакте получается? Насколько по ощущениям читабельность снижается?
alsii
01.04.2019 14:11Собственно кода на реакте столько же, как и с JSX. Насчет читаемости — дело привычки. Вот, оцените сами кусочек из нерабочего проекта. Тут задействованы еще стили из bootstrap и AdminLTE.
Заголовок спойлераconst LoginPage = props => { const [auth, setAuth] = React.useState({email: '', password: ''}) const handleChange = ({target}) => setAuth({...auth, [target.name]: target.value}) const handleSubmit = e => { e.preventDefault(); console.log('LoginPage::handleSubmit', e, jsonHeaders); fetch('/api/auth/login', {method: 'POST', body: JSON.stringify(auth), headers: jsonHeaders}) .then(response => response.ok && response || Promise.reject(response)) .then(response => response.json()) .then(data => props.onSubmit(data.result.token)) .catch(result => console.log('LoginPage::handleSubmit:failure', result)) } document.body.setAttribute('class', 'hold-transition login-page') return e('div', {className: 'login-box'}, e('div', {className: 'login-logo'}, e('b', {}, 'Load'), 'Machine'), e('div', {className: 'login-box-body'}, e('p', {className: 'login-box-msg'}, 'Log in to start loading'), e('form', {onSubmit: handleSubmit}, e('div', {className: 'form-group has-feedback'}, e('input', {name: 'email', type: 'email', className:'form-control', placeholder: 'E-mail', onChange: handleChange}), e('i', {className: 'fa fa-envelope form-control-feedback'}), ), e('div', {className: 'form-group has-feedback'}, e('input', {name: 'password', type: 'password', className:'form-control', placeholder: 'Password', onChange: handleChange}), e('i', {className: 'fa fa-lock form-control-feedback'}), ), e('div', {}, e('button', {className: 'btn btn-primary btn-block btn-flat'}, 'Log in'), ), e('br'), e('a', {onClick: props.onRegister, href:'#'}, 'Register'), ) ) ) }
user9000
30.03.2019 23:01Маятник JS качнулся в обратную сторону?
Psychosynthesis
31.03.2019 00:30Это неминуемый процесс, учитывая неконтролируемое усложнение реактивного подхода.
Psychosynthesis
31.03.2019 00:27А запросы к серверу и селект элементов как реализовывать, инструмент какой-нибудь есть? Или предложите использовать fetch или подключать к проекту jQ?
yarkov
31.03.2019 00:51Или предложите использовать fetch
А чем fetch не угодил?AndreasCag
31.03.2019 22:36Тем, что он не throw'ит ошибки на не 2xx коды от сервера и не позволяет трекать прогресс
VolCh
31.03.2019 23:49или отменить его.
justboris
01.04.2019 09:31+1С этим уже все в порядке. AbortController завезли во все современные браузеры, где был нативный fetch.
alsii
01.04.2019 13:25Первый вопрос (если уж он действительно принципиален) решается так:
fetch(url) .then(response => response.ok ? response : Promise.reject(response)) .then(response => { ... }) .catch({ ... })
megahertz
31.03.2019 11:12Да, fetch. Если IE нужен — с полифилом. А с селекторами еще проще, querySelector работает в ie8+
PaulMaly Автор
31.03.2019 11:22Все же Svelte это UI фреймворк. Поэтому вы вольны использовать любые средства для работы с ajax. На проектах посложнее, мы обычно используем axios. Он изоморфный и очень «feature rich». Если нужно что-то попроще, тогда unfetch — 500B полифил для fetch.
Кроме того, есть еще Sapper — изоморфный фреймворк для PWA поверх Svelte. Там встроен и роутинг и фетчинг: sapper.svelte.technology
PavlovM
31.03.2019 05:51Используем Svelte параллельно с Vue. Вещь достаточно приятная, но очень молодая и сыроватая. Документация слабая, на Stackoverflow вопросов/ответов мало, так что в случае не совсем банальной проблемы приходится сложно. И именно поэтому я бы не советовал новичкам начинать с него.
Лично мне очень не хватает поддержки Typescript, недавно пришлось городить костыли для нее, но это уже другая история, которую обсудили выше.
1c80
31.03.2019 09:03А что дал такой вариант в чем выразилось преимущество Svelte? что мешало использовать только Vue?
Я даже нормальных UI компонент не нашел под SveltePavlovM
31.03.2019 09:55Там большой и старый проект, часть страниц сделана на первом Angular, часть — на Vue. Svelte решили использовать для тех элементов, которые должны подключаться и там и там (например, сквозная навигация). Мол, исчезающий фреймворк, все будет шустро и круто.
Ну и определяющая причина была в том, что фронт-тимлид и несколько других ребят решили поиграть с модной штукой :) Я работаю немного на другом направлении и изначально меня про этот выбор и не спрашивали.
На самом деле, в итоге, я не вижу больших преимуществ. Размер и скорость выполнения кода сопоставимы (хотя, серьезных сравнительных тестов не проводили), все тоже самое можно было сделать и на Vue, не добавляя новых зависимостей и оставаясь в более стабильной и развитой экосистеме.
1c80
31.03.2019 10:02Ясно спасибо, так и думал примерно.
и в статье и комментах пока никто не привел конкретного примера, где Svelte бы всех резко уделал в каком то моменте, так что пока да, интерес есть, но и только.
PaulMaly Автор
31.03.2019 13:18Ну вообще преимуществ уйма, а сравнение на реально примере можно по-быстрому хотя бы тут глянуть: medium.freecodecamp.org/a-real-world-comparison-of-front-end-frameworks-with-benchmarks-2018-update-e5760fb4a962
В нашей компании используем Vue в проектах, когда заказчик хочет «что-то из популярного» и всегда Svelte, если заказчику все равно.PavlovM
31.03.2019 13:48Я бы не сказал, что их уйма, кроме размера бандла и скорости. Однако и эти преимущества, скорее всего, будут нивелироваться при увеличении приложения, потому что на небольшом примере "исчезающий" Svelte предсказуемо выигрывает у фреймворков, которые тащат в рантайм много всего разного, однако чем больше проект, тем меньшую долю в его производительности занимает загрузка и старт самого фреймворка.
Производительности других фреймворков на данный момент тоже вполне достаточно для большинства случаев, а в экосистеме же Svelte пока явно уступает "большой тройке".
Я ничего не имею против этого фреймворка (кроме того, что мне больше по душе стандартные экшены-мутации, чем местный store), однако считаю, что для крупных проектов он ещё слишком молод. Скоро, кажется, выйдет третья версия — будем посмотреть.
PaulMaly Автор
31.03.2019 14:32Я бы не сказал, что их уйма, кроме размера бандла и скорости.
Этого мало? В Svelte 3 еще упрощенный синтаксис самих компонентов и сторов, который позволяте писать в 1.5-2 раза меньше кода по сравнению конкретно c Vue. Имхо это тоже сильный плюс.
Однако и эти преимущества, скорее всего, будут нивелироваться при увеличении приложения, потому что на небольшом примере «исчезающий» Svelte предсказуемо выигрывает у фреймворков, которые тащат в рантайм много всего разного, однако чем больше проект, тем меньшую долю в его производительности занимает загрузка и старт самого фреймворка.
Когда проект разрастается, то в игру вступает code-splitting. Благодаря тому, что Svelte собирает в каждый бандл только то, что действительно необходимо для его работы и сами бандлы являются полностью независимыми, это значительно упрощает работу на больших проектах. Потому что с классическим подходом — даже самый маленький кусочек вашего кода зависит от всего фреймворка.
а в экосистеме же Svelte пока явно уступает «большой тройке».
Тоже самое было и с Vue года 2-3 назад. Так что это так себе аргумент.
однако считаю, что для крупных проектов он ещё слишком молод.
А все видимо поголовно пишут энтерпрайзы, да? Это даже чисто статистически невозможно.
Скоро, кажется, выйдет третья версия — будем посмотреть.
Данная статья именно о Svelte 3.
(кроме того, что мне больше по душе стандартные экшены-мутации, чем местный store),
Как раз мемчик на эту тему:
PavlovM
31.03.2019 15:06Моя точка зрения заключается в том, что пока что Svelte подходит для больших/долгоживущих проектов меньше, чем «большая тройка», потому что единственный его плюс — производительность, но и производительности других фреймворков для большинства задач вполне достаточно, даже на слабых устройствах.
Минусы же, в лице пока что слабо развитой экосистемы, отсутствия хорошей документации и прочих детских болячек — на лицо.
Если ваша точка зрения отличается — ок, у меня с этим нет никаких проблем.
Свое отношение я высказал — вещь интересная, возможно, перспективная, но большой проект я бы на ней пока не писал. Однако, всячески желаю ей расти, развиваться и чтобы через год-два-три я изменил свое мнение.
Что касается «Тоже самое было и с Vue года 2-3 назад.», то тут я не соглашусь с вашей логикой. Кроме Vue несколько лет назад существовала прорва других начинающих фреймворков, однако большинство из них сгинуло, а Vue стал популярен, во многом, благодаря хорошей документации и простоте освоения. Если у проекта пока нет хорошей документации, это не значит, что через несколько лет он станет таким же популярным, как Vue. Это значит лишь то, что пока у проекта нет хорошей документации.vintage
31.03.2019 15:27производительности других фреймворков для большинства задач вполне достаточно, даже на слабых устройствах
Это совсем не так.
PaulMaly Автор
02.04.2019 15:04Минусы же, в лице пока что слабо развитой экосистемы, отсутствия хорошей документации и прочих детских болячек — на лицо.
С первым абзацем не согласен, но это ваше мнение. Тут могу отметить, что детские болячки есть конечно, как и у всех. Однако для v3 доки стали значительно лучше, чего только новые Tutorial и REPL стоят. Начать пробовать можно прямо в REPL и просто скачать готовый проект оттуда.
Свое отношение я высказал — вещь интересная, возможно, перспективная, но большой проект я бы на ней пока не писал. Однако, всячески желаю ей расти, развиваться и чтобы через год-два-три я изменил свое мнение.
Все верно! Тут ведь как, любую новую вещь кто-то раньше оцениват по достоинству, кто-то позже.
kvghabr
31.03.2019 12:22+1Интересно выглядит. Даже если сам фрэймворк не взлетит, то концепты, выпиливающие как можно больше сущностей (не в ущерб функциональности) из нынешнего зоопарка, должны развиваться.
LeshiyUrban
31.03.2019 14:26Если кому интересно, то я делал не сложный ui на этом фреймворке: https://github.com/reddec/monexec-ui
Это SPA UI для супервизора https://github.com/reddec/monexec
В целом удобно.
Senyaak
01.04.2019 22:51Веб компоненты итд уже являються очень хорошей альтернативой фреймворков — а когда введут вот это — github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md — зачем нужны будут вообще какие либо фреймворки?
justboris
01.04.2019 23:41Как видно из секции "3.3. Conditionals and Loops using Nested Templates", всю самую интересную часть оформлению циклов и условий предполагается делегировать фреймворкам. А без этой базовой функциональности даже простую страничку не собрать.
P.S. тем не менее, спасибо за ссылку, расширили мой кругозор.
Senyaak
02.04.2019 00:06Это спокойно реализуется кастомным элементом — пихать это в темплейт не обязательно. Там даж дальше по тексту об этом написано)
justboris
02.04.2019 01:49зачем нужны будут вообще какие либо фреймворки?
Это спокойно реализуется кастомным элементомКак-то вот эти два утверждения не складываются. В любом случае придется подключить какой-то дополнительный код, чтобы все заработало как надо.
Senyaak
02.04.2019 16:361) Дополнительный код — можно и не подключать — а написать всё руками
2) Подключение каких либо библиотек — это не тоже самое что воткнуть фреймворк в проект
PaulMaly Автор
02.04.2019 14:59Решить можно все. Чтобы хоть как-то писать нормально на веб-компонентах уже придумали lit-element/lit-html, но ведь это тоже фреймворки по-сути. Да и сами веб-компоненты, если включить shadow-dom становятся довольно медлеными.
Кроме того, раз уж речь про Svelte, если вдруг ситуация с веб-компонентами изменится к лучшему, всегда можно скомпилировать Svelte-компоненты в веб-компоненты с помощью одного флага и продолжить юзать их таким образом. Так что мы ничего не теряем!Senyaak
02.04.2019 23:28А можно источник — где описываеться как и почему шэдоу дом негативно влияет на производительность
PaulMaly Автор
03.04.2019 00:21+1Источника дать не могу, это просто тесты показывают. Попробуйте создать веб-компонент с shadow-root и без него. Сделайте замеры и сами все увидите, насколько станет медленнее.
Могу вот еще дать ссылку на тесты, которые делались к другой статье. Они конечно искусственные, но разница в скорости слишком существенная, чтобы списать на погрешность.
muhammad_97
02.04.2019 05:54-1Есть еще [Riot.js](https://riot.js.org/), который местами очень схож со Svelte. И тот и другой сгодятся максимум для каких-нибудь небольших pet-project, да и в них лучше заюзать React, если уже знакомы с ним.
В целом действительно неплохо для новичков, как переходной этап к более серьезным фреймворкам типа React, Vue и Angular.
> Это означает, что нет виртуального DOM, нет фреймворков поверх фреймворков и нет фреймворка в рантайме.
> Все это довольно серьезные аргументы для более опытных разработчиков
Не увидел аргументов.
stalkerg
02.04.2019 07:51+1Мы используем Svelte уже для второго крупного проекта и я не понимаю о чем вы говорите.
В нем все делается проще, работает быстрее, памяти жрет меньше, бандл в итоге то же компактнее. Я не знаю зачем React и Vue нужны… для любого новоого проекта ответ один — Svelte.
PaulMaly Автор
02.04.2019 14:55В целом действительно неплохо для новичков, как переходной этап к более серьезным фреймворкам типа React, Vue и Angular.
А можете как-то аргументировать чем React более серьезен? Vue ладно, примерно схож по возможностям. Angular, очень замороченный, но действительно фактически комбайн. Но React то в каком месте я понять не могу?
Не увидел аргументов.
Не увидели аргументо в том, что у вас код будет работать быстрее, размер бандла будет меньше, кода придется писать в разы меньше и в целом эффективнее, не? Ну тогда я не знаю, действительно, никаких плюсов.
easyman
Все супер, но real-life примеров мало.
Например, я был бы рад SPA с jwt авторизацией используя SSO и Google/FB
PaulMaly Автор
Вообще это отличная идея! Можете дать ссылку на real-life пример подобного типа для React или Vue? Быть может я бы заморочился с этим для Svelte.
questor
Уже есть такой в проекте realworld
PaulMaly Автор
Ну это не интересный пример. Там Svelte еще в том году почти всех порвал: A Real-World Comparison of Front-End Frameworks with Benchmarks .
К тому же там нет ни JWT, ни SSO.