Комментарии 117
Уважаемые читатели! Что вы думаете о Svelte?
Последний раз, когда я захотел взять Svelte в прод (в конце 2019) — я пошел в дискорд, и за неделю чтения дискорда, особенно feed с гитхаба… расхотел. Брать в прод то, от чего регулярно отваливаются детали — идея крайне сомнительная.
Отличная производительность, улучшающая впечатления пользователей от работы с сайтами, созданными на Svelte.
Справедливости ради, если во времена Svelte v2 там и вправду можно было хвалиться производительностью, очень близкой к vanilla.js, то в v3 уже нет. Конечно, Svelte всё еще быстрее реакта, кто б сомневался. Но уже не настолько быстрая, как многие другие оптимизирующие перестройку DOM библиотеки.
Да, Svelte набирает популярность и он очень хорош, но есть ещё несколько графиков, которые показывают, что прекращать изучать React в данный момент не стоит.
www.npmtrends.com/@angular/core-vs-react-vs-vue-vs-svelte
www.youtube.com/watch?v=0cFoEPhv2II
А писать новую DTO, которая перечисляет все поля существующей, не хочу. Как автоматизировать?
Я чего-то не понимаю
В целом, да
Использование термина «строгая типизация» — опрометчивая идея.
Вы явно под этим понимаете «номинативная типизация», это разные вещи.
Если грубо, номинативная — это когда имя типа является его частью, а строгая, это когда компилятор не занимается автоматическими имплиситными кастами.
Теперь по вопросу.
я хочу примерно так:
// псевдокод
class A {
id: int
name: string
}
let dtoA = A.withMapping(id, (id) -> id.toString);
// и тут мне нужно, что бы типа dtoA
// выводился на стадии компиляции, как
class DtoA {
id: string
name: string
}
То-есть, я хочу и тайпчекинг(и в компайл тайме, и в рантайме), и модификацию типов данных «на лету», и без бойлерплейта с перечислением всех филдов.
В Java так не получится. А в typescript можно провернуть и не такое.
В целом, со всем моим уважением к возможностям Java и её инфраструктуры (многие из которых уникальные), мне очень не нравится по 100 раз перечислять одни и те же поля — ну это же явно автоматизируется теоретически.
class Base
{
// общие поля
}
class A extends Base
{
id: int;
}
class B extends Base
{
id: string;
}
И ещё 50 производных от неё струткур, которые требуются клиенту.
Типа там, здесь мне нужен юзер со списком его покупок, тут юзер с метаинформацией о посещениях, тут нужен он же со списком своих друзей и т.д.
На стороне сервера у меня есть сущность User, которая всё это опосредованно содержит.
Фигачить от неё 50 dto, каждая из которых наследует базовую дто с общими полями (хотя я сомневаюсь, что такие вообще будут) — это совсем не похоже на автоматизацию.
Кроме того, наследование подразумевает расширение, в то время как мне при создании DTO часто нужно сужение.
Короче, подход с наследование избавит меня от бойлерплейта в одном с половиной случае, так я ещё и заплачу за это лишним классом UserDtoBase.
А ломбок хорошо только тем, что лечит болезни джавы (через костыль с кодогенерацией и плагин к IDE), его трудно понимать как аргумент против ЯПов, у которых нет таких болезней
И тут вся проблема — кто то любит плодить одинаковый, зато явный код, кто-то выбирает автоматизацию, в обмен на снижение эксплиситности. Но в Java у тебя нет выбора.
Контексты задач разные, домены разные, в программировании очень редко можно сказать — всегда делай так, а не иначе. Поэтому я считаю инструменты, которые дают меньше пространства и выбора — отсталыми и неудобными.
При таком ландшафте я бы предпочёл не иметь в кодовой базе 50 DTOшек, которые во многом друг друга повторяют, и все являются отображением одного конкретного класса.
Но предпочли бы иметь 50 заклинаний вида:
let dtoA = A.withMapping(id, (id) -> id.toString);
вне dto в произвольных местах кода. Где логика?
Я могу их иметь где угодно
В том и суть, что все эти правила преобразования из А в Б могут быть действительно где угодно, размазанные по кодовой базе, и ответ на вопрос «каким образом получился данный конкретный выхлоп?» становится совсем не однозначным, поскольку нет никакого способа узнать всю цепочку метаморфоз произошедших с начальным объектом, кроме как прочитать код и найти все места, где с ним что-то делали.
Но, да бох с ним, хочется вам иметь возможность отстрелить себе ноги по самую шею — имеете полное право. Главное для меня тут в другом — это и были основные претензии к джаве и спрингу, на основании которых они были признаны вами «отсталыми»?
что все эти правила преобразования из А в Б могут быть действительно где угодно, размазанные по кодовой базе
Так же, как и ваши DTO которые вы можете складировать куда угодно, называть как угодно, и использовать как угодно. Половину из них вам может быть лень выделять в отдельные DTO, и вы обмажете их атрибутами мапинга — которые все кейсы покрыть не смогут. Это ещё усугубляется моментом, что класс в Java — это не данные, это данные+поведение, в кейсе с DTO мы используем его как дынные, что гарантируется только конвенциями, а не ЯПом.
Тут ещё момент с инстанцированием, код в стиле
var userDto = new UserDto(
user.getId(),
user.getName(),
user.getSome(),
....
);
которого в кодовой базе серьёзного проекта просто море — это кошмар.
В тайпскрипте это легко автоматизировать (очень легко).
Это ещё хорошо, если разработчик использует конструкторы для DTO, я встречал подходы в C#, когда все свойства делают с сеттерами, что бы костылить присваивание через рефлексию.
Помимо этого, есть претензии к Optional типу.
В Java нет юнионов, но при разработке они нужны — встроенный тип Optional тому подтверждение — это закостыленный с помощью контрактов юнион, который по сути ничего не гарантирует (да, он даёт варнинг, которых в большом проект могут быть тысячи). И даже если бы он работал как надо — реализация через контракты, это костыль.
Свой аналог типа-объединения без контрактов тоже не получиться сделать — например пытаться эмулировать его наследованием можно, но если он будет содержать дженерики (а кому нужны юнионы без дженериков?) — то он будет страшно неудобен в использовании.
Нет адекватной интерполяции строк.
Вести разработку в чём-то кроме идеи — невозможно, потому что половина проекта работает на кодогенерации
Отсутствие дженериков в рантайме в языке со статической, строгой номинативной типизацией — вызывает кучу вопросов. и добавляет кучу неудобств.
Подход в JPARepository, когда наследуешь интерфейс, пишешь в нём методы, а реализацию за тебя дописывают (я, если честно, не знаю. кто или что это делает) исходя из букв в названии метода — явно не от большого богатства системы типов сделан.
В целом, общая претензия такая — у ЯПа нищая, просто обездоленная система типов, которая не позволяет детально выразить даже самый простой домен.
Возможно в вашем случае можно использовать список объектов. С Java не знаком, поэтому псевдокод.
Class User {
List<Object> Entities = new List([
{value: object1, type: Friend},
{value: object2, type: Purchase}
]);
}
Или хранить поля списком:
Class User {
List<Object> Fields = new List([
{key: "Name", value: "username1", type: string},
{key: "FriendsCount", value: "12", type: int}
]);
}
А при отправке преобразовывать в string/json.
Покажу на втором примере:
class BaseField {
string Key;
};
class StringField extend BaseField {
string Value;
};
// может можно так сократить:
class Field<T> extend BaseField {
T Value;
};
Class User {
List<BaseField> Fields = new List([
new StringField("Name", "username1"),
new Field<int>("FriendsCount", 12),
]);
}
Можете, пожалуйста, показать OpenAPI документацию по этому ендпоинту? А то, мне сложно понять зачем всё это)
40:50 про скрывание аккардиона на gitlab — будет интересно узнать интересный момент в vue )
он сам описывал это на другой конфе — там проблема в state management по большей части (т.е. не самая центральная функциональность Vue): youtu.be/3tdfBMRq34o?t=2311
p.s. Ну и во Vue3 планируется кстати оптимизация т.к. tree diff будет сравниваться блоками а не по каждому элементу, это должно сократить время затрачиваемое на обновления компонентов, тут подробней: youtu.be/WLpLYhnGqPA?t=1794
гораздо сложнее заменить React в головах, когда уже поколение разработчиков выросло на JSX и понятия не имеет как работает реальный DOM
Шаблонизацию HTML в любом случае заменять не надо. Ну если только вы очень жаждете попереизобретать велосипеды.
А уж какая там именно шаблонизация, JSX или не JSX — не очень важно. В любом случае, JSX != React.
habr.com/ru/post/462705/#comment_20485003
habr.com/ru/post/459706/#comment_20395539
Также интересный момент: habr.com/ru/company/yandex/blog/486146
Клиент мобильной web-версии Маркета мы перевели на React + Redux. Почему не на Vue.js? Мы устроили соревнование между двумя фреймворками. Две команды энтузиастов портировали страницу поисковой выдачи Маркета на обе технологии. По итогам внутренних бенчмарков и тестов React в нашем проекте показал себя лучше.
у Vue плоская система реактивности
Мне даже пришлось полностью переписывать 1 проект на React + Redux когда я это выяснил. Как оно вообще живёт с такой системой подписок computed -> computed за счёт копирования всех зависимостей на каждый чих? Был очень неприятно удивлён этому, думая, что оно работает как в KnockoutJS.
AngularJS
Несколько типов аргументов ('=', '@', '>', '&') у директив. Очень странное именование методов жизненного цикла (contoller, link, и функция, которую возвращает link) В 1.5 они тупо взяли именование из реакта и стало сильно лучше. Различные способы вставки директив в шаблон (элемент, класс, атрибут и даже комментарий), в компонентах в 1.5 в итоге все равно оставили только элемент. Неочевидная и медленно работающая система реактивности требующая оберток над всем асинхронным браузерным API, а заодно и над любой асинхронной библиотекой. Такое впечатление, что авторы на ходу додумывали большинство концепций.
Почти три года с ним работал, и если в 2013 он для своего времени он может и был не плох в сравнении с имевшимися альтернативами, но уже в 2017 я бы его едва ли взял.
Ребята, создатели React, это не ваше дело определять что можно, а что нельзя, это зависит от структуры данных, требований к программе и в разных случаях может быть разным.
Вот они и не определили. Сам реакт не управляет состоянием фронтенд приложения, он даёт вам апи, что бы вы могли управлять состоянием конкретного компонента. Как бы, ничего не мешает использовать любой подход. Можно мввм, можно флакс, можно мвц, можно своё что-то придумать.
На деле, навязывается скорее редакс или мобикс, но навязывается он не реактом, а сообществом
В этом смысле. реакт один из лучших решений из ui фреймворков вообще, не только в вебе. Все остальные, с которыми я работал, навязывали парадигму работы с данными (например wpf навязывает MVVM)
но по хорошему такой задачи вообще не должно возникать, как её не возникает во Vue, Angular или Svelte
как раз потому, что они её сделали за тебя.
реакт даёт односторонню привязку данных из коробки, предлагая тебе самому решить проблему обратной привязки. Другие фреймворки дают двухсторонюю, и ты об этом не думаешь.
В целом, на вкус и цвет. Какой бы фреймворк у тебя ни был, тебе всегда нужно объяснить ему, какие данные он должен отображать, где ему их брать, и как ему понять, что они обновились, и ему нужно переотразить их заново. Как бы, если ты не говоришь об этой проблеме — это не значит, что у тебя её нет. Если тебе поставляют вместе с фреймворком имплементацию МВВМ или любого другого МВx, ты думаешь об этом меньше. Но я бы не сказал, что это хорошо
P.S.: В том же Vue тоже можно добавлять неотслеживаемые поля и не создавать связь между данными и отображением, управлять обновлением вручную, заменить встроенный мост на redux, например. Только это никто не делает, потому что это не существующий кейс. Это как носить везде с собой парашют на случай падения с самолёта, при том, что вы вообще на земле. Просто почитайте с какими проблемами сталкиваются программисты на Vue, их количество и уровень, чтобы понять пропасть между этими фреймворками. Svelte тоже выглядит интересным, особенно с отказом от виртуального DOM, но не буду за него говорить, так как ещё не использовал в production.
С точки зрения реализации ребята в Vue, Angular и Svelte действительно проделали большую работу
Если нужно, что бы работу проделали за тебя, можно взять Mobx, и получится то же самое. А плюс тут в том, что есть широкий выбор
логику проекта, скажем на Vue, можно спокойно перенести на Svelte
Смелое заявление, я бы посмотрел, как легко получится мигрировать средний проект на Vue на ангуляр
С точки зрения того, как с этим работать — очень субъективно, лично мне после разных mvvm решений интерфейс реакта кажется максимально удобным и обоснованным.
Что вообще делает реакт? абстрагирует меня от работы с DOM. И да, это всё, что мне нужно от UI фреймворка. А состоянием я предпочитаю управлять или через свои решения, или через фреймворки для работы с состоянием.
Можно всю жизнь писать на встроенном MVVM, в том же 500 лет назад изобретенный WPF. Лично моя практика показывает, когда ты не думаешь о работе с сотоянием — ты работаешь с ним хреново. И архитектура твоего приложения от этого страдает. Появляется куча неявных связей в виде подписок на ивенты, которые никак не отследишь, просто глядя на кодовую базу. Только через дебаг, и то с кучей проблем.
В этом смысле, реакт с его четко детерминированной парадигмой — компонент отображает входные данные на пользовательский интерфейс — глоток свежего воздуха.
Это кстати отлично подходит для функционального подхода к программированию. Что, по-моему, определяющий плюс.
Нет, надо было нагородить своих стандартов и откатить веб на 20 лет назад, и пиарить этот подход среди людей, которые не знают другого
А это просто чушь. Даже не знаю, что тут можно сказать. На полном серьёзе обвинить добрую половину фронтенд инженеров мира (включая техлидов, синьоров и т.д.) в том, что пиар акция убедила их использовать дерьмовую технологию, а лично вы прекрасно видите, как они все ошибаются — человеку с таким самомнением не стоит тратить время на разъяснение очевидной истины всяким тупицам с хабра. Уверен, есть задачи и поважнее
На полном серьёзе обвинить добрую половину фронтенд инженеров мира (включая техлидов, синьоров и т.д.) в том, что пиар акция убедила их использовать дерьмовую технологию
Каюсь, я и сам на это повёлся. Хоть и сам несколько раз техлид. С первого взгляда это выглядит очень привлекательно, в 2013 реальный DOM правда был медленным и все создавали аналоги виртуального DOM в своих проектах. Не было Proxy, а get/set были на экспериментальной стадии и если вам нужна была поддержка IE — их для вас не существовало. JSX выглядел очень заманчиво. Но, как обычно, дьявол в деталях. Сначала ты думаешь, что просто чего-то не понимаешь, начинаешь копать, советоваться с коллегами, экспериментировать, смотреть исходники, изучать паттерны специально для React. Делаешь на нём пару проектов, привыкаешь, забываешь как это было на vanilla. Я понял, что что-то не так, когда на vanilla js на одном собеседовании за час сделал прототип приложения, на которое на React у меня ушло бы добрых два. Нет, ну не может так быть. Ну это же фреймворк, он же должен облегчать жизнь. Ну ладно, вот эта конкретная фича не облегчает. Ок, вот эта тоже заставляет писать лишнего, но это же мелочи. Одно время колебался между React и Vanilla. Angular первой версии создан правильно, приложения на нём делаются в разы быстрее и комфортнее, чем на React, но он имеет проблему с инкапсуляцией, а это критично, надеюсь после 2 версии с приходом Google это исправили. Когда я увидел Vue — я понял, что можно делать по нормальному, и это не только моё мнение. Многие из тех, кто попробовал его достаточно основательно больше никогда не вернутся на React. На самом деле разница между ними всеми не такая прямо вырвиглазная, джуниор найдёт все их полезными. Вы же, «король разработки», нашли в реакте подход «компонент отображает входные данные на пользовательский интерфейс» или «абстрагирует меня от работы с DOM», хотя это никакого отношения не имеет к React и общее почти для всех frontend-фреймворков. Но в деталях разница, которая всё рушит или всё преображает. Например, проброс свойств родителя потомку стоил ангуляру потери первого места. Это не было сразу очевидно. Нужно зарелизить не один проект, чтобы понять, что же не так.
как они все ошибаются
Ну во первых не все. Кто со мной согласен — просто не пользуются React без особой необходимости (а пользуются Vue, Svelte, Angular, и ещё несколькими десятками решений). Во вторых аргумент к социальному доказательству хорошо работает в маркетинге, при продаже стирального порошка домохозяйкам, но не нужно тащить его на Хабр. Добрая половина научного мира тоже в своё время ошибалась, веря в теорию теплорода или теорию эфира. Мы может рассуждать более сильными аргументами, такими как бенчмарк производительности программиста на разных фреймворках, обзор фич или основных проблем. Основные проблемы реакта, отсутствующие в других мейнстрим-фреймворках я выше привёл. Вообще React по восприятию (и, кстати, по распространённости) очень похож на PHP, им довольны только люди, не знающие других решений. К сожалению, с массовым набором новых ребят в IT и особенно в веб, таких сейчас большинство. Мы сами в этом виноваты, если бы меня спросили 5 лет назад что я думаю о React — я бы сказал, что это выглядит очень перспективно. Никто не ругает технологию с которой мало знаком, а когда набирается достаточно фактической базы — уже слишком поздно.
Я понял, что что-то не так, когда на vanilla js на одном собеседовании за час сделал прототип приложения, на которое на React у меня ушло бы добрых два. Нет, ну не может так быть
Ещё как может. Компонентный подход же, который на ваниле придётся руками делать. И он начинает давать преимущества не на стадии «прототип за час»
Вы же, «король разработки», нашли в реакте подход «компонент отображает входные данные на пользовательский интерфейс» или «абстрагирует меня от работы с DOM», хотя это никакого отношения не имеет к React и общее почти для всех frontend-фреймворков
Эти штуки есть в реакте, и в остальных фреймворках тоже есть. Я сказал, что мне от ui фреймворка нужно только это (компонентынй подход — как раз таки реализация абстрагирования от DOM).
Во вторых аргумент к социальному доказательству хорошо работает в маркетинге
Ну, какое утверждение (теория заговора про пиар реакта ради того, что бы никто не сделал сайт лучше фейсбука), такой и аргумент в ответ
А это просто чушь. Даже не знаю, что тут можно сказать. На полном серьёзе обвинить добрую половину фронтенд инженеров мира (включая техлидов, синьоров и т.д.) в том, что пиар акция убедила их использовать дерьмовую технологию, а лично вы прекрасно видите, как они все ошибаются — человеку с таким самомнением не стоит тратить время на разъяснение очевидной истины всяким тупицам с хабра. Уверен, есть задачи и поважнее
Сто тысяч леммингов не могут заблуждаться? У меня, например, подобное отношение к бутстрапу. Я считаю его избыточным или наоборот, недостаточным для большинства проектов в которых он используется. Он адово засирает код, он плодит лишние сущности вообще без ограничений. Да что там… Он в большинстве случаев даже не экономит трудозатраты. Но многие все равно хотят бутстрап в перечне технологий, потому что… модно!
С фреймворками та же беда. Порой спрашиваешь «а зачем вам тут реактивность? зачем всё это городить, если у вас элементарная статика на входе и выходе?»…
То есть они не сделали основного, что входит в обязанности любого ui-фреймворка
А они не делали ui-фреймворк, они делали библиотеку рендеринга.
Да, можно написать свою прокладку, которая будет соединять react с данными, что и сделали авторы redux и mobx, но по хорошему такой задачи вообще не должно возникать, как её не возникает во Vue, Angular или Svelte.
Если у вас не возникает задачи по организации хорошей архитектуры (а очень много людей на фронтэнде дико удивляются тому факту, что на фронтэнде тоже нужна архитектура, «ну тут же всё просто, кнопочки, поля, данные собрать в JSON и отправить») — то вариантов немного:
1) Вы пишете мелкую тривиальщину, когда и вправду «кнопочки, поля, и данные собрать», это всё в размерах небольшое, и никогда не вырастет.
2) Вы фронтэндер одного фреймворка. Потому что действительно, во всех современных фреймворках (включая реакт) есть заготовки для MVVM или чего-то подобного, и вы «насобачились» применять заготовку вашего фреймворка должным образом.
3) Вы радостно кодите в сторону обрыва, за которым вас поджидает превращение всего вашего проекта в бесформенный кусок говнокода.
Логику проекта, скажем на Vue, можно спокойно перенести на Svelte, потому что это просто сущности JavaScript.
Это чрезвычайно смелое и абсолютно голословное заявление, которое вы, скорее всего, на проектах реального, а не «карманного» размера подтвердить не сможете.
Это я вам говорю как человек, который больше половины своей профессиональной карьеры переписывает фронтэнды с приданием им хоть какой-то архитектуры и поддерживаемости.
Это я вам говорю как человек, который больше половины своей профессиональной карьеры переписывает фронтэнды
Ну я как бы всю карьеру фронтенд пишу, 15 лет уже, давайте этим мериться.
Если у вас не возникает задачи по организации хорошей архитектуры
Эта претензия не по адресу. Да, есть много людей, которые не задумываются об архитектуре и это большая проблема. Больше того, именно фреймворки и послужили тому, что у людей без знания принципов построения архитектуры получается создавать какие-никакие приложения, в результате отбивается стимул её изучать и падает общая квалификация. Касательно упомянутого пункта, отказ от избыточного слоя абстракции не означает отсутствие архитектуры. У вас может быть сколько угодно других (целесообразных) абстракций, просто не нужно плодить сущности без необходимости, как сделали в React.
Это чрезвычайно смелое и абсолютно голословное заявление, которое вы, скорее всего, на проектах реального, а не «карманного» размера подтвердить не сможете.
Под «реальными» вы подразумеваете то г… но, которое пишут люди, вчера выучившие один фреймворк, позавчера javascript, и понятия не имеющие о том, что нужно отделять данные от представления? Тогда да, не смогу. На проектах, с хорошей архитектурой это конечно будет долгой задачей (ещё бы, переписать всё представление), но абсолютно тривиальной и половина приложения останется нетронутой.
На проектах, с хорошей архитектурой это конечно будет долгой задачей (ещё бы, переписать всё представление), но абсолютно тривиальной и половина приложения останется нетронутой.
На проектах с хорошей архитектурой фреймворк всегда будет спокойно отчуждаем, вью ли это, реакт ли это, или что-то еще. Потому что в фреймворке останется только сам рендер, а весь остальной код будет framework-agnostic.
Но где бы их найти, эти проекты с хорошей архитектурой. Это даже не говоря про то, что имея такие проекты, перенести что-то куда-то с реакта будет нисколько не сложнее, чем с вью.
Пока какой-то крупный проект не изъявит желание перейти на svetle и его опыт не окажется положительным, надежды на svetle как на конкурента тройки крайне малы, ИМХО.
Вы можете встретить Svelte на главной странице https://mail.ru/ и https://money.yandex.ru. (определяется по соответствующим классам svelte-****
в коде).
Вот зачем вы только что сделали такую антирекламу хорошему перспективному фреймворку?
Пилю проекты на Vue. Благо, в компании лояльно относятся к выбору технологий. Реакт стал изучать так, для общего развития. Буду ли я на него переходить? — вряд ли. Сейчас мне кажется, что Vue умеет все что React, только красивее (JSX — рай для мазохиста). Жду Vue 3, возможно перейду на Angular. Ну а Svelte — для меня это пока что много шума, и мало полезной информации. Вот как-то так.
Может https://www.spotify.com тогда в противовес? =)
Вот серьёзно, чем они думают?
Тут более сложный вопрос. Изначально JSX тоже не был типизированным, и его добавили позже, увидев популярность его в сообществе.
Так же и со Svelte – у него свой оригинальный синтаксис шаблонов, за счет которых он является таким крутым. И это теперь задача инструментов (IDE, сборщиков и тайпчекеров) поддержать новый синтаксис.
Тайпскрипт хорош, но ограничивает фантазию. Svelte вводит много инноваций на тему реактивности, из-за которых он и выигрывает в разных бенчмарках. Система типов тайпскрипта их выразить, к сожалению, не в состоянии.
Вот тут перечислены 4 пункта, по которым код на Svelte отличается от валидного Javascript:
https://svelte.dev/docs#script
на них Typescript и споткнётся.
Да, у них свой dsl для шаблонов, и он не ложится так чисто на js/dom, как jsx. А в обсуждаемой статье, между прочим, указали отсутствие jsx как "плюс" у Svelte. И не записали в минусы самобытный dsl для шаблонов, который ещё и меняется от версии к версии.
«Типы ограничивают фантазию разработчиков. К сожалению, недостатки у них тоже есть»
Думают они известно чем. Полная поддержка TS при формировании DOM возможна только через TSX, а TSX — это всегда виртуальный DOM.
TSX — это всегда виртуальный DOM
Строго говоря, нет. Вам никто не мешает в реализации аналога createElement, назовем его dom(...) (то есть что-то вроде “@babel/plugin-transform-react-jsx”, { “pragma”: “dom” }) написать и нативную реализации с полной перерисовкой всех дочерних компонентов при изменении свойств/внутреннего состояния. Даже на Хабре есть реализация. Просто тогда придется более надежно защищаться от перерисовки и всякие биндинги делать через реальные id-шники, чтобы как-то реализовывать привязку данных. Я вполне допускаю, что некоторые клиентские шаблонизаторы так и работают.
Формально, вы правы — но полная перерисовка это ещё хуже чем виртуальный DOM. Настолько хуже, что я не вижу смысла обсуждать этот вариант всерьёз.
Вот серьёзно, чем они думают?
Видимо все еще хайп на первом месте.
_https://github.com/sveltejs/svelte/issues/3677#issuecomment-590060874 (Feb 23 2020):
> I have analyzed Svelte commits for last half a year. Please correct me if I am wrong, but there is no a single commit related to Typescript support. There is no slightest sign of any progress in the area. I would like to choose Svelte for a project, but I cannot argue it is the right choice. I would like to know if Svelte team has any roadmap and vision of implementing TS. I also want to know whether they just do care. Just say us when there will be any progress in the direction
Добавление поддержки Typescript в Svelte это не такая задача чтобы "просто берем и добавляем". Код нем отличается от обычного JS, поэтому и Typescript его не понимает.
Тут есть два варианта – они выпустят Svelte 4, с новым более дружественным для типов синтаксисом. Либо Typescript наконец-то доведет до ума свое plugin API, чтобы можно было написать плагин для синтаскиса Svelte.
Оба варианта требуют большой работы, поэтому странно чего-то ожидать в скором времени.
Видимо у MS денег и разработчиков не хватает, чтобы воплотить это в жизнь. Что ж придется скромному js разработчику из NYT и его сотоварищам как-то помочь им в популяризации TS.
{/sarcasm}
Ну вот технически я особых плюсов перед FlowType не вижу (по состоянию года на 3 тому), скорее наоборот. Но по факту TS популярнее.
Для меня большим плюсом было то, что Typescript написан на JS, и для своей работы ничего кроме Node не требует. Flow же поставляется бинарником, что чревато проблемами в кросс-платформенности, или необходимостью сборки из исходников, если под вашу систему его еще не собрали за вас.
youtu.be/etKOc80-cw0
А так считаю писать на чистом js глупо
Интересный доклад, но уже устарел за пару лет.
Пример из этого момента с промисами сейчас работает в Typescript как надо, починили: пример
Хотя мне тоже не нравится такое поведение на шаблонах, может разработчики решили, что вариантность в шаблонах нормально проставлять не будут. Хотя strictFunctionTypes может для шаблонов тоже что-то есть или будет.
Хотя strictFunctionTypes может для шаблонов
Хотя strictFunctionTypes сделали, может для шаблонов
Тут проблема не в шаблонах, а в том, что компилятор при проверке совместимости типов принципиально игнорирует мутабельность свойств или элементов.
Вот такой код компилируется, хотя не должен бы:
let foo1: { bar: Animal } = undefined!;
let foo2: { bar: Dog } = undefined!;
foo1 = foo2;
Вот такой код компилируется, хотя не должен бы:
С чего бы ему не компилироваться? Собака содержит все интерфейсы животного, в чем тут проблема?
Не должен компилировать такой код:
let foo1: { bar: Animal } = undefined!;
let foo2: { bar: Dog } = undefined!;
foo2 = foo1;
Но он и не компилируется.
Как React «делает всё остальное»? Благодаря использованию технологии виртуальной DOM. Определение того, какие части DOM нужно обновить, проводится в недрах библиотеки, на промежуточном уровне, находящемся между кодом, написанным программистом, и реальной DOM. Именно благодаря этой технологии можно гарантировать высокие скорости рендеринга страниц.
Виртуальная DOM — сравнительно медленная технология.
Мне, человеку далекому от мира фронтенда, это не понятно.
Так виртуальный дом это быстро или медленно?
Вычисление патчей для реального дома через виртуальный заметно быстрее чем работа напрямую с реальным (хоть полный перерендинг, хоть вычисление "патчей"). Svelte обещает скорость близкую к теоретически максимально возможной — точечные патчи без какого-либо сравнения деревьев, практически как опытный фронтендер руками напишет, имея в виду оптимизацию (пере)рендринга. А по сравнению с тем, что неопытный руками напишет будет и быстрее, и качественней, скорее всего.
Пришло ли время забыть о React и перейти на Svelte?