Отвечу на частый вопрос насчет сочетаемости svelte и typescript — у нас несколько проектов на typescript и svelte, 2 из них уже в продакшене.
В чем секрет? Нет, мы не используем костыли по приколачиванию typescript внутрь .svelte файлов. У нас просто не смешивается логика и UI. Мы пишем логику в .ts файлах, где она отлично типизируется, а в .svelte файлах у нас только декларативное описание компонента.
Сам svelte написан на typescript и очень хорошо типизирован, получше многого, что встречается на npm. Даже импортируя что-то из svelte/internal (там очень уж удобные абстракции для прямого взаимодействия с DOM, например в тех же экшенах) мы получаем отлично типизированные функции. Если сравнивать типизацию svelte с типизацией vue (проще выбросить и написать свою, ибо не знает даже о половине тех вещей, что есть в Vue) или react (неплохо, но много недочетов. Например почему SyntheticEvent будучи дженериком от EventTarget'а требует тайпгварда для event.target, чтоб воспользоваться методами, которые там гарантировано есть?)
Ну и немного о javascript и его надмножествах:
typescript является надмножеством javascript, это как javascript но с дополнительным синтаксисом для описания типов;
jsx является надмножеством javascript, это как javascript но с дополнительным синтаксисом для описания xml шаблонов;
svelte является надмножеством javascript и html, это как javascript и html но с дополнительным синтаксисом для описания реактивности и манипуляций с DOM.
Ни один из них, не является надмножеством другого… хотя нет, есть tsx, который является надмножеством typescript. И сообщество react должно быть благодарно тому, что у Microsoft так много работы с xml, а jsx оказался очень удобным для его построения, настолько, что они добавили его в свой язык. Не случись этого, в jsx до сих пор не было бы typescript.
Однофайловым компонентам vue и svelte повезло меньше, что впрочем не мешает использовать typescript за их пределами. Вы же не тянете логику внутрь компонента, где по идее должен быть только UI?
Вообще, по ощущениями от Svelte у многих дико бомбит — мне кажется меньше, чем при появлении Vue например
Парадокс Блаба в действии, я считаю. Люди привыкли жить в уютном теплом мирке любимой технологии и яростно сопротивляются подсознательным мыслям «А вдруг действительно окажется лучше и все перейдут на него, а я останусь не удел… Надо переучиваться? Но я боюсь переучиваться. Нет! Нет! И еще раз нет! Я не настолько хорош, чтоб освоить новый фреймворк/язык».
Svelte другой, а люди боятся нового по своей природе, вот и все.
Из наследия после одной не очень известной аутсорс галеры, которую послали нафиг, ибо проект стало поддерживать нереально дорого, и наняли меня «спасать ситуацию».
Про банальщину вроде функций вида
if(condition) return true;
else return false;
даже говорить влом…
Но вот такие перлы реально убивают до сих пор:
В первый месяц у меня еще была возможность спросить «зачем?». На что я получил закономерный ответ: «ну чтоб дожидалось запросов в тех функциях». А на мое объяснение, что если не вернуть из колбэка промис, то ждать не будет, а у него ни колбэк, ни вызываемые функции ничего не возвращают, я услышал лишь «разве?».
Надеюсь он больше не будет так делать… Но человек реально верил в «магию» промисов в js и даже не догадывался, что это работает несколько иначе, чем он хотел.
А вот еще одинт финт, я нашел уже когда обратная связь оборвалась:
<div v-for="(item, i) of array" v-if="i === index">
...
</div>
Если кто не знает, это такой способ написать цикл for и if в шаблонах vue. И я бы мог списать это на то, что человек не понимает шаблонов и пишет как умеет… Но я увидел абсолютно аналогичную штуку в js коде:
let item;
for(let i = 0; i < array.length; i++) {
if(i === index) {
item = array[i];
}
}
Я так и не понял сокрального смысла сия кода, и почему нельзя было просто написать
const item = array[index];
Остается только предполагать, что у человека не было дома отопления, и он грелся таким образом от проца.
У меня отец информатику в школе преподает, как то ему тоже рассказывал, что предыдущие поколение разработчиков повсюду на оставляли подобных перлов, на что он мне спокойно ответил:
А так в школьных учебниках написано, ибо автору нужно показаь школьникам пример с if, а реальных примеров они придумать не могут
Единый подход есть:
У Вас по файлу на каждую сущность (будто в редаксе здорового человека не так?), из которых Вы экспортируете множество сторов, каждый стор содержит атомарное значение.
Разногласия разве могут быть в том, как хранить множество однотипных сущностей, как Readable<Entity[]> или как Readable[] ибо это реально зависит от задачи.
Тоже в целом касается в том числе и vuejs
У Vuex для этого есть модули, а то что не все их используют, отнюдь проблема не vue
И кстати, combineReducers никак не спасет меня от конфликта имен экшенов, в отличии от модулей vuex или нативных es модулей в случае свелта
А почему бы не скомпилировать rust библиотеку в static-lib? Насколько помню go прекрасно умеет с ними работать через тот же cgo. Только работать это будет быстрее и соберется все в единый бинарник.
Ну и так на заметку читающим, libembed.dylib — это мак специфично, на линуксе будет libembed.so, а на винде — libembed.dll
Роутеров хватает, на любой вкус и цвет. В реакте тоже нет единого роутера. А то что вью ограничивает меня только своим монстром, я бы скорее к минусам отнес.
Насчет редакса. У свелт есть управление состоянием из коробки. И ощущения от него просто прекрасные. Уже через месяц его использования я недоумевал, как я до этого мог пользоваться vuex, redux и mobx с их излишней сложностью. Но самое главное, сторы свелта — это всего лишь интерфейс (под который кстати неплохо вписываются обсерваблы), а значит Вы можете завернуть в него что угодно. И специально для любителей редакса — редакс уже завернули
Если дока изучается за 1 вечер — это не значит, что она слабая. Текущая дока покрывает 100% возможностей как фреймворка, так и его компилятора (со стороны обычного пользователя, но много ли народа идет пилить пулреквесты в используемые инструменты?).
В ангуляр встроить, что react, что vue большой проблемы нет, ибо ангуляр тоже работает с нативным DOM (на самом деле зависит от выбранного рендерера).
А вот встроить vue в react или наоборот — та еще боль. Лично решал проблему, когда vue виджет встроенный в приложение на реакт зависал — vue уходил в бесконечную рекурсию, из-за того что реакт примешал своей гадости в DOM, так еще и не догадался, что enumerable в таких случаях выключают.
Притом сейчас мигрирую проект с Vue на Svelte3 и реально нет никаких проблем, чтобы использовать из Vue компоненты Svelte и наоборот, со всеми пропсами и событиями (со слотами правда не заморачивался, ибо не надо)
Ограничений частично можно достичь с помощью некоторых плагинов eslint, не настолько идеально конечно, как в Elm/PureScript/ReasonML, но вполне достаточно, чтоб писать чистый код… С гарантиями чуть сложнее, хотя и их можно достичь с помощью некоторых библиотек.
Мне вполне удается писать вполне себе ФП код на JS/TS, и я может и не против пересесть на PureScript, вот только я с ним не расширю свою команду…
Вот написали Вы либу с надеждой на TypeScript, а я стал ее использовать в проекте без strictNullChecks или вообще с чистым JavaScript… а потом буду разбираться со стректрейсом, который полностью в node_modules из-за того, что какой-то умник не проверил на null понадеявшийся на «строгий» (нет!) компилятор…
И таких библиотек на npm в последнее время стало очень много…
Ну и в принципе легко добавляется в любой язык с дженериками.
Если мне пришел None — мне глубоко фиолетово откуда он пришел, ведь это вполне себе тоже результат вычислений, что результата нет. Option — это хорошая абстракция, чтоб не иметь головной боли с NullPointerException и не более.
Но я скорее предположу, что Ваша претензия к типу Result, но и тут проблем меньше.
Во-первых, в Rust четко разделены паники и ошибки как результат вычисления. Паники — это ошибки программиста, их почти никогда не ловят (хотя такая возможность есть, это крайний случай) и у них четкий стектрейс и дебажить их никаких проблем. Ошибки как результат вычисления — это штатная ситуация (сеть не доступна, файл не открылся), ее не нужно дебажить, ее нужно обрабатывать, ну или пробрасывать дальше, программисту чаще всего до лампочки, какой сискол там использовался под капотом, если его программа не смогла открыть файл из-за того, что юзер выдернул флешку.
Во-вторых, что бы пробросить ошибку, тип ошибки должен совпадать, а если моя функция возвращает Result<(), MyError>, а вызываемая Result<(), OtherError>, то чтоб пробросить его мне придется как то преобразовать OtherError к MyError, я могу сделать это на месте с помощью .map_err() или обобщенно, с помощью From/Into типажей, но сделать я это обязан, иначе моя программа просто не скомпилируется.
И это все резко отличает Rust/Ocaml/Haskell от языков с эксепшенами, где я мало того, что не вижу из сигнатуры, что там могут быть ошибки, так еще мне в одну кучу сыпят то, что я забыл написать if(x != null)
Хорошо, то оно хорошо, вот только компилятор меня не обязывает это сделать, мой псевдокод вполне себе компилируется, а в Rust/Haskell мне придется корректно извлечь результат из Result/Either и как-то среагировать на ошибку, иначе моя программа не скомпилируется
То есть программа остановится не в месте возникновения ошибки, а где-то в случайном месте программы, где решили привести коллекцию к массиву? Счастливой отладки, да.
Именно по этому в ФП языках не кидают исключений, а возвращают рантайм ошибку как результат вычислений, а для ошибок программиста есть паника, у которой будет адекватный стектрейс…
С другой стороны, псевдокод на C#, эквивалент которого вполне можно встретить в императивном коде:
class A
{
public void MethodA()
{
MethodB();
}
private void MethodB()
{
throw new Exception();
}
}
class B
{
public void MethodA()
{
MethodB(new A());
}
private void MethodB(A a)
{
try {
a.MethodA();
}
catch(Exception e) {
Logger.Error(e);
throw e;
}
}
}
Данная реализация как раз и появилась из-за того, что вариант lodash не устраивал. Ну и вообще в последнее время я избегаю lodash — он очень недружественный к ФП
В чем секрет? Нет, мы не используем костыли по приколачиванию typescript внутрь .svelte файлов. У нас просто не смешивается логика и UI. Мы пишем логику в .ts файлах, где она отлично типизируется, а в .svelte файлах у нас только декларативное описание компонента.
Сам svelte написан на typescript и очень хорошо типизирован, получше многого, что встречается на npm. Даже импортируя что-то из svelte/internal (там очень уж удобные абстракции для прямого взаимодействия с DOM, например в тех же экшенах) мы получаем отлично типизированные функции. Если сравнивать типизацию svelte с типизацией vue (проще выбросить и написать свою, ибо не знает даже о половине тех вещей, что есть в Vue) или react (неплохо, но много недочетов. Например почему SyntheticEvent будучи дженериком от EventTarget'а требует тайпгварда для event.target, чтоб воспользоваться методами, которые там гарантировано есть?)
Ну и немного о javascript и его надмножествах:
typescript является надмножеством javascript, это как javascript но с дополнительным синтаксисом для описания типов;
jsx является надмножеством javascript, это как javascript но с дополнительным синтаксисом для описания xml шаблонов;
svelte является надмножеством javascript и html, это как javascript и html но с дополнительным синтаксисом для описания реактивности и манипуляций с DOM.
Ни один из них, не является надмножеством другого… хотя нет, есть tsx, который является надмножеством typescript. И сообщество react должно быть благодарно тому, что у Microsoft так много работы с xml, а jsx оказался очень удобным для его построения, настолько, что они добавили его в свой язык. Не случись этого, в jsx до сих пор не было бы typescript.
Однофайловым компонентам vue и svelte повезло меньше, что впрочем не мешает использовать typescript за их пределами. Вы же не тянете логику внутрь компонента, где по идее должен быть только UI?
Парадокс Блаба в действии, я считаю. Люди привыкли жить в уютном теплом мирке любимой технологии и яростно сопротивляются подсознательным мыслям «А вдруг действительно окажется лучше и все перейдут на него, а я останусь не удел… Надо переучиваться? Но я боюсь переучиваться. Нет! Нет! И еще раз нет! Я не настолько хорош, чтоб освоить новый фреймворк/язык».
Svelte другой, а люди боятся нового по своей природе, вот и все.
Про банальщину вроде функций видадаже говорить влом…
Но вот такие перлы реально убивают до сих пор:В первый месяц у меня еще была возможность спросить «зачем?». На что я получил закономерный ответ: «ну чтоб дожидалось запросов в тех функциях». А на мое объяснение, что если не вернуть из колбэка промис, то ждать не будет, а у него ни колбэк, ни вызываемые функции ничего не возвращают, я услышал лишь «разве?».
Надеюсь он больше не будет так делать… Но человек реально верил в «магию» промисов в js и даже не догадывался, что это работает несколько иначе, чем он хотел.
А вот еще одинт финт, я нашел уже когда обратная связь оборвалась:
Если кто не знает, это такой способ написать цикл for и if в шаблонах vue. И я бы мог списать это на то, что человек не понимает шаблонов и пишет как умеет… Но я увидел абсолютно аналогичную штуку в js коде:Я так и не понял сокрального смысла сия кода, и почему нельзя было просто написать
Остается только предполагать, что у человека не было дома отопления, и он грелся таким образом от проца.
У Вас по файлу на каждую сущность (будто в редаксе здорового человека не так?), из которых Вы экспортируете множество сторов, каждый стор содержит атомарное значение.
Разногласия разве могут быть в том, как хранить множество однотипных сущностей, как Readable<Entity[]> или как Readable[] ибо это реально зависит от задачи.
У Vuex для этого есть модули, а то что не все их используют, отнюдь проблема не vue
И кстати, combineReducers никак не спасет меня от конфликта имен экшенов, в отличии от модулей vuex или нативных es модулей в случае свелта
Ну и так на заметку читающим, libembed.dylib — это мак специфично, на линуксе будет libembed.so, а на винде — libembed.dll
Насчет редакса. У свелт есть управление состоянием из коробки. И ощущения от него просто прекрасные. Уже через месяц его использования я недоумевал, как я до этого мог пользоваться vuex, redux и mobx с их излишней сложностью. Но самое главное, сторы свелта — это всего лишь интерфейс (под который кстати неплохо вписываются обсерваблы), а значит Вы можете завернуть в него что угодно. И специально для любителей редакса — редакс уже завернули
А вот встроить vue в react или наоборот — та еще боль. Лично решал проблему, когда vue виджет встроенный в приложение на реакт зависал — vue уходил в бесконечную рекурсию, из-за того что реакт примешал своей гадости в DOM, так еще и не догадался, что enumerable в таких случаях выключают.
Притом сейчас мигрирую проект с Vue на Svelte3 и реально нет никаких проблем, чтобы использовать из Vue компоненты Svelte и наоборот, со всеми пропсами и событиями (со слотами правда не заморачивался, ибо не надо)
Мне вполне удается писать вполне себе ФП код на JS/TS, и я может и не против пересесть на PureScript, вот только я с ним не расширю свою команду…
И таких библиотек на npm в последнее время стало очень много…
А можно пример такого добавления?
Но я скорее предположу, что Ваша претензия к типу Result, но и тут проблем меньше.
Во-первых, в Rust четко разделены паники и ошибки как результат вычисления. Паники — это ошибки программиста, их почти никогда не ловят (хотя такая возможность есть, это крайний случай) и у них четкий стектрейс и дебажить их никаких проблем. Ошибки как результат вычисления — это штатная ситуация (сеть не доступна, файл не открылся), ее не нужно дебажить, ее нужно обрабатывать, ну или пробрасывать дальше, программисту чаще всего до лампочки, какой сискол там использовался под капотом, если его программа не смогла открыть файл из-за того, что юзер выдернул флешку.
Во-вторых, что бы пробросить ошибку, тип ошибки должен совпадать, а если моя функция возвращает Result<(), MyError>, а вызываемая Result<(), OtherError>, то чтоб пробросить его мне придется как то преобразовать OtherError к MyError, я могу сделать это на месте с помощью .map_err() или обобщенно, с помощью From/Into типажей, но сделать я это обязан, иначе моя программа просто не скомпилируется.
И это все резко отличает Rust/Ocaml/Haskell от языков с эксепшенами, где я мало того, что не вижу из сигнатуры, что там могут быть ошибки, так еще мне в одну кучу сыпят то, что я забыл написать if(x != null)
С другой стороны, псевдокод на C#, эквивалент которого вполне можно встретить в императивном коде:Счастливой отладки