Это небольшая ответная статья на публикацию «Сравнение JS-фреймворков: React, Vue и Hyperapp». Вообще я не большой фанат подобных сравнений. Однако раз уж речь зашла о таком маргинальном фреймворке, как Hyperapp, в сравнении с мастодонтами, типа React и Vue, я подумал, почему бы не рассмотреть все те же примеры на Svelte. Так сказать, для полноты картины. Тем более, это займет буквально 5 минут. Поехали!
Если вдруг вы не знакомы со Svelte и концепцией исчезающих фреймворков, можете ознакомиться со статьями «Магически исчезающий JS фреймворк» и «Исчезающие фреймворки».
Для удобства читателей, я скопировал примеры из оригинальной статьи под спойлеры, чтобы было удобнее сравнивать. Что ж приступим.
> Рабочий пример.
Компонент Svelte — это html-файл, который имеет небезызвестный формат Single File Component (SFC), в том или ином виде, уже применяющийся в Vue, Ractive, Riot и некоторых других фреймворках. Кроме самого html-шаблона, компонент может иметь поведение и логику, описанную на javascript, а также scoped-стили компонента.
Ни одна часть компонента не является обязательной, поэтому компонент счетчика может состоять лишь из html-шаблона самого счетчика. Для изменения значения переменной count, обработчик кликов использует встроенный метод компонента set(), описанный в документации.
> Рабочий пример.
В отличие от JSX, который, как под копирку, применяется во всех 3-х фреймворках из оригинального сравнения, и по сути расширяет javascript код html-подобным синтаксисом, Svelte использует более привычные возможности — внедрение js и css кода в html с помощью тегов <script> и <style>.
Скрипт компонента экспортирует простой JS объект, разделенный на секции. В секции methods описываются методы компонента, которые могут быть использованы через инстанс компонента и в обработчиках событий. Так, при нажатии на кнопку, вызывается метод getData(), внутри которого запрашиваются данные и по завершению операции, данные просто устанавливаются в стейт компонента и сразу же отрисовываются в шаблоне.
Обратите внимание, на использование деструктуризации объекта публикации (post) на каждом шаге итерации списка публикаций:
Этот трюк позволяет избежать избыточности в шаблонах типа {post.title} и визуально упростить шаблоны, используя более короткую запись {title}.
> Рабочий пример.
Тут все довольно банально. Выставляем css-класс в зависимости от значения done и меняем это значение на противоположное при клике на элемент списка.
Disclaimer: С этого момента я решил опустить сравнение с Hyperapp, потому что иначе таблицы будут просто не читаемые.
Svelte крайне минималистичен, в том числе в плане хуков жизненного цикла. Существует всего 4 хука:
Честно говоря, не знаю что тут комментировать. Сами по себе бенчмарки и способ их исполнения всегда вызывает много споров, поэтому не думаю что имеет смысл излишне заострять внимание.
Однако других данных у нас все равно нет.
Cудя по цифрам, Svelte довольно быстрый, «жрет» мало памяти (в том числе потому что не использует VirtualDOM), быстро запускается и имеет небольшие размеры.
Вообще, сказать что результаты бенчмарков этих 3-х фреймворков отличались кардинально, я не могу. Однако, только Svelte имеет исключительно «зеленый» столбик, т.е. он достаточно хорош сразу по всем показателям, а значит отлично сбалансирован и не имеет явных перекосов ни в скорости, ни в потреблении памяти и иных метриках. В общем, с ним смело можно начинать любой проект, от обычного веба, до мобильных устройств, Смарт ТВ и более экзотичных систем.
Svelte — отличный инструмент для создания компонентов практически любых веб-приложений. Он такой же мощный как React и хотя пока имеет значительно меньшее сообщество, при этом требует меньше усилий для освоения. Он гибок, как Vue, при этом значительно более минималистичен и выверен, так как не пытается ухватиться сразу за все идеи современной веб-разработки.
Кроме того, он единственный использует концепцию исчезающих фреймворков. Иными словами он не имеет никакого специфического рантайма, кроме самого браузера.
Приложения на нем получаются быстрыми, не требовательными к ресурсам и маленькими в размере. Кроме того, Svelte может «бесшовно» использоваться в приложениях, написанных на других фреймворках, о чем я планирую написать в следующий раз.
Если вы впервые познакомились с этим замечательным фреймворком, возможно вам будет интересно прочитать и другие статьи о нем:
> Магически исчезающий JS фреймворк
> 1Kb autocomplete
> SvelteJS: Релиз второй версии
Если у вас остались вопросы по Svelte, вступайте в русскоязычный телеграм канал SvelteJS. Там вы всегда сможете задать вопрос и получить совет, узнать последние новости, а также просто приятно пообщаться. Будем вам рады!
Если вдруг вы не знакомы со Svelte и концепцией исчезающих фреймворков, можете ознакомиться со статьями «Магически исчезающий JS фреймворк» и «Исчезающие фреймворки».
Для удобства читателей, я скопировал примеры из оригинальной статьи под спойлеры, чтобы было удобнее сравнивать. Что ж приступим.
Пример №1: приложение-счётчик
React
import React from "react";
import ReactDOM from "react-dom";
class Counter extends React.Component {
constructor(props) {
super(props);
this.state = { count: 0};
}
down(value) {
this.setState(state => ({ count: state.count - value }));
}
up(value) {
this.setState(state => ({ count: state.count + value }));
}
render() {
return (
<div>
<h1>{this.state.count}</h1>
<button onClick = {() => this.down(1)}>-</button>
<button onClick = {() => this.up(1)}>+</button>
</div>
);
}
}
ReactDOM.render(<Counter />, document.querySelector("#app"));
Vue
import Vue from "vue";
new Vue({
data: { count: 0 },
methods: {
down: function(value) {
this.count -= value;
},
up: function(value) {
this.count += value;
}
},
render: function(h) {
return(
<div>
<h1>{this.count}</h1>
<button onClick={() => this.down(1)}>-</button>
<button onClick={() => this.up(1)}>+</button>
</div>
);
},
el: "#app"
});
Hyperapp
import { h, app } from "hyperapp";
const state = {
count: 0
};
const actions = {
down: value => state => ({ count: state.count - value}),
up: value => state => ({ count: state.count + value})
};
const view = (state, actions) => (
<div>
<h1>{state.count}</h1>
<button onclick={() => actions.down(1)}>-</button>
<button onclick={() => actions.up(1)}>+</button>
</div>
);
app(state, actions, view, document.querySelector("#app"));
?Svelte
<div>
<h1>{count}</h1>
<button on:click="set({count: count - 1})">-</button>
<button on:click="set({count: count + 1})">+</button>
</div>
> Рабочий пример.
?Анализ
Компонент Svelte — это html-файл, который имеет небезызвестный формат Single File Component (SFC), в том или ином виде, уже применяющийся в Vue, Ractive, Riot и некоторых других фреймворках. Кроме самого html-шаблона, компонент может иметь поведение и логику, описанную на javascript, а также scoped-стили компонента.
Ни одна часть компонента не является обязательной, поэтому компонент счетчика может состоять лишь из html-шаблона самого счетчика. Для изменения значения переменной count, обработчик кликов использует встроенный метод компонента set(), описанный в документации.
Пример №2: работа с асинхронным кодом
React
import React from "react";
import ReactDOM from "react-dom";
class PostViewer extends React.Component {
constructor(props) {
super(props);
this.state = { posts: [] };
}
getData() {
fetch(`https://jsonplaceholder.typicode.com/posts`)
.then(response => response.json())
.then(json => {
this.setState(state => ({ posts: json}));
});
}
render() {
return (
<div>
<button onClick={() => this.getData()}>Get posts</button>
{this.state.posts.map(post => (
<div key={post.id}>
<h2><font color="#3AC1EF">{post.title}</font></h2>
<p>{post.body}</p>
</div>
))}
</div>
);
}
}
ReactDOM.render(<PostViewer />, document.querySelector("#app"));
Vue
import Vue from "vue";
new Vue({
data: { posts: [] },
methods: {
getData: function(value) {
fetch(`https://jsonplaceholder.typicode.com/posts`)
.then(response => response.json())
.then(json => {
this.posts = json;
});
}
},
render: function(h) {
return (
<div>
<button onClick={() => this.getData()}>Get posts</button>
{this.posts.map(post => (
<div key={post.id}>
<h2><font color="#3AC1EF">{post.title}</font></h2>
<p>{post.body}</p>
</div>
))}
</div>
);
},
el: "#app"
});
Hyperapp
import { h, app } from "hyperapp";
const state = {
posts: []
};
const actions = {
getData: () => (state, actions) => {
fetch(`https://jsonplaceholder.typicode.com/posts`)
.then(response => response.json())
.then(json => {
actions.getDataComplete(json);
});
},
getDataComplete: data => state => ({ posts: data })
};
const view = (state, actions) => (
<div>
<button onclick={() => actions.getData()}>Get posts</button>
{state.posts.map(post => (
<div key={post.id}>
<h2><font color="#3AC1EF">{post.title}</font></h2>
<p>{post.body}</p>
</div>
))}
</div>
);
app(state, actions, view, document.querySelector("#app"));
?Svelte
<div>
<button on:click="getData()">Get posts</button>
{#each posts as {title, body}}
<div>
<h2><font color="#3AC1EF">{title}</font></h2>
<p>{body}</p>
</div>
{/each}
</div>
<script>
export default {
methods: {
getData() {
fetch('https://jsonplaceholder.typicode.com/posts')
.then(res => res.json())
.then(posts => this.set({ posts }));
}
}
};
</script>
> Рабочий пример.
?Анализ
В отличие от JSX, который, как под копирку, применяется во всех 3-х фреймворках из оригинального сравнения, и по сути расширяет javascript код html-подобным синтаксисом, Svelte использует более привычные возможности — внедрение js и css кода в html с помощью тегов <script> и <style>.
Скрипт компонента экспортирует простой JS объект, разделенный на секции. В секции methods описываются методы компонента, которые могут быть использованы через инстанс компонента и в обработчиках событий. Так, при нажатии на кнопку, вызывается метод getData(), внутри которого запрашиваются данные и по завершению операции, данные просто устанавливаются в стейт компонента и сразу же отрисовываются в шаблоне.
Обратите внимание, на использование деструктуризации объекта публикации (post) на каждом шаге итерации списка публикаций:
{#each posts as {title, body}}
Этот трюк позволяет избежать избыточности в шаблонах типа {post.title} и визуально упростить шаблоны, используя более короткую запись {title}.
Пример №3: компонент элемента списка для To-Do-приложения
React (функциональный стиль)
function TodoItem(props) {
return (
<li class={props.done ? "done" : ""} onclick={() => props.toggle(props.id)}>
{props.value}
</li>
);
}
React
class TodoItem extends React.Component {
render () {
return (
<li class={this.props.done ? "done" : ""} onclick={() => this.props.toggle(this.props.id)}>
{this.props.value}
</li>
);
}
}
Vue
var TodoItem = Vue.component("todoitem", {
props: ["id", "value", "done", "toggle"],
template:
'<li v-bind:class="{done : done}" v-on:click="toggle(id)">{{value}}</li>'
});
Hyperapp
const TodoItem = ({ id, value, done, toggle }) = (
<li class={done ? "done" : ""} onclick={() => toggle(id)}>
{value}
</li>
);
?Svelte
<li class="{done ? 'done' : ''}" on:click="set({done: !done})">{value}</li>
> Рабочий пример.
?Анализ
Тут все довольно банально. Выставляем css-класс в зависимости от значения done и меняем это значение на противоположное при клике на элемент списка.
Сравнение методов жизненного цикла компонентов
Disclaimer: С этого момента я решил опустить сравнение с Hyperapp, потому что иначе таблицы будут просто не читаемые.
| Событие |
React |
Vue |
Svelte |
| Инициализация |
constructor |
beforeCreate, created |
onstate |
| Монтирование |
componentDidMount |
beforeMount, mounted |
oncreate, onupdate |
| Обновление |
componentDidUpdate |
beforeUpdate, updated |
onstate, onupdate |
| Размонтирование |
componentWillUnmount |
— | ondestroy |
| Уничтожение |
— | beforeDestroy, destroyed |
— |
?Анализ
Svelte крайне минималистичен, в том числе в плане хуков жизненного цикла. Существует всего 4 хука:
- onstate — вызывается до создания компонента и каждое изменение стейта до обновления DOM.
- oncreate — вызывается момент создания компонента.
- onupdate — вызывается сразу после монтирования в DOM и каждое изменение стейта после обновления DOM.
- ondestroy — вызывается при уничтожении компонента и удаления из DOM.
Сравнение производительности фреймворков
Честно говоря, не знаю что тут комментировать. Сами по себе бенчмарки и способ их исполнения всегда вызывает много споров, поэтому не думаю что имеет смысл излишне заострять внимание.
Однако других данных у нас все равно нет.
?Работа с таблицами
?Загрузка, запуск, размеры кода
?Работа с памятью
?Анализ
Cудя по цифрам, Svelte довольно быстрый, «жрет» мало памяти (в том числе потому что не использует VirtualDOM), быстро запускается и имеет небольшие размеры.
Вообще, сказать что результаты бенчмарков этих 3-х фреймворков отличались кардинально, я не могу. Однако, только Svelte имеет исключительно «зеленый» столбик, т.е. он достаточно хорош сразу по всем показателям, а значит отлично сбалансирован и не имеет явных перекосов ни в скорости, ни в потреблении памяти и иных метриках. В общем, с ним смело можно начинать любой проект, от обычного веба, до мобильных устройств, Смарт ТВ и более экзотичных систем.
Итоги
Svelte — отличный инструмент для создания компонентов практически любых веб-приложений. Он такой же мощный как React и хотя пока имеет значительно меньшее сообщество, при этом требует меньше усилий для освоения. Он гибок, как Vue, при этом значительно более минималистичен и выверен, так как не пытается ухватиться сразу за все идеи современной веб-разработки.
Кроме того, он единственный использует концепцию исчезающих фреймворков. Иными словами он не имеет никакого специфического рантайма, кроме самого браузера.
Приложения на нем получаются быстрыми, не требовательными к ресурсам и маленькими в размере. Кроме того, Svelte может «бесшовно» использоваться в приложениях, написанных на других фреймворках, о чем я планирую написать в следующий раз.
Если вы впервые познакомились с этим замечательным фреймворком, возможно вам будет интересно прочитать и другие статьи о нем:
> Магически исчезающий JS фреймворк
> 1Kb autocomplete
> SvelteJS: Релиз второй версии
Если у вас остались вопросы по Svelte, вступайте в русскоязычный телеграм канал SvelteJS. Там вы всегда сможете задать вопрос и получить совет, узнать последние новости, а также просто приятно пообщаться. Будем вам рады!
Комментарии (78)
argonavtt
22.07.2018 09:27+1Есть идея создать бота для телеграмма, который будет писать что то вроде «React не фреймворк», «Vue — это самый лучший фреймворк», «Svelte — отличный инструмент для создания компонентов практически любых веб-приложений.» и т.д. Учитывая, что и дня не проходит без парочки front-end разработчиков которые бы спорили «какой фреймворк лучше», данный бот будет вроде как грушей для битья. Захотел поспорить на эту тему, пошёл в телеграмм, поколотил его своими «доводами».
YemSalat
22.07.2018 09:34+4В отличие от JSX, который, как под копирку, применяется во всех 3-х фреймворках из оригинального сравнения
То что в примере для Вью — так обычно никто не делает, у вас будет такой же single file component как в Svelte, и никакого метода render.
ПС
Вкусовщина конечно, но мне кажется с таким названием фрэймворку будет особенно трудно взлететь.vintage
22.07.2018 10:20+1Вкусовщина конечно, но мне кажется с таким названием фрэймворку будет особенно трудно взлететь.
Почему? И с каким названием было бы проще?
YemSalat
22.07.2018 15:44Почему?
Нe понятно как его правильно произносить, нe «слетает с языка» и вообще «нестандартное» слово для англоговорящих.
И с каким названием было бы проще?
Vue :D шутка
Я не маркетолог, но что-то подсказывает что название должно быть коротким, легко произносимым, и еще желательно звучать «круто» :)Xtray
22.07.2018 17:42+2Произносить «свелт» — несложно, вроде бы. Один слог, в отличие от «ре-акт», «ан-гу-ляр» :)
А, например, что Vue нужно читать как «вью» — не всем было понятно.YemSalat
23.07.2018 07:18-3Произносить «свелт» — несложно, вроде бы
Для того чтобы англосаксам было «несложно» должно быть как минимум «swelt», но уж никак не «svelte»
А, например, что Vue нужно читать как «вью» — не всем было понятно.
Уж точно понятнее чем как читать «Svelte»stalkerg
23.07.2018 08:55+2Для того чтобы англосаксам было «несложно» должно быть как минимум «swelt», но уж никак не «svelte»
почему? Слово же английское.
PaulMaly Автор
23.07.2018 12:21Не знаю, не слышал, значит не существует? ))))
svelte — стройный, изящный, гибкий
Уж точно понятнее чем как читать «Svelte»
Мне вот интересно, как несуществующее в словаре слово (vue), похожее по звучанию на существующее слово (view), может быть понятнее чем существующее в словаре и известное слово (svelte)? Понимаю что это субъективное мнение, но все же?
И кстати, Vue раньше читали, как «вуе», а не как «вью». Где-то даже был пост где один из евангелистов, может даже сам Эван, писал как правильно читать.
PaulMaly Автор
22.07.2018 11:52+1То что в примере для Вью — так обычно никто не делает, у вас будет такой же single file component как в Svelte, и никакого метода render.
Именно поэтому там есть словосочетание «из оригинального сравнения». Заметил, что многие тут апеллируют к несоответствию примеров их собственным предпочтениям. Господа, какое это имеет отношение к данной статье? Я же не могу менять примеры из оригинальной. Сам пишу на Vue и хорошо представляю, как можно написать, но если вы не согласны с примерами, что ж, быть может вам тоже написать ответную статью? Это будет как минимум интересно.
Вкусовщина конечно, но мне кажется с таким названием фрэймворку будет особенно трудно взлететь.
Сложно сказать, что вы имеете ввиду, но в целом да, слово не избитое. Думаю у автора — Рича Харриса, есть некоторая любовь к названием подтекстом. Его предыдущий фреймворк RactiveJS содержит отсылку к книге Neal Stephenson'а «The Diamond Age: Or, A Young Lady's Illustrated Primer», а именно сокращение от «interactive». Это конечно прикольно, но созвучность названия с, например, Reactive, вызывает путаницу до сих пор.
Правда Vue имеет примерно тот же изъян, потому как читается и слышится как View. Один React не имеет такой проблемы, хотя не у всех есть миллионы баксов, чтобы выкупить себе права на имя.YemSalat
22.07.2018 15:40Именно поэтому там есть словосочетание «из оригинального сравнения».
Оно может и так, но вывод следует все-равно в стиле «видите везде нужен jsx, а в Svetle только html» хотя во Вью по факту вам тоже нe нужен jsx.
Писать статью только для того чтобы показать очевидный факт корявости примеров из оригинального сравнения — может в какой-то степени и интересно, но на мой взгляд — не самая благодарная задача.
Правда Vue имеет примерно тот же изъян, потому как читается и слышится как View
Мне кажется это by design :)PaulMaly Автор
22.07.2018 23:35Оно может и так, но вывод следует все-равно в стиле «видите везде нужен jsx, а в Svetle только html» хотя во Вью по факту вам тоже нe нужен jsx.
Я нигде не писал что он нужен, перечитайте еще раз. Там написано, что JSX используется в примерах из оригинальной статьи для всех 3-х фреймворков. Далее идет реверанс в сторону JSX и того что это расширение JS с помощью HTML-like, а Svelte наоборот идет от HTML и расширяет его JS, что в общем-то уже в него заложено.
По поводу Vue, сорри, но там вообще похватали отовсюду. Там и шаблоны, и SFC, и JSX с render-функциями, и angular-like классы c декораторами. И что? Каждый пишет как хочет.
Писать статью только для того чтобы показать очевидный факт корявости примеров из оригинального сравнения — может в какой-то степени и интересно, но на мой взгляд — не самая благодарная задача.
Я ни слова не сказал про примеры из оригинальной статьи. Добавил сюда, потому что это удобнее для читателей. Типа сравнение все же. Не мое дело критиковать то, как эти примеры написаны. Статью писал не для этого, а чтобы расширить кругозор читателей примерами на Svelte, о чем написано в преамбуле.
Мне кажется это by design :)
Старнный ход. Многие до сих пор гуглят View, если в усной речи сказать «мы используем вью в своих проектах». Каждый раз, когда такое произношу и не уверен, что человек знаком с ним, приходится обращать внимание на написание.
YemSalat
23.07.2018 07:31-2По поводу Vue, сорри, но там вообще похватали отовсюду. Там и шаблоны, и SFC, и JSX с render-функциями, и angular-like классы c декораторами. И что? Каждый пишет как хочет.
Да нифига, по своему опыту, во всех проектах пишут в стиле в котором vue-cli задает изначальную структуру (т.е. почти у всех single file components и все такое)
Я ни слова не сказал про примеры из оригинальной статьи. Добавил сюда, потому что это удобнее для читателей. Типа сравнение все же. Не мое дело критиковать то, как эти примеры написаны
Ну, судя по количеству комментариев на этот счет — возможно вы все-таки не совсем правы? Все понимают что «я не я и собака не моя», но все же для корректного сравнения нужны корректные примеры.
Старнный ход. Многие до сих пор гуглят View, если в усной речи сказать «мы используем вью в своих проектах». Каждый раз, когда такое произношу и не уверен, что человек знаком с ним, приходится обращать внимание на написание.
Ну да, такой вот ход. Со Svelte у вас будет такая же история, только когда объясните как оно пишется — все-равно будет не понятно как оно читается.PaulMaly Автор
24.07.2018 00:12Да нифига, по своему опыту, во всех проектах пишут в стиле в котором vue-cli задает изначальную структуру (т.е. почти у всех single file components и все такое)
У всех или нет, не знаю. Мне тоже SFC в Vue нравится, хотя, мы на нем начали писать еще тогда, когда такого формата не было. Поэтому большая часть проекто на конструкторах.
Я любом случае, у меня нет задачи править чужие примеры.
Ну, судя по количеству комментариев на этот счет — возможно вы все-таки не совсем правы? Все понимают что «я не я и собака не моя», но все же для корректного сравнения нужны корректные примеры.
Это ответная статья, на другую статью, которая кстати даже перевод, а автор вообще англоговорящий. И при этом вы требуете от меня менять примеры
Опять же, чтобы говорить, что «так обычно не делают» надо иметь какую-то статистику. У меня ее нет. Примеры рабочие и «не правильные» они только для вашего эстетического восприятия. Поэтому я вполне могу предположить, что для автора статьи — это наиболее правильная реализация. Я же в свою очередь к статье никакого отношения не имею, поэтому и менять ничего не должен.
Со Svelte у вас будет такая же история, только когда объясните как оно пишется — все-равно будет не понятно как оно читается.
Вы издеваетесь? Это обычное английское слово, если вы его не знаете и не знаете, как оно пишется, то это, пожалуй, ваша проблема.
JSmitty
22.07.2018 10:10+2Про Vue примеры некорректные, для столь простого кода никто не будет писать рендер-функции. Образец идиоматического кода для первого примера тут, про второй вам уже сказали, шаблон был бы такой:
<template> <div> <button @click="getData">Get posts</button> <div v-for="post in posts" :key="post.id"> <h2>{post.title}</h2> <p>{post.body}</p> </div> </div> </template> <style scoped> h2 { color: #3AC1EF; } </style>
И для третьего примера шаблон такой:
<li :class="{done : done}" @click="toggle(id)">{{value}}</li>
И в svelte у вас пропсы вообще не описаны — непонятно, должно ли описание быть, и как должна IDE подсказки делать при использовании компонента.
А вообще интересно, расскажите, как там с отладкой дело обстоит? Дев тулы? Стейт менеджмент? Роутинг?PaulMaly Автор
22.07.2018 12:41+1Про Vue примеры некорректные,
Я то что могу сделать? Выше про это уже отвечал. Примеры не мои и менять я их не могу.
И в svelte у вас пропсы вообще не описаны — непонятно, должно ли описание быть, и как должна IDE подсказки делать при использовании компонента.
Так как в Svelte нет патчинга геттеров/сеттеров, как в Vue, реактивные данные могут создаваться без первоначально описания в любой момент времени. Однако согласен с тем, что хорошая практика иметь некое описание данных компонента и значения по-умолчанию. Делается это примерно также как в Vue, хотя может наборот, в Vue как в Svelte (мы же все знаем, что изначально Vue — это клон Ractive, а Svelte — это сводный брат Ractive по папиной линии?):
export default { data() { return { count: 0 } } };
Но повторяю, это не является обязательным. Рабочие примеры я привел.
PaulMaly Автор
22.07.2018 12:59+1Пропустил последний вопрос.
А вообще интересно, расскажите, как там с отладкой дело обстоит? Дев тулы? Стейт менеджмент? Роутинг?
Что конкретно по поводу отладки вас интересует? Хром devtools есть, sourcemap есть.
Для стейт-менеджмента есть встроенный стейт компонентов, а также супер простая и удобная реализация глобального стейта — Store с иерархическим наследованием стора в рамках одной иерархии, идущая вместе со Svelte. Он сильно отличается от Redux/Vuex в сторону упрощения и призван прежде всего шарить стейт между компонентами и удобно им пользоваться. Нужен Redux — используйте, многие так делают. Можно даже использовать Redux Dev Tools со Svelte Store с помощью svelte-dev-store, но сам я не пользуюсь.
Для роутинга можно использовать что угодно, это же прежде всего UI либа, но и интегрированных решений полно.
vintage
22.07.2018 10:12+2Создание компонента из всего одной строчки выглядит круто, но:
1. Возможность использования переменных без объявления приводит к тому, что ни статическая, ни даже динамическая типизация нам не помощник. А для подстраховки придётся писать больше тестов вида «а не опечатался ли я в таком-то выражении».
2. Одна строчка ровно до тех пор, пока внутри не используется какой-либо иной компонент, и тогда появляется скрипт с портянкой импортов и реэкспортов.
3. Та же беда, что и в Ангуляре — компонент сначала меняет своё состояние, а потом через биндинги оно начинает подниматься. То есть временно приложение находится в неконсистентном состоянии, что приводит к различным багам.
4. Ну и возможность писать произвольный яваскрипт в шаблоне — скорее вредная возможность, чем полезная. Вот как, например, эти шаблоны тестировать?PaulMaly Автор
22.07.2018 13:271. Возможность использования переменных без объявления приводит к тому, что ни статическая, ни даже динамическая типизация нам не помощник. А для подстраховки придётся писать больше тестов вида «а не опечатался ли я в таком-то выражении».
И вы туда же, со своими опечатками))) Будто это самая частая причина ошибок. Не знаю как у вас, но у меня проблемы с типами значительно чаще в рантайме происходят, особенно с внешними данными, чем из-за опечаток.
Если вам нужно объявить переменные и их значения по-умолчанию, вы также можете это сделать:
export default { data() { return { count: 0 } } };
Опять же, вы же понимаете, что в Svelte физически не может быть необъявленных переменных? Могут быть лишь объявленные переменные без первоначального значения, т.е. undefined.
2. Одна строчка ровно до тех пор, пока внутри не используется какой-либо иной компонент, и тогда появляется скрипт с портянкой импортов и реэкспортов.
А что за цель такая — писать компонент в одну строчку? Вы к этому стремитесь?
Не знаю в чем портянка, но ES6 модули, которые используются в Svelte — это как бы стандарт уже, так что все вопросы к комитетам. Однако есть даже шорткат для этого:
<script> // базовый вариант с ES6 импортом import Nested from './Nested.html'; export default { components: { Nested, NestedShort: './NestedShort.html' // укороченный вариант } }; </script>
3. Та же беда, что и в Ангуляре — компонент сначала меняет своё состояние, а потом через биндинги оно начинает подниматься. То есть временно приложение находится в неконсистентном состоянии, что приводит к различным багам.
Хорошо хоть в $mol таких проблем нет, да? Жаль никто об этом не знает…
Но если серьезно, вполне стабильно работает и особых проблем лично я не наблюдаю. Все же в Ангуляре эта проблема лишь усугубляла иные архитектурные огрехи.
Опять же, если боитесь этого, всегда можно отказаться от 2way биндингов и использовать «props down, events up», благо в Svelte — это очень удобно. Отключить 2way можно даже на уровне компилятора: bind: false.
4. Ну и возможность писать произвольный яваскрипт в шаблоне — скорее вредная возможность, чем полезная. Вот как, например, эти шаблоны тестировать?
Вредная возможность — не пользуйтесь. Выносите все в методы и хелперы и тестируйте их как обычные функции.
Кстати, по поводу тестов, давно идут разговоры о том, чтобы тесты были интегрированы прямо в компоненты. Если это будет сделано, то будет просто бомба! Self-tested components! ))))))
jeron-diovis
24.07.2018 00:13Объясните мне про Svelte. «Магически исчезающий фреймворк».
Раз он «исчезает», стало быть, он встраивает в код какие-то инлайновые хелперы, которые будут делать его работу. Как babel без плагина transform-runtime.
Раз он их встраивает, то вопрос: как скоро размер этого встраиваемого кода превысит исходный размер фреймворка? Очевидно же, что на крупном проекте это рано или поздно случится. Это происходит скорее рано, или скорее поздно?
А если он не инлайном вставляет, а генерирует какой-нибудь модуль с реюзабельным инструментарием, то какой же он, к чёрту, «исчезающий»?
Я вот никак этого не пойму. Выглядит как полный пшик.
Кто пробовал, поделитесь впечатлениями, пожалуйста.PaulMaly Автор
24.07.2018 00:23Объясните мне про Svelte. «Магически исчезающий фреймворк».
В конце статьи есть ссылки на другие статьи по Svelte. Также можете почитать перевод статьи «Исчезающие фреймворки» где подробно описано в чем суть.
Раз он их встраивает, то вопрос: как скоро размер этого встраиваемого кода превысит исходный размер фреймворка? Очевидно же, что на крупном проекте это рано или поздно случится. Это происходит скорее рано, или скорее поздно?
В теории да, но это скорее всего произойдет на крупном приложении. Как правило такие приложения уже требуют code-splitting, которые работает лучше со Svelte, чем с классическими фреймворками, так как там даже самый маленький кусочек кода зависит от всего фреймворка. Так что предполагаю, что даже на крупных проектах такой подход будет давать определенные преимущества.
Из своего опыта могу резюмировать, что когда я заканчиваю писать приложение на Svelte код его меньше или сопоставим по размеру с кодом только лишь фреймворка (без кода приложения) со схожей функциональностью.
Не знаю, насколько для вас это репрезентативно, но могу дать ссылку на «A Real-World Comparison of Front-End Frameworks with Benchmarks.» — это бенчмарки, в том числе по размеру, после реализации проекта RealWorld на нескольких фреймворках. Как видите, Svelte вполне себе хорош.
А если он не инлайном вставляет, а генерирует какой-нибудь модуль с реюзабельным инструментарием, то какой же он, к чёрту, «исчезающий»?
Исчезающий он потому, что во-первых, нет никакого рантайма, который вам надо тянуть, — ваши компоненты stand-alone. Во-вторых, благодаря статическому анализу и генерации кода, в ваш бандл попадает только те хелперы, которые реально используются. Ничего лишнего, только код вашего приложения, а не все что нужно всем юзерам фреймворка. Из-за этого «feature cost» очень низкий.
При этом Svelte сам оптимизирует влючение хелперов в бандл, то есть если какие-то фичи используются в нескольких компонентах, они не будут загружены дважды.
bgnx
Вы забыли про одну ложку дегтя — в отличие от svelte jsx позволяет не выбрасывать типизацию и все три фрейворка могут использовать все удобства статической типизации легко подключив typescript или flow. А вот как подключить typescript или flow к svelte чтобы мне также как и во всех этих трех фреймворках редактор подсветил что я опечатался в шаблоне?
Поэтому хватить хейтить jsx — люди придумали хранить шаблоны внутри js не потому что им так красивше а чтобы получить возможность статически протипизировать выражения и обращения к данным на отсутствие опачаток и заодно получить удобный автокомплит. Например запись условий через вот эти &&, ||, ?:
про которые многие хейтеры jsx говорят как захламлением любимого им xml синтаксиса (где мол форматирование получше) придуманы не для красоты а для того чтобы typescript или flow смог проверить сужение nullable типа и валидность обращения после проверки и тоже самое касается вывода списка записывая через .map чтобы можно было проверить что элемент массива будет нужного типа вместе с проверкой всех возможных опечаток или удобным автокомплитом.
Как получить все эти удобства статической типизации со svelte?
bgnx
это был ответ на эту цитату
Voiddancer
А где вы, собсно, хейт увидели?
bgnx
это была отсылка к обсуждению синтаксиса svelte и jsx в предыдущих статьях
funca
jsx это не js. подсветка синтаксиса, автокомплит, проверка типов и т.п. для jsx не задаром. это заслуга инструментария, специально написанного для данного формата.
для svelte есть плагин к vscode с поддержкой автокомплита и typescript (они реализовали language server).
но вообще да, отсутствие качественных инструментов — основная проблема для большинства dsl, которая часто заставляет разработчиков отказываться от них и переходить на mainstream языки.
bgnx
Попробовал этот плагин — подсветка синтаксиса есть но ни автокомплита ни проверки на ошибки внутри выражения (
<h1>Hello {user.profile.emal}!</h1>) нет, но возможно это у меня что-то не завелось, у вас работает проверка выражений и автокомплит?Да, но jsx уже стал стандартом и у него нет никакого кастомного языка — достаточно распарсить js-выражение внутри скобок и передать статическому анализатору джаваскрипта.
А вот написание typescript-плагина кастомного языка описания шаблонов может быть не простым делом — недостаточно просто распарсить js выражение — нужно объяснить ему откуда берутся новые переменные как например "todo" "i" в этом шаблоне
и также подсказать что нужно сузить определение для nullable типа user.profile в этом случае
и в общем случае нужно учитывать все особенности кастомного синтаксиса и это при условии что плагины для тайпскрипта не ограничены в функциональности в том что они могут проверять. Плюс неясно насколько это будет замедлять работу — одно дело проверять js где все достаточно хорошо оптимизировано включая инкрементальную проверку при редактировании и совсем другое дело — при каждом вводе символа вызывать хуки для плагина который будет проверять все заново.
Но это тайпскрипт — для него еще можно написать плагин а для flow такой возможности нет и теряем всю аудиторию пользователей flow среди потенциальных пользователей svelte.
PaulMaly Автор
Краткий ответ на ваш комментарий из 2-х пунктов:
Focushift
В последнем ангуляре же как-то сделали проверку вычислений в html.
PaulMaly Автор
Все это лишь вопрос инструментов. Но работа маркетинга на лицо, поэтому последователи JSX свято верят, что это не просто еще один шаблонизатор))
vintage
Там форкнули Typescript Language Services. Ну и работает оно очень так себе.
PaulMaly Автор
Раскажите, пожалуйста, чем типизация одного DSL отличается от типизации другого? Или вы из тех, которые «JSX — это просто JS» ?? ))))) Намекаю, вам тут ниже писали про инструменты.
Typescript и Flow — это прежде всего статические анализаторы кода, Svelte — это тоже статический анализатор кода + компилятор из SFC в ванилу. Так зачем нам 2 статических анализатора?
В итоге, все DSL конструкции превращаются в обычный JS (не строковые шаблоны же, ей Богу), поэтому бравада с JSX вообще не понятна.
Далее, вы и многие тут, так говорите про опечатки, будто это самая частая и большая проблема разработки. По моему опыту баги связанные с опечатками фиксятся в момент девелопмента и даже не доходят до тестов. Да и вообще, в чем проблема с опечатками? Если вы опечатались вы увидите undefined, пойдете в компонент, где он произшел и поправите свою ошибку. Если же вам сложно понятно где это происходит, то, возможно, у вас есть более серьезная проблема в архитектуре, а не в том, что вы плохо печатаете.
Про типизацию мы обсуждаем одно и то же в комментариях к каждой статье. По моему опыту build-time типизация практически бесполезна, большинство проблем возникает в глубоком рантайме, где у вас никаких flow/typescript уже нет. Проблему с проверкой входящий данных вполне решаются ассерты.
Давайте просто остановимся на 3-х вещах:
mayorovp
Typescript и Flow — это еще и языки, которые понимает IDE. У Swelte есть плагины для всех IDE?
И каким таким образом Svelte может понять типы переданных на вход параметров без TS/Flow? Ответ: никаким, потому что в чистом JS нет никаких статических типов.
А по моему опыту большинство проблем можно решить именно в build-time.
stalkerg
После python как то не согласен с вами… сила статической типизации сильно приувеличенна. Даже в Си скорее попадёшь на что то другое. Вот в Java без этого трудно но там они сами создали проблему а потом её решают. (алгоритмы не при помощи ООП, а через ООП)
0xd34df00d
Судить о статической типизации по С и, пожалуй, даже Java действительно не стоит.
stalkerg
Я правильно понимаю что вы считаете Haskell образцом в этом смысле?
0xd34df00d
Нет, ведь Hask is not a category.
Хотя он, безусловно, ближе к образцам.
stalkerg
И всё же, вы можете нормально написать что вы думаете на этот счёт?
Почему Си не подходит для суждений о статической типизации и какой язык по вашему мнению подходит?
0xd34df00d
В С статическая типизация слабая (неявные преобразования, касты,
void*, вот это всё) и слабовыразительная (вы можете меньше инвариантов выразить в типах). По факту, всё, для чего она подходит — отличить число от указателя да функцию от числа. По-моему, вполне очевидно, что судить о всём спектре возможных систем типов по этому — так себе идея.Хаскель не является образцом, но вполне подходит. И я, кстати, вполне серьёзен был: например, присутствие в языке
undefinedиseqломает eta reduction, что, в принципе, является одним из проявлений отсутствия категориальной структуры. В хаскеле никодга не будет totality checker'а, поэтому даже когда через несколько лет туда завезут зависимые типы, всю полную их мощь раскрыть не удастся. И, собственно, сейчас зависимых типов там нет, поэтому приходится обмазываться синглтонами,PolyKinds,TypeInTypeи прочими костылями, чтобы выразить банальные инварианты, которые в языках с завтипами выражаются только так.За образец из имеющихся языков можно взять какую-нибудь агду или идрис.
stalkerg
Как бы да, но всё же сильная и слабая типизация это немного отдельная тема. И мы тут по сути обсуждаем только статическую типизацию т.е. время связывания переменной.
ЗЫ а так к примеру в питоне сильная типизация но динамическая. :)
PaulMaly Автор
Возможно, зато их понимают не все программисты. Еще раз, Svelte — это о ES6 и его возможностях, а значение статической типизации сильно преувеличено.
Не знаю, у меня IDE поддерживает и Javascript, и CSS, и HTML, а что еще что-то надо? Если понадобиться, то плагин написать это не проблема. И уж точно это не проблема Svelte, а лишь инструментария, который, конечно же, пока не такой богатый как у более популярных фреймворках.
В чем проблема для Svelte добавить свои описательные средства для JS и на их основе понимать типы? Говорю же, статический анализатор уже встроен, а на его основе можно сделать что угодно. Другое дело, что сейчас этого нет, потому что нет особого запроса от сообщества.
Спорить с этим бесполезно, но на мой взгляд проблемы, которые могут быть решены путем статического анализа, по определению не могут являться действительно серьезными проблемами, иначе бы мы давно уже решили все проблемы в мире. К тому же вариативность проблем в рантайме по определению выше.
mayorovp
Пока что я наблюдаю недооцененность статической типизации.
Ключевое слово — "свои". В этом и проблема: программисту их нужно будет отдельно поддерживать.
PaulMaly Автор
Интересно, а какой у вас бекграунд, что вы так сильно чуствуете необходимость в статической типизации на клиенте? У меня C/C++ около 5 лет и честно говоря проблем с типами в JS практически не ощущаю, хотя первое время было конечно не привычно. Конечно для больших проектов, пожалуй, смысл есть, но для средних и малых, отнюдь.
Какому программисту? Можете немного раскрыть мысль, чтобы я был уверен, что вас правильно понял?
0xd34df00d
Я, конечно, не mayorovp, но я тоже чувствую необходимость в статической типизации. Мой бекграунд — лет 15 плюсов и лет 7 хаскеля.
Никогда не понимал, кстати, что за язык такой — C/C++.
PaulMaly Автор
Ваше право конечно. Знаю многих людей, которые пришли также из строго-типизированных языков и хотят типы в JS, знаю тех, кто пришел и не хочет. Знаю даже таких, которые никогда с такими типами не писали и JS — это чуть ли не первый их язык, но тоже хотят типы.
Возможно именно из-за того, что первые заходят в статьи по JS и начинают на полном серьезе требовать наличие TS во всех JS инструментах, будто бы это статья про TS или TS — это уже де-факто стандарт JS. Но все это не так.
TS — не стандарт, стандарт это ES и в нем типов нет, сорри. Если лично вам это не устраивает, ок, я вас не виню. Я вообще считаю что переходящим со строго-типизированных языков, да еще с классическим ООП, лучше всего подойдет Angular 2+ для фронтенда. Очень хороший инструмент для любителей всего этого, пользуйтесь. Там вам и TS, и классы и кучу тулзов из коробки.
Не понимаю зачем только заходить в комменты к JS статья и писать там о тех вещах, которые нужны прям скажем не всем (реверанс не в вашу конкретно сторону)?
mayorovp
Вот только отсутствие статической типизации как раз и переводит Svelte в категорию «подходит не всем». Почему вы отказываетесь это признать?
PaulMaly Автор
А вы знаете интсрумент который подходит всем? Серьезно? ))) Я не знаю, так что с интересом узнаю от вас!
Разве кто-то в статье или комментариях говорил, что Svelte подходит всем? Я так сказать не могу, потому что я не все, и потому что не занимаюсь всеми проектами. С уверенностью могу сказать ли то, что Svelte хорошо подходит для маленьких и средних веб-проектов, веб-виджетов, stand-alone UI компонентов, а также html5 мобильных приложений и даже Smart TV приложений. Это то, что лично я на нем разрабатывал.
Мое личное имхо, в таких проектах он очень хорош. Возможно даже лучше, чем React и Vue, хотя утверждать этого не буду, потому что у оных также есть свои плюсы.
mayorovp
Да, и это были вы: https://habr.com/post/417747/#comment_18907631
PaulMaly Автор
Чтобы не быть голословным, могли бы вы скопировать точную цитату, пожалуйста? Комметрий на который вы дали ссылку, слишком большой, чтобы понять ваши намеки.
И я все еще жду от вас фреймворк, который подходит всем. Может и мне подойдет.
mayorovp
В том комментарии вы начали спорить вот с этой цитатой:
Так все-таки, есть у Svelte эта ложка дегтя (минус) или нет?
Если есть, то я не понимаю почему вы вообще начали этот спор. Если у него минусов нет — значит, по вашему мнению, Svelte подходит всем.
PaulMaly Автор
Во-первых, это не значит, что я считаю, что Svelte подходит для всех. Я этого никогда не писал и не утверждаю сейчас.
Во-вторых, я спорил с тем, что Svelte выбрасывает типизацию и написал, что он сам может это делать, если это будет нужно сообществу. Также то, что уже сейчас можно сделать предпроцессор, которые будет решать часть этих проблем.
Поэтому да, я не согласен конкретно с этим минусом, но это не значит что я утверждаю, что он подходит всем.
Например, если бы вы написали, что к минусам Svelte можно отнести является отсутствие возможности шарить код между компонентами, путем наследования или миксинов, то я бы с вами согласился. И хотя я понимаю, почему так сделано и не раз слышал доводы автора, мне все равно иногда хочется пропатчить конструктор или отнаследоваться от общего класса. Ситуацию частично спасает глубоко интегрированный в иерархию компонентов Svetle Store, через который можно делать подобные вещи.
Вы бинес-логику также пишете? Тогда понимаю почему вам нужен TS. В данном случае, языком кода это выглядело бы так:
Только если я не согласен с одним описанным недостатоком, это вовсе не означает, что я считаю что их нет совсем.
И кстати, так и не узнал от вас фреймворк, который подходит всем.
stalkerg
Мне статическая типизация не подходит к примеру. :)
mayorovp
И что? Суть в том, что если Svelte не поддерживает статическую типизацию — его нельзя полноценно использовать в проекте где статическая типизация используется.
А если Svelte поддерживает статическую типизацию — его можно использовать где угодно. Или тут кто-то подумал что я предлагаю статическую типизацию сделать обязательной?
vintage
Почему не подходит?
0xd34df00d
Исключительно субъективная аналогия вот, но всё же.
Вот представьте себе, топите вы за архитектуру, паттерны, что кода, что методов разработки, MVC там, TDD, я не знаю, что там ещё бывает. И приходит к вам собеседник и говорит, что это всё, конечно, круто, но нужно далеко не всегда, и вот у него в проектах и без этого всё работает, и вообще ХХивП-дривен-девелопмент вполне норм.
Да, рациональное зерно в этом есть, да, не все проекты не во всех условиях вообще рассматривают поддерживаемость и прочее как один из оптимизационных критериев, и в проектах на 100 строк все эти MVC и TDD, наверное, не нужны.
Что вы ему скажете?
faiwer
Мне кажется, что вы только что приравняли
динамическую типизациюкХХивП. Наверное ничего не надо говорить ему в ответ, чтобы кормить тролля :)stalkerg
К слову о том почему вредны или неподходят TDD и MVC есть много статей, не нужно верить всегда маркетологам от ИТ.
mayorovp
Какому-нибудь. Ведь гипотетические "свои описательные средства" Swelte кто-то должен сначала использовать чтобы описать входные для Swelte данные, не само же по себе описание возьмется?
PaulMaly Автор
А что TS никто не описывал? Или Flow? Они что всегда были? Никто их не учил? В рождения вы их знали? В React что нет PropTypes? В Vue нет собственного синтаксиса типов для пропсов? Это никто не придумал и не поддерживает?
Только в отличии от них, Svelte еще и статический анализатор, а значит может сделать встроенный инструмент, который будет идеально ложиться на сам Svelte и его подходы.
Зачем ему сбоку лепить еще один статический анализатор, чтобы получить что? Опять же, если прям очень надо, то можно написать свой предпроцессор для Svelte и там прикрутить хоть TS, хоть Flow. Не уверен, может это уже и сделано, но я не видел. Если нет, значит видимо в сообществе Svelte пока это никому не надо. Это плохо? Имхо, нет.
Далее, никто вам не мешает использовать TS в импортируемых в Svelte компоненты модулях и там держать всю бизнес-логику. Это даже архитектурно будет более правильно.
mayorovp
Если программа пишется на TS — да, информация о типах TS оказывается доступна без дополнительных телодвижений. Ее можно вытащить через API транслятора или из файла с тайпингами.
Да без проблем. На самом деле, можно поступить даже проще: взять тот код который генерирует Svelte и с минимальными модификациями отдать на вход компилятору TS. Но это никак не приблизит к появлению контекстных подсказок в IDE.
Само собой, я изначально предполагал что так и будет делаться. Но меня интересует не только бизнес-логика, но и сам шаблон. В котором всегда будет оставаться что-то JS-подобное, иначе зачем он вообще нужен.
mayorovp
Кстати о бакграунде. Каждый раз когда кто-то говорит что статическая типизация не нужна, а опечатки легко исправляются — я вспоминаю один и тот же проект.
Проект на Sharepoint. Билд+деплой — 5 минут. 5 минут на исправление каждой опечатки…
PaulMaly Автор
Я больше года работал над легаси-проектом на плюсах, которому было лет 10, а в багтрекере было несколько тысяч ошибок, а кол-во строк кода я даже не пытался оценивать.
Так вот там все примитивные ошибки давно были исправлены, остались только edge-cases и ошибки глубокого рантайма, которые мы и отлавливали. Поэтому когда кто-то пишет мне про проблемы с опечатками, ничего кроме улыбки у меня это не вызывает.)))
mayorovp
На этапе сопровождения — да, так и есть. Но у нас-то была активная разработка...
PaulMaly Автор
А что от активность разработки как-то снижает кол-во сложных сценариев и ошибок в рантайме и увеличивает кол-во опечаток?
Не знаю почему вы так много опечатываетесь, но мои компоненты Svelte, как правило, содержат до 50 строк кода вместе с шаблонами, а значит легко просматриваются. Также очень легко тестируются, так как не смотря на SFC на выходе это обычный JS конструктор.
mayorovp
Активность разработки просто увеличивает количество опечаток. А опечатка штука такая — пока ее не исправишь, к сложным ошибкам приступить не получается.
И да, если все компоненты по 50 строк кода — это, в реалиях того проекта, лишь означает что компоненты появляются пачками по 20 штук. Что же до легкости тестирования — удачи в условиях пяти минутной задержки перед запуском :-)
0xd34df00d
Ну, когда после глубокого рефакторинга и победы ругани тайпчекера у вас все тесты зелёные сразу — это тоже вызывает очень много положительных эмоций. В частности, оттого, какие именно тесты можно писать, а где можно не реализовывать проверку частных случаев того, что ловится тайпчекером.
YemSalat
1) Typescript/Flow — это тоже по сути ES6
2) Значение статической типизации в самодокументируемом коде, подсказках в иде, и в том что у вас не будет ситуаций типа
> «Если вы опечатались вы увидите undefined, пойдете в компонент, где он произшел и поправите свою ошибку. „
Вы сразу видите проблему когда еще даже не допечатали “корявую» строку
У нас и так уже есть два основных «статических анализатора», и то проблема — какой выбрать. Нафига нам еще один??
PaulMaly Автор
TS код — это валидный код ES? Нет, тогда об чем речь?
Ок, а без нее, я увижу ее сразу как HMR перезагрузит мне страницу. Не уверен, что готов перевести всю свою команду на другой язык, чтобы на 3 секунды раньше замечать опечатки))
Потому что в Svelte он уже итак есть, так как является основой подхода, который Svelte использует. Там этот анализатор используется для многих других вещей, в том числе для генерации кода, его оптимизации и т.п. Svelte никак не является аналогом TS/Flow и решает совершенно другие задачи, но раз он решает эти задачи с помощью ± такого же статического анализатора, то я не понимаю зачем сбоку крутить еще один.
Как мне кажется, если сообщество Svelte придет к тому, что нужна статическая типизация, она будет реализована прямо внутри компилятора, без сторонних примочек, будет поддерживать DSL и вообще глубоко и удобно интегрироваться со Svelte. И это будет круто, потому что, на вкус и цвет, но для мне TS органично смотрится только в Angular 2+, а не в React и Vue, например. В React мне нравится как выглядит подход FP, а в Vue по большей части SFC.
mayorovp
Хм, а в чем "подход FP" конфликтует с TS?
swandir
DSL это достаточно широкое понятие, чтобы его распространить и на JXS, но пользы в этом немного. Как бы там ни было, JSX — не шаблон.
Разница тут в том, что, не смотря на расширение синтаксиса, JSX семантически равнозначен JavaScript. Он имеет достаточно простую рекурсивную структуру (элемент: имя, атрибуты и вложенные элементы), которая консистентно и однозначно соответствует выражениям JavaScript. Результат JSX-выражения идентичен результату JavaScript-выражения. Это значит, что на JSX распространяются все правила языка-хоста: JSX-выражение можно вычислить заранее, можно сохранить, можно передать как параметр или вернуть из функции, можно заменить равносильным JavaScript-выраженим как полностью, так и частично.
Конечно, поддержку расширения синтаксиса нужно ещё добавить в инструменты, но это совсем не то же самое, что добавить поддержку языка со своей собственной семантикой — они вообще скорее всего будут несовместимы.
Семантику шаблона, раз он компилируется в JavaScript, можно свести к семантике JavaScript. Однако это не то же самое что иметь равносильную семантику. Приведение семантики не является явным, что не позволяет судить о шаблоне в терминах языка-хоста. На шаблон не распространяются языковые средства JavaScript. Можно спорить о нужности этих средств, но факта оно не меняет.
Вопрос нужности/достаточности статической типизации в JavaScript неоднозначен, однако отрицать её преимущества смысла нет. В конце концов это хотя бы просто инлайн-документация, которая проверяется компилятором, и которую понимают IDE.
Также у статической типизации есть побочный эффект. Статически типизируемый интерфейс — это явный интерфейс, с явным контрактом.
Ещё важным фактором эффективности статической типизации в JS является дружественность к ней интерфейсов библиотек. Если новые фреймворки будут занимать такую позицию, что поддерживать статическую типизацию ненужно, потому что она неэффективна, то это ведёт к замкнутому кругу.
Кстати говоря, "проблема опечаток" это в своей сути всё та же проблема явных, верифицируемых интерфейсов.
Насчёт того, что Svelte сам по себе статический анализатор. От статического анализатора требуется покрытие значимых сценариев использования и совместимость с экосистемой. Скажем, TypeScript может это обеспечить, насколько это возможно. От Svelte для этого потребуется по крайней мере сопоставимое количество работы, если допустить что это практически реализуемо. Svelte может ограничиться верификацией специфических для себя частей на манер PropTypes, но это только небольшая часть, и остаётся ещё проблема анализа внешнего к фреймворку кода.
stalkerg
Совершенно не понимаю такое отношение к этому посту, я его перечитал 5 раз и не понял где бы автор сказал что то не то. Последный абзац вряд ли мог вызвать такую реакцию т.к. там просто описано текущее состояние вещей.
Вполне возможно кого то задело что то про JSX но вроде это и впрям DSL хоть и близкий к JS. Svelte то же к слову использует JS как есть внутри своих выражений кроме тех что начинаются на #.
Возможно кто то не согласен с мыслью что статическая типизация не настолько необходима? Это увы боюсь дело личного опыта и веры, в моём случае после более чем 10 лет с Python и JS проблем с опечатками не было, а если что то было то элементарно исправлялось и опять же тесты. (а вы пишете тесты?) Мне кажется, даже если вы не согласны с этой идеей то вы всё же должны признать что такая точка зрения есть.
Короче у Svelte (который написан на TS) всё отлично если вы не преверженец статической типизации.
YemSalat
Люди которые думают что статическая типизация — это про опечатки — не врубаются в статическую типизацию.
Для избегания опечаток в JavaScript'e есть «use strict»
Тесты мы все пишем (в мечтах), но дело не в этом, дело в уверенности в своем коде уже на этапе написания, в том что не надо держать все в голове. И еще в том что иде гораздо лучше «понимает» код и не надо так часто лезть в гугл.
stalkerg
Я надеюсь вы не про меня? т.к. я прекрасно понимаю что это такое и с чем едят. Опечатки это то что тут постоянно упоминали в первую очередь говоря о статической типизации.
Про IDE это хорошо… но лично я по большей части использовал просто редакторы типо Kate,Sublime,VS Code и хватало, даже для С++.
vintage
VS Code — IDE.