Comments 117
Уважаемые читатели! Что вы думаете о Svelte?
Последний раз, когда я захотел взять Svelte в прод (в конце 2019) — я пошел в дискорд, и за неделю чтения дискорда, особенно feed с гитхаба… расхотел. Брать в прод то, от чего регулярно отваливаются детали — идея крайне сомнительная.
Отличная производительность, улучшающая впечатления пользователей от работы с сайтами, созданными на Svelte.
Справедливости ради, если во времена Svelte v2 там и вправду можно было хвалиться производительностью, очень близкой к vanilla.js, то в v3 уже нет. Конечно, Svelte всё еще быстрее реакта, кто б сомневался. Но уже не настолько быстрая, как многие другие оптимизирующие перестройку DOM библиотеки.
Сделали на Svelte несколько проектов. Впечатления самые приятные.
Да, Svelte набирает популярность и он очень хорош, но есть ещё несколько графиков, которые показывают, что прекращать изучать React в данный момент не стоит.
www.npmtrends.com/@angular/core-vs-react-vs-vue-vs-svelte
Да, Svelte набирает популярность и он очень хорош, но есть ещё несколько графиков, которые показывают, что прекращать изучать React в данный момент не стоит.
www.npmtrends.com/@angular/core-vs-react-vs-vue-vs-svelte
Не думаю, что минус частоты обновления документации реакта объективен. Более того, как разработчик более 20 проектов на реакт за последние 4 года минусы производительности виртуального дом существенно снизились, нивелируются стандартными техниками рекомпозиции компонентов, а также возможностью всегда перейти на ванилу жс минуя реакт абстракции в критических для производительности местах. При этом, вы не будете страдать от такого перехода. Поэтому светлу нужно что-то больше чем сейчас, чтобы на него смотрели серьёзно. Для бизнеса с огромными деньгами важна надёжность — это не только инструменты, но и люди. Чем большее количество людей вовлечены в развитие и поддержку — тем охотнее бизнес внедряет такие инструменты. Если же такими инструментами владеют только самые «гики» — это риск, на который никто не пойдёт. Вопрос доверия остаётся открытым
отличное выступление о svelte от Ильи Климова
www.youtube.com/watch?v=0cFoEPhv2II
www.youtube.com/watch?v=0cFoEPhv2II
UFO just landed and posted this here
Это грустная примета. К счастью, в больших проектах такое редко встретишь.
Да, а потом ты садишься писать пет проект, с беком на java и спринге, и фронтом на реакте, и поражаешься, насколько на беке все отсталое. То что на фронте автоматизируется за пол минуты, в старой джаве не автоматизируется вообще никак, или автоматизируется с помощью кодогенерации в связке с плагинами к IDE. Ну хрен знает, что выгодно бизнесу, но разработчику точно выгодно переходить на новые инструменты
А если на фронте Реакт на Ангуляр поменять, то внезапно окажется что всё уже автоматизированно до тебя и тебе только бизнес-логику написать осталось
«Гуляйтеся детки, гуляйтеся в своей песочнице»(с)
Примеров, разумеется, не будет.
Хочу вернуть из запроса сущность, которая точно такая, как другая моя сущность, но одно поле называется по другому, и имеет тип строки вместо инта.
А писать новую DTO, которая перечисляет все поля существующей, не хочу. Как автоматизировать?
А писать новую 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;
}
Дженерики и наследование чем-то не подошли? Базовый абстрактный класс с общими полями, две имплементации, одна со стрингом, вторая с интом. Ничего по сто раз перечислять не нужно, а с lombok даже геттеры с сеттерами писать не придется.
Это не масштабируется. Грубо говоря, есть у меня структура данных User.
И ещё 50 производных от неё струткур, которые требуются клиенту.
Типа там, здесь мне нужен юзер со списком его покупок, тут юзер с метаинформацией о посещениях, тут нужен он же со списком своих друзей и т.д.
На стороне сервера у меня есть сущность User, которая всё это опосредованно содержит.
Фигачить от неё 50 dto, каждая из которых наследует базовую дто с общими полями (хотя я сомневаюсь, что такие вообще будут) — это совсем не похоже на автоматизацию.
Кроме того, наследование подразумевает расширение, в то время как мне при создании DTO часто нужно сужение.
Короче, подход с наследование избавит меня от бойлерплейта в одном с половиной случае, так я ещё и заплачу за это лишним классом UserDtoBase.
А ломбок хорошо только тем, что лечит болезни джавы (через костыль с кодогенерацией и плагин к IDE), его трудно понимать как аргумент против ЯПов, у которых нет таких болезней
И ещё 50 производных от неё струткур, которые требуются клиенту.
Типа там, здесь мне нужен юзер со списком его покупок, тут юзер с метаинформацией о посещениях, тут нужен он же со списком своих друзей и т.д.
На стороне сервера у меня есть сущность User, которая всё это опосредованно содержит.
Фигачить от неё 50 dto, каждая из которых наследует базовую дто с общими полями (хотя я сомневаюсь, что такие вообще будут) — это совсем не похоже на автоматизацию.
Кроме того, наследование подразумевает расширение, в то время как мне при создании DTO часто нужно сужение.
Короче, подход с наследование избавит меня от бойлерплейта в одном с половиной случае, так я ещё и заплачу за это лишним классом UserDtoBase.
А ломбок хорошо только тем, что лечит болезни джавы (через костыль с кодогенерацией и плагин к IDE), его трудно понимать как аргумент против ЯПов, у которых нет таких болезней
Ок, хорошо, у вас есть потребность иметь 50 разных User'ов, которые на какую-то чуточку отличаются друг от друга, и вы не хотите пользоваться наследованием. Зачем нужны эти 50 ентитей? Что бы вернуть клиенту в ответ на разные запросы. Но это тогда совсем разные сущности, у них разные задачи — ваш центральный User это представление user'а внутри системы, сложный объект инкапсулирующий всю логику и все данные пользователя, это ни разу не dto. А dto'шки вам нужны ровно в том месте, где вы собираете ответ на конкретный запрос, мест этих много и они, эти места, строго говоря, могут быть совсем не рядом. При таком ландшафте лично я бы предпочел иметь dto, которая будет четко и однозначно отвечать за преобразование User в тот вид, который улетит по сети, что бы во всех 50 случаях посмотрев в код я мог четко видеть, что происходит. в общем это не тот случай, когда стоит хотеть от компилятора странного.
При таком ландшафте я бы предпочёл не иметь в кодовой базе 50 DTOшек, которые во многом друг друга повторяют, и все являются отображением одного конкретного класса.
И тут вся проблема — кто то любит плодить одинаковый, зато явный код, кто-то выбирает автоматизацию, в обмен на снижение эксплиситности. Но в Java у тебя нет выбора.
Контексты задач разные, домены разные, в программировании очень редко можно сказать — всегда делай так, а не иначе. Поэтому я считаю инструменты, которые дают меньше пространства и выбора — отсталыми и неудобными.
И тут вся проблема — кто то любит плодить одинаковый, зато явный код, кто-то выбирает автоматизацию, в обмен на снижение эксплиситности. Но в Java у тебя нет выбора.
Контексты задач разные, домены разные, в программировании очень редко можно сказать — всегда делай так, а не иначе. Поэтому я считаю инструменты, которые дают меньше пространства и выбора — отсталыми и неудобными.
При таком ландшафте я бы предпочёл не иметь в кодовой базе 50 DTOшек, которые во многом друг друга повторяют, и все являются отображением одного конкретного класса.
Но предпочли бы иметь 50 заклинаний вида:
let dtoA = A.withMapping(id, (id) -> id.toString);
вне dto в произвольных местах кода. Где логика?
Я могу их иметь где угодно, в той же папке UserDto например. Логика в том, что эти «заклинания» короче классов, и тут нет перечисления одного и того же. Я не хочу дублировать код, вот где логика
Я могу их иметь где угодно
В том и суть, что все эти правила преобразования из А в Б могут быть действительно где угодно, размазанные по кодовой базе, и ответ на вопрос «каким образом получился данный конкретный выхлоп?» становится совсем не однозначным, поскольку нет никакого способа узнать всю цепочку метаморфоз произошедших с начальным объектом, кроме как прочитать код и найти все места, где с ним что-то делали.
Но, да бох с ним, хочется вам иметь возможность отстрелить себе ноги по самую шею — имеете полное право. Главное для меня тут в другом — это и были основные претензии к джаве и спрингу, на основании которых они были признаны вами «отсталыми»?
что все эти правила преобразования из А в Б могут быть действительно где угодно, размазанные по кодовой базе
Так же, как и ваши DTO которые вы можете складировать куда угодно, называть как угодно, и использовать как угодно. Половину из них вам может быть лень выделять в отдельные DTO, и вы обмажете их атрибутами мапинга — которые все кейсы покрыть не смогут. Это ещё усугубляется моментом, что класс в Java — это не данные, это данные+поведение, в кейсе с DTO мы используем его как дынные, что гарантируется только конвенциями, а не ЯПом.
Тут ещё момент с инстанцированием, код в стиле
var userDto = new UserDto(
user.getId(),
user.getName(),
user.getSome(),
....
);
которого в кодовой базе серьёзного проекта просто море — это кошмар.
В тайпскрипте это легко автоматизировать (очень легко).
Это ещё хорошо, если разработчик использует конструкторы для DTO, я встречал подходы в C#, когда все свойства делают с сеттерами, что бы костылить присваивание через рефлексию.
Помимо этого, есть претензии к Optional типу.
В Java нет юнионов, но при разработке они нужны — встроенный тип Optional тому подтверждение — это закостыленный с помощью контрактов юнион, который по сути ничего не гарантирует (да, он даёт варнинг, которых в большом проект могут быть тысячи). И даже если бы он работал как надо — реализация через контракты, это костыль.
Свой аналог типа-объединения без контрактов тоже не получиться сделать — например пытаться эмулировать его наследованием можно, но если он будет содержать дженерики (а кому нужны юнионы без дженериков?) — то он будет страшно неудобен в использовании.
Нет адекватной интерполяции строк.
Вести разработку в чём-то кроме идеи — невозможно, потому что половина проекта работает на кодогенерации
Отсутствие дженериков в рантайме в языке со статической, строгой номинативной типизацией — вызывает кучу вопросов. и добавляет кучу неудобств.
Подход в JPARepository, когда наследуешь интерфейс, пишешь в нём методы, а реализацию за тебя дописывают (я, если честно, не знаю. кто или что это делает) исходя из букв в названии метода — явно не от большого богатства системы типов сделан.
В целом, общая претензия такая — у ЯПа нищая, просто обездоленная система типов, которая не позволяет детально выразить даже самый простой домен.
Соглашусь, что если в языке только строгая типизация, это головная боль.
Возможно в вашем случае можно использовать список объектов. С Java не знаком, поэтому псевдокод.
Или хранить поля списком:
А при отправке преобразовывать в string/json.
Возможно в вашем случае можно использовать список объектов. С 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.
Хехе, не получится, в Java нет просто объектов. Есть странные анонимные классы, но они тут не подойдут
А если вместо объекта базовый класс или интерфейс задать и от него наследоваться для элементов списка?
Покажу на втором примере:
Покажу на втором примере:
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 документацию по этому ендпоинту? А то, мне сложно понять зачем всё это)
не хотите писать новую dto, зато напишите 10 модульных тестов )
Астрологи объявили неделю фронтэнда.
Минусов у Svelte на данный момент слишком много, чтобы даже просто подумать об отказе от зарекомендовавшего себя в бою реакта.
или от ангуляра :)
и о vue не забываем )
ага, каждый отметил свое предпочтение :)
посмотрите www.youtube.com/watch?v=0cFoEPhv2II&t=1660s
40:50 про скрывание аккардиона на gitlab — будет интересно узнать интересный момент в vue )
40:50 про скрывание аккардиона на gitlab — будет интересно узнать интересный момент в vue )
ну это не показатель, просто то что попалось крутому докладчику и поэтому стало так популярно, подобных архитектурных тормозов на реакте или других фреймворках в мировых продуктах уверен — навалом вследствие криворукости архитекторов или бюрократии большой корпорации и тд.
Криворуких может и много ). А вы можете описать в целом какую ошибку допустили на сворачивание? Как ее обойти? Отсылка на криворукость также не аргумент ). Возможно стоит признать, что у Vue есть архитектурные ограничения. Думаю ваши мысли будут интересны не только мне, но и другим читателям). Заранее спасибо
UFO just landed and posted this here
А вы можете описать в целом какую ошибку допустили на сворачивание? Как ее обойти?
он сам описывал это на другой конфе — там проблема в state management по большей части (т.е. не самая центральная функциональность Vue): youtu.be/3tdfBMRq34o?t=2311
p.s. Ну и во Vue3 планируется кстати оптимизация т.к. tree diff будет сравниваться блоками а не по каждому элементу, это должно сократить время затрачиваемое на обновления компонентов, тут подробней: youtu.be/WLpLYhnGqPA?t=1794
он сам описывал это на другой конфе — там проблема в state management по большей части (т.е. не самая центральная функциональность Vue): youtu.be/3tdfBMRq34o?t=2311
p.s. Ну и во Vue3 планируется кстати оптимизация т.к. tree diff будет сравниваться блоками а не по каждому элементу, это должно сократить время затрачиваемое на обновления компонентов, тут подробней: youtu.be/WLpLYhnGqPA?t=1794
Например каких?
UFO just landed and posted this here
React изначально был мёртворождённым ребёнком и все кто его используют постоянно мучаются то со state-менеджментом, то с формами, то ещё с 100+ моментов, которые не продумали его авторы. К сожалению facebook имеет слишком большой отдел маркетинга и слишком много денег, чтобы посылать разработчиков пиарить свою компанию на все конференции. Заменить React технически — не сложная задача, гораздо сложнее заменить React в головах, когда уже поколение разработчиков выросло на JSX и понятия не имеет как работает реальный DOM.
гораздо сложнее заменить React в головах, когда уже поколение разработчиков выросло на JSX и понятия не имеет как работает реальный DOM
Шаблонизацию HTML в любом случае заменять не надо. Ну если только вы очень жаждете попереизобретать велосипеды.
А уж какая там именно шаблонизация, JSX или не JSX — не очень важно. В любом случае, JSX != React.
UFO just landed and posted this here
Svelte, Vue, AngularJS (сказал бы и за Angular, но с ним не работал), даже древний Knockout. Почти все или дают меньше возможностей, но гораздо дешевле (с меньшими ограничениями), либо больше возможностей за ту же цену. Из мейнстрим-решений я бы предпочёл React только Backbone и ExtJS. Пока, когда есть возможность выбора стека, использую Vue или vanilla js.
UFO just landed and posted this here
О, на это множество статей на Хабре, нет смысла тут дублировать.
UFO just landed and posted this here
Моё мнение вот, например:
habr.com/ru/post/462705/#comment_20485003
habr.com/ru/post/459706/#comment_20395539
habr.com/ru/post/462705/#comment_20485003
habr.com/ru/post/459706/#comment_20395539
у Vue плоская система реактивности. Если на странице много компонентов и пытаетесь удалить большое дерево компонентов, приводит к тормозам системы.
Также интересный момент: habr.com/ru/company/yandex/blog/486146
Также интересный момент: 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 я бы его едва ли взял.
Не очень понятно. Идея прорабатывать state management наоборот явно заставляет решать проблемы, которые иначе бы потом возникли в рантайме.
Линус Торвальдс как-то говорил, что плохие программисты думают над инструментами, а хорошие — над структурой данных. State — это прежде всего данные, над ними надо думать, и более того, это основное над чем надо думать. Но UI-фреймворк не должен навязывать способ как нам обращаться с нашими данными. Может я хочу использовать linqToJs. Moжет нативные Map и Set. Может нативные js-классы и вынести обработку данных в отдельные от view модули (в 90% это целесообразно). Фреймворк должен помогать мне в этом, а не навязывать свои правила, вроде «стейт меняется только таким образом» или «props нельзя изменять из компонента». Ребята, создатели React, это не ваше дело определять что можно, а что нельзя, это зависит от структуры данных, требований к программе и в разных случаях может быть разным. Vue так же не позволяет менять props по техническим причинам, но даёт очень лёгкий способ обойти это, если так надо. Так же Vue позволяет легко выносить логику работы с данными за пределы компонента и работать с ними стандартными средствами javascript, без каких либо ограничений фреймворка вообще. В React при использовании state или context — это просто боль из за многословности и костного API, при использовании Redux вам доступны только плоские сериализуемые структуры данных, никаких Map и Set, никаких нативных ссылок на объекты, иммутабельность, которая часто просто не уместна, при использовании хуков, последнего и рекомендуемого решения — вам не доступен вынос логики за пределы компонентов. Решение, которое я сейчас использую на проектах, на которых приходится использовать React — это MobX, он как может решает большую часть проблем, но всё равно остаётся очень многословным по сравнению с тем же Vue. Так что да, проблемы с данными нужно решать на этапе разработки, а не в рантайме, но я не согласен, что инструмент должен заставлять вас это делать и навязывать решение, это полностью ответственность программиста и какую организацию вы выберете для своих данных не должно зависеть от view-слоя. К сожалению, с React просто использовать стандартные решения JavaScript без адаптеров не представляется возможным, они изобрели свои велосипеды на трёх колёсах, и в этом, наверное, моя главная претензия к React.
Ребята, создатели React, это не ваше дело определять что можно, а что нельзя, это зависит от структуры данных, требований к программе и в разных случаях может быть разным.
Вот они и не определили. Сам реакт не управляет состоянием фронтенд приложения, он даёт вам апи, что бы вы могли управлять состоянием конкретного компонента. Как бы, ничего не мешает использовать любой подход. Можно мввм, можно флакс, можно мвц, можно своё что-то придумать.
На деле, навязывается скорее редакс или мобикс, но навязывается он не реактом, а сообществом
В этом смысле. реакт один из лучших решений из ui фреймворков вообще, не только в вебе. Все остальные, с которыми я работал, навязывали парадигму работы с данными (например wpf навязывает MVVM)
Они сделали связку model и view на своих правилах, то есть принимают объекты не как есть, а через неизменяемые props или метод setState. Да, можно написать свою прокладку, которая будет соединять react с данными, что и сделали авторы redux и mobx, но по хорошему такой задачи вообще не должно возникать, как её не возникает во Vue, Angular или Svelte. React просто отошёл от стандартов, нагородил своё API, и да, им можно пользоваться, но у других просто нет этого слоя абстракции и нет всех тех проблем, которые он порождает. Заметьте, 90% статей про то, как управлять стейтом идёт от пользователей React, для других эта проблема будто бы не существует. И она на самом деле не существует ни на Vue, ни на Angular, ни на Svelte.
но по хорошему такой задачи вообще не должно возникать, как её не возникает во Vue, Angular или Svelte
как раз потому, что они её сделали за тебя.
реакт даёт односторонню привязку данных из коробки, предлагая тебе самому решить проблему обратной привязки. Другие фреймворки дают двухсторонюю, и ты об этом не думаешь.
В целом, на вкус и цвет. Какой бы фреймворк у тебя ни был, тебе всегда нужно объяснить ему, какие данные он должен отображать, где ему их брать, и как ему понять, что они обновились, и ему нужно переотразить их заново. Как бы, если ты не говоришь об этой проблеме — это не значит, что у тебя её нет. Если тебе поставляют вместе с фреймворком имплементацию МВВМ или любого другого МВx, ты думаешь об этом меньше. Но я бы не сказал, что это хорошо
Этот вопрос можно рассматривать с двух сторон: с точки зрения реализации и с точки зрения интерфейса. С точки зрения реализации ребята в Vue, Angular и Svelte действительно проделали большую работу и под капотом того, что кажется просто изменением переменной, сложная логика отслеживания изменений и реакций на них. Но с точки зрения интерфейса для программиста в этих фреймворках нет никакой разницы, работаете ли вы с нативными сущностями js или со свойствами слоя представления. Они взаимозаменяемы, имеют одинаковый интерфейс. Логику проекта, скажем на Vue, можно спокойно перенести на Svelte, потому что это просто сущности JavaScript. В React наоборот, очень минималистичная реализация и совершенно самобытный интерфейс для работы с ней. То есть они не сделали основного, что входит в обязанности любого ui-фреймворка, не сделали моста между моделью и шаблоном и взвалили этот груз на пользователя. Если на то пошло, то с нативным DOM тоже можно работать в такой манере, только вместо setState вызывать setAttribute, и это при правильном подходе будет быстрее, чем React. Что они вообще сделали? Рендеринг шаблона? Да, через удобный JSX. Да, с кешированием (читай виртуальный DOM). Возможно они просто были не в теме как было принято во фронте на тот момент и до сих пор принято в большинстве фреймворков (React разрабатывался под большим влиянием PHP и бекенд-разработки). А во фронтенд того времени принято было так, что вы просто создаёте абстракцию JavaScript, которая инкапсулирует в себя всю работу с DOM. То есть вы изменяете свойство объекта — меняется текст на странице. Добавляете элементы в массив — добавляются пункты к списку на странице. Можно назвать это двусторонним дата-биндингом, но по сути это просто аватар вашего UI, однозначный и всегда синхронизированный образ. Односторонний биндинг никогда не бывает нужен, если что-то нужно продублировать — вы делаете это в js, не меняя слой view, и этим разводите логику отображения и редактирования. Представление view в js — это ещё из vanilla js подход. Вы работаете с обычными js-объектами, а изменения происходят в UI. Это очень просто и очень элегантно, вам не нужно изобретать велосипеды, вы используете принципы разработки программ, созданные не для фронтенда, а в целом, которым под 50 лет, и у вас всё хорошо. Нет, надо было нагородить своих стандартов и откатить веб на 20 лет назад, и пиарить этот подход среди людей, которые не знают другого. Да, в интересах facebook чтобы веб откатился и все сидели только на одном сайте на букву Ф вместо миллионов разных. И когда я вижу как люди бьются в стены, снесённые 20 лет назад, понимаю, что у них получается.
P.S.: В том же Vue тоже можно добавлять неотслеживаемые поля и не создавать связь между данными и отображением, управлять обновлением вручную, заменить встроенный мост на redux, например. Только это никто не делает, потому что это не существующий кейс. Это как носить везде с собой парашют на случай падения с самолёта, при том, что вы вообще на земле. Просто почитайте с какими проблемами сталкиваются программисты на Vue, их количество и уровень, чтобы понять пропасть между этими фреймворками. Svelte тоже выглядит интересным, особенно с отказом от виртуального DOM, но не буду за него говорить, так как ещё не использовал в production.
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-**** в коде).
>mail.ru (...) yandex.ru
Вот зачем вы только что сделали такую антирекламу хорошему перспективному фреймворку?
Вот зачем вы только что сделали такую антирекламу хорошему перспективному фреймворку?
Пилю проекты на Vue. Благо, в компании лояльно относятся к выбору технологий. Реакт стал изучать так, для общего развития. Буду ли я на него переходить? — вряд ли. Сейчас мне кажется, что Vue умеет все что React, только красивее (JSX — рай для мазохиста). Жду Vue 3, возможно перейду на Angular. Ну а Svelte — для меня это пока что много шума, и мало полезной информации. Вот как-то так.
Может https://www.spotify.com тогда в противовес? =)
Без полноценной поддержки TypeScript оно так и останется поделкой для сайтов визиток и других одноразовых задач.
Если честно, когда кто-то на полном серьёзе делает инструмент для фронта, и без полной поддержки ts, я испытываю глубокое недоумение
Вот серьёзно, чем они думают?
Вот серьёзно, чем они думают?
Тут более сложный вопрос. Изначально JSX тоже не был типизированным, и его добавили позже, увидев популярность его в сообществе.
Так же и со Svelte – у него свой оригинальный синтаксис шаблонов, за счет которых он является таким крутым. И это теперь задача инструментов (IDE, сборщиков и тайпчекеров) поддержать новый синтаксис.
Насколько я понимаю, когда начали делать реакт, тайпскрипт не был стандартом индустрии. И Фейсбук ставил на свой FlowTypes. Сейчас довольно странно начинать проект на чистом js
Тайпскрипт хорош, но ограничивает фантазию. Svelte вводит много инноваций на тему реактивности, из-за которых он и выигрывает в разных бенчмарках. Система типов тайпскрипта их выразить, к сожалению, не в состоянии.
Можно кейс, который не выразить системой типов тайпскрипта? Именно с реактивностью
Вот тут перечислены 4 пункта, по которым код на Svelte отличается от валидного Javascript:
https://svelte.dev/docs#script
на них Typescript и споткнётся.
Ого, он ещё и отличается от валидного Javascript? Очень спорный подход, как по мне
«Типы ограничивают фантазию разработчиков. К сожалению, недостатки у них тоже есть»
Думают они известно чем. Полная поддержка TS при формировании DOM возможна только через TSX, а TSX — это всегда виртуальный DOM.
TSX — это всегда виртуальный DOM
Строго говоря, нет. Вам никто не мешает в реализации аналога createElement, назовем его dom(...) (то есть что-то вроде “@babel/plugin-transform-react-jsx”, { “pragma”: “dom” }) написать и нативную реализации с полной перерисовкой всех дочерних компонентов при изменении свойств/внутреннего состояния. Даже на Хабре есть реализация. Просто тогда придется более надежно защищаться от перерисовки и всякие биндинги делать через реальные id-шники, чтобы как-то реализовывать привязку данных. Я вполне допускаю, что некоторые клиентские шаблонизаторы так и работают.
Формально, вы правы — но полная перерисовка это ещё хуже чем виртуальный DOM. Настолько хуже, что я не вижу смысла обсуждать этот вариант всерьёз.
Недавно крутил таким же способом JSX к PhaserJS. По факту без чего-то вроде VDOM не получится либо организовать эффективные перерисовки, либо избавиться от императивного кода. И то и другое не слишком уж приемлемо в современном вебе.
Вот серьёзно, чем они думают?
Видимо все еще хайп на первом месте.
_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.
Оба варианта требуют большой работы, поэтому странно чего-то ожидать в скором времени.
{#sarcasm mode}
Видимо у MS денег и разработчиков не хватает, чтобы воплотить это в жизнь. Что ж придется скромному js разработчику из NYT и его сотоварищам как-то помочь им в популяризации TS.
{/sarcasm}
Видимо у MS денег и разработчиков не хватает, чтобы воплотить это в жизнь. Что ж придется скромному js разработчику из NYT и его сотоварищам как-то помочь им в популяризации TS.
{/sarcasm}
TS не нуждается в популяризации.
Ну вот технически я особых плюсов перед FlowType не вижу (по состоянию года на 3 тому), скорее наоборот. Но по факту TS популярнее.
Для меня большим плюсом было то, что Typescript написан на JS, и для своей работы ничего кроме Node не требует. Flow же поставляется бинарником, что чревато проблемами в кросс-платформенности, или необходимостью сборки из исходников, если под вашу систему его еще не собрали за вас.
Я не топлю за flow, но в этом видео есть интересные моменты относительно ts, которые могут проявиться не очень хорошо
youtu.be/etKOc80-cw0
А так считаю писать на чистом js глупо
youtu.be/etKOc80-cw0
А так считаю писать на чистом js глупо
Интересный доклад, но уже устарел за пару лет.
Пример из этого момента с промисами сейчас работает в Typescript как надо, починили: пример
Не уверен, что это эквивалентный код для Flow, но у меня он тоже ничего не нашел.
Хотя мне тоже не нравится такое поведение на шаблонах, может разработчики решили, что вариантность в шаблонах нормально проставлять не будут. Хотя strictFunctionTypes может для шаблонов тоже что-то есть или будет.
Хотя мне тоже не нравится такое поведение на шаблонах, может разработчики решили, что вариантность в шаблонах нормально проставлять не будут. Хотя 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 — сравнительно медленная технология.
Мне, человеку далекому от мира фронтенда, это не понятно.
Так виртуальный дом это быстро или медленно?
Быстрее чем полный перерендер всего дерева на каждое изменение состояния, как это было со строковыми шаблонами, но медленнее чем прямые точечные изменения в DOM после статического анализа связей без реконсиляции в рантайме в Svelte.
Вычисление патчей для реального дома через виртуальный заметно быстрее чем работа напрямую с реальным (хоть полный перерендинг, хоть вычисление "патчей"). Svelte обещает скорость близкую к теоретически максимально возможной — точечные патчи без какого-либо сравнения деревьев, практически как опытный фронтендер руками напишет, имея в виду оптимизацию (пере)рендринга. А по сравнению с тем, что неопытный руками напишет будет и быстрее, и качественней, скорее всего.
UFO just landed and posted this here
Sign up to leave a comment.
Пришло ли время забыть о React и перейти на Svelte?