Когда я вижу очередную статью о Svelte:
RE: Боль и слёзы в Svelte 3
Svelte 3: Переосмысление реактивности
Почему SvelteJS возможно лучший фреймворк для новых веб-разработчиков
Легенда о Фреймворке Всевластия
Re: «Сравнение JS-фреймворков: React, Vue и Hyperapp»
Исчезающие фреймворки
Меня переполняет восхищение от наглости писавших её. С серьёзнейшим видом эти люди приходят и начинают рассказывать что их фреймворк в принципе может рассматриваться как альтернатива большой тройке: Angular, React, Vue. Первый раз я подумал, что автор из-за своей неопытности на полном серьёзе рассматривает Svelte как вменяемую production-ready альтернативу устоявшимся фреймворкам. Второй раз я подумал, что автор испытывает творческий кризис и его так тошнит от большой тройки, что ему хочется писать на чём угодно, но только не на ней. В последующие разы меня преследовало чувство, что кто-то просто строчит заказные посты.
Паранойя, скажете вы и будете правы. Но мой психотерапевт занят поддержкой пострадавших от коронавируса. Им нужнее. Поэтому выговариваться мне придётся вам. А выговориться я бы хотел на тему того, что Svelte — натужно пиаримый кем-то мертворождённый фреймворк. Который в 2020 году является пустой тратой времени и не имеет никаких реальных конкурентных преимуществ по сравнению с другими фронтенд-фреймворками.
Не хочу сравнивать Svelte и остальные фреймворки и проходить по его конкретным недостаткам. Можете почитать эту статью ради конкретики. О конкретике с фанатами(пиарщиками?) Svelte спорить бесполезно. Они найдут ту самую ситуацию, когда какой-то компонент откажется работать со shadow DOM используемого фреймворка и будут выставлять её как абсолютный аргумент в пользу Svelte. И тот факт, что мешать в одном проекте компоненты написанные для разных реактивных фреймворков, да и сами фреймворки — затея ниже средней, их не смутит. Как не смутит и указание на что-то чего в Svelte нет — оно либо не нужно, либо уже пилится и вообще как только так сразу. Поэтому я просто не вижу смысла спорить о деталях. Всё равно выйдет что Svelte — замечательный фреймворк.
Ну знаете как то: лисп замечательный язык, только на нём почти никто не пишет, хаскелл — язычище каких поискать(как и тех кто пишет на нём) и т.д. Всё хорошо, всё отлично, только никому не нужно. Так что давайте сразу зайдем с козырей. У нас есть большая тройка вёб-фреймворков. Она худо-бедно устоялась за последние 5 лет. На ней создана и работает куча проектов. Для неё есть куча библиотек и компонентов. Для неё исправлены многие детские болезни. У неё большое сообщество опытных профессионалов. Для неё куча работы.
Svelte же не может с практической стороны похвастаться почти ничем. Я помню как взлетал и набирал популярность Vue на фоне реакта с ангуляром. Да пиар был, но Vue просто не нуждался в пиаре. Он решал реальные проблемы раздутости и сложности других фреймворков. Он взял то что было реализовано в других и реализовал в минималистичной форме. Он решал конкретную проблему — сложность и монструозность двух других фреймворков. Какую реальную проблему решает Svelte я не знаю. То что написано у них на сайте это заявление о благих намерениях.
С практической точки зрения важно одно — насколько хорошо фреймворк решает реальные бизнес задачи. И с этой точки зрения, если взять 2 фреймворка примерно одинаково решающие задачи, но у одного из них больше коммьюнити и экосистема, разумно выбрать последний. Svelte вышел в 2016 году. Vue вышел в 2014. Разница в 2 года. Т.е. Svelte мог учесть все ошибки Vue и стать лучшим, отвоевать аудиторию и рынок. Но он до сих пор является полнейшей маргинальщиной известной в основном по своим хвалебным статьям.
Особенно актуально это для тех, кто только въезжает во фронтенд. Часто въезжает за деньгами. Так вот: в Svelte денег нет. Работы на нём тоже нет. И самое интересное — опыта на нём тоже не будет. Мантра «у нас есть настоящая реактивность и небольшой размер фреймворка» на самом деле означает «во фреймворке нет кучи типовых фич, а осваивать большую тройку вам все равно придётся». Так вот, заклинаю всех входящих в мир фронтенда, не ведитесь на хвалебные статьи. Не ведитесь на эту чушь! Фреймворк без экосистемы в 2020 году целящий на место большой тройки — это мёртвый фреймворк.
Когда про реакт в начале его популярности писали даже в Спидинфо, было всё то же самое, только с одной разницей — реакт решал какие-то проблемы разработки. Даже если не решал, то он смог родить вокруг себя за 3 года такую мощную экосистему, которая перечеркнула все его недостатки. Я ненавижу реакт, но понимаю, что если не буду использовать его, то попросту проиграю в эффективности тем, кто его использует, имея доступ ко вкуснейшим компонентам и библиотекам. Не используя Svelte я не теряю ничего.
Сам подход минимализма, который предлагает Svelte недостижим в принципе. Я не могу представить ситуацию когда целесообразно будет использовать не чистый JS или VueJS, а Svelte. Vanilla JS как преимущество, когда тайпскрипт стал уже практически стандартом для написания сложных проектов? Попытки выиграть в размере кода на мелком проекте, где большая часть это сторонние компоненты и библиотеки? Выиграть на размере фреймворка в по-настоящему крупном проекте? Отсутствие Virtual DOM, но взамен него костыль в виде очередного уровня транспиляции заложенной в саму суть фреймворка? Write less code? При нулевой экосистеме? Причем заметьте, что в примерах на сайте рассматриваются именно крохотные компоненты, на которых разница достигается только за счет того, что в Vuejs и React есть какая-то инициализация компонента или описание редьюсеров, которые сделаны не просто так. Дальше там сравнивают количество символов в простейших трёхстрочных примерах. Возможно этим делается намёк, что под «write less code» подразумевается предложение в принципе не писать ничего длиннее нескольких строк. Однако это снижает и без того приступно низкую область применения Svelte для реальных проектов.
Говорят, что у Svelte большое русскоязычное коммьюнити. Я его не вижу, вижу только евангелистов, каждый из которых проповедует за десятерых. Везде одна и та же аргументация — рассмотрение corner cases, и радость от того что у нас не как в VueJS/Angular/React. Тот факт, что 3 фреймворка по каким-то причинам вымучали именно такие подходы, игнорируется. Тот факт, что за несколько лет фреймворк не смог достигнуть популярности большой тройки тоже игнорируется. Хотя он мог бы принять во внимание чужие ошибки и выехать только за счет этого. Контраргументы уровня — вы просто не смогли разобраться со Svelte — это вообще за гранью юмора. Люди, которые работают с ангуляром и реактом не могут разобраться в с маленьким простым Svelte? Наверное тут дело в самом Svelte. Или в том, что там в принципе не в чем разбираться, потому что ничего стоящего нет.
Когда им задают вопрос «зачем нужен ваш фреймворк, который не взлетает уже 3 года при имеющейся тройке?», то в ответ слышны лишь шутки про то что на вкус все фломастеры разные. Это достойный ответ для кучи технологий в ИТ, но только не для фронтенда и только не для реактивных фреймворков. Еще 5 лет назад этого добра было навалом, всех уже и не упомнишь. Но как-то эволюционно мы пришли к тройке лидеров, к тому что нужно отрасли. Вокруг лидеров сформировалось коммьюнити и экосистема. Мы пришли к набору фломастеров, каждый из которых солёный и легко кладется за воротник(хоть это и тема для другого разговора). Суть в другом — к фломастерам есть определённые требования, которым надо соответствовать.
Svelte не соответствует этим требованиям. За время существования Svelte, сравнимое со временем существования других фреймворков до получения ими признания, вокруг Svelte не сложилось ничего. Ах, за тройкой стоят корпорации? Господа, вы вроде как претендуете на то что у вас замечательный фреймворк. Почему вы не можете найти финансирование для своего замечательного фреймворка? У вас же на сайте куча логотипов в секции Who's using Svelte?. Может с ним что-то не так? Вы уверены, что если его допилить, то получится не второй VueJS только сырой?
Вы уверены, что в праве советовать этот фреймворк так категорично? Фронтенд — это область куда каждый день приходят новые люди без опыта. Они не в состоянии оценить масштаб ненужности Svelte. Они увидят хвалебные статьи где умные дядьки с серьёзным видом рассуждают о том какой там замечательный проброс событий, компилятор и т.д. Что интересно с академической точки зрения, но не с практической. Они подумают что с этим стоит связываться, потратят свое время и останутся ни с чем. А выдавая пачками статьи про то, как замечательно на Svelte можно сделать какую-то хрень, которую можно так же сделать на нормальных фреймворках, вы подкладываете начинающим людям огромную свинью. У меня всё.
amarao
Как человек, крайне далёкий от JS, из всей статьи я почерпнул потрясающе правильную идею: "что вы потеряете, если проигнорируете X?". Для хобби-областей это не применимо, а вот к рабочим инструментам — просто универсальный принцип.
JustDont
Тут главное иметь в виду горизонт такого игнорирования, иначе можно, скажем, оказаться в 2020 году программистом десктопных приложений на C (без ++).
Но это, безусловно, не касается узких местячковых инструментов, типа как о чем речь в статье, тут не поспоришь — другое дело, что идеи этих узких местячковых инструментов могут потом прижиться в гораздо более интересном контексте.
А так-то да, мысль очень хорошая. Во всем фронтэнде «кита» только два, причем второй во многие разы меньше первого. Первый — производители браузеров. На всё, что становится стандартом и реализовывается в браузерах — нужно обращать наипервейшее внимание, чисто потому, что вы это забесплатно получите вместе с браузером, причём еще и оттестированное сотнями тысяч юзеров. Второй — самые распространенные библиотеки (не только фреймворки для рендера).
Всё остальное — на многие порядки менее важно этих двух величин.
osmanpasha
офтопик: а на чем в 2020 пишут десктопные приложения? Просто, читая хабр, кажется, что десктопная разработка умерла на 100% — никаких новостей, никаких статей о технологиях, софте, всё про веб и мобильную разработку. Нет, в общем, обычных путей узнать, на чем сейчас пишут десктопные приложения.
iroln
К сожалению, всё чаще на Electron.
В остальном всё без изменений: Qt, GTK, WPF…
KReal
А кто-то и на WinForms…
hardex
Я все жду, когда же MS так полюбит WPF, как они полюбили ASP.NET…
А до тех пор есть хорошие фреймворки, а еcть BooleanToVisibilityConverter
JustDont
Да как обычно, на всем пишут. Но относительно мощный тренд нынешнего времени — писать на электроне. Просто потому, что таким образом одна и та же кодовая база может использоваться и в вебе, и в десктопе — удешевление разработки просто радикальнейшее.
Впрочем, минусов у такого подхода тоже немало, в частности, про нормальное управление ресурсами (даже не ручное выделение памяти, а просто что-то достаточно предсказуемое) можно забыть.
firk
Как будто это что-то плохое.
AnthonyMikh
Конечно, плохое. В 2020 году смысла начинать новый проект на C нет.
KanuTaH
Сильное утверждение. Смотря что за проект. В том же XNNPACK от гугла, который вышел примерно прошлой осенью, большая часть кода (почти половина) написана на C.
hardex
Речь о десктопе.
AnthonyMikh
Всё ещё не понимаю, почему это нельзя было написать хотя бы на C++. Чтобы не освобождать память руками и полагаться на RAII. Чтобы возвращать сильно типизированные статусы ошибок, которые не смешиваются с обычными числами. Чтобы писать обобщённый код, не прибегая к помощи внешнего препроцессора. Да блин, хотя бы ради того, чтобы не писать
xnn_
в начале имени каждой функции.И это всё при том, что C++ в принципе далеко не лучший язык.
KanuTaH
Вероятно, требования к производительности были таковы, что всякие сюрпризы от компиляторов наподобие кривой работы std::min() с initializer_list были бы крайне нежелательны. Чем меньше в языке абстракций, тем меньше требований к компилятору по части удешевления этих абстракций или сведения их к zero-cost. А термин «лучший язык в принципе», как по мне, вообще смысла не имеет. Каждый отдельный язык может быть лучшим (ну, или не лучшим) выбором только в какой-то конкретной ситуации. Нельзя сказать, что «C++ всегда лучше, чем C» так же, как нельзя сказать, что «C всегда лучше, чем ассемблер» или «условный C#, раст или хаскель всегда лучше, чем C++».
AnthonyMikh
RAII, enum class, шаблоны и пространства имён на производительность в рантайме не влияют.
Да не то чтобы. Плюсовый
std::sort
на шаблонах работает быстрее сишногоqsort
.KanuTaH
Вот опять сильное утверждение. Навскидку — тот же RAII, например, очень даже влияет на возможность оптимизации хвостовой рекурсии, потому что после на первый взгляд «хвостового» рекурсивного вызова на самом деле еще идут неявные вызовы деструкторов, поэтому могут потребоваться специальные трюки. В обсчем, не все так просто — как это обычно, впрочем, и бывает.
AnthonyMikh
А если память освобождать руками, это типа проще?
KanuTaH
Это не вопрос «типа проще», это вопрос контроля. Как я уже выше написал — чем меньше всяких абстракций, тем меньше вероятность, что компилятор что-нибудь запорет. Иногда это бывает настолько важно, что абстракций приходится избегать, даже если они, на первый неискушенный взгляд, безобидны и «на производительность в рантайме не влияют».
AnthonyMikh
Так если память выделять и освобождать руками, то будет точно такой же выбор, ставить вызов free до рекурсивного вызова или после, с такими же последствиями. Не понимаю, почему вы считаете это преимуществом. Тем более что RAII работает и для более сложных форм потока управления, когда отследить самому, в какой момент память становится ненужна, уже не так просто.
KanuTaH
Так в том-то и дело, что так ты сам выбираешь, где ставить free(), и делаешь это в явном виде, а с RAII этим неявно занимается компилятор. В результате ты можешь получить деградацию на ровном месте, просто добавив в существовавшую рекурсивную функцию любой объект с деструктором, даже самым что ни на есть тривиальным, и даже не заметить этого, пока не посыпятся багрепорты. В ряде сценариев это может быть просто-напросто недопустимо. Абстракции — это хорошо и даже замечательно, но… не все, не везде и не всегда.
0xd34df00d
Так тогда прямо на асме надо. Компилятор иногда даёт сюрпризы в виде совершенно кривого шедулинга регистров или инструкций, даже если писать на голом С с интринсиками.
KanuTaH
Ну бывает, что и на асме приходится :)
0xd34df00d
Ну вот.
А для асма тоже С не обязателен, можно и на хаскеле, скажем.
KanuTaH
Новое прочтение фразы «на
фортранеасме можно писать на любом языке»? :)0xd34df00d
Не на любом, только там, где метапрограммирование норм. На плюсах у вас так не получится, например.
KanuTaH
Ну автоматический анроллинг в плюсах, наверное, не сделаешь, да. Во всяком случае, не inline.
0xd34df00d
Да, по крайней мере, пока вы не можете манипулировать со строками в компилтайме так же, как в рантайме (например, чтобы их распарсить буст-спиритом каким-нибудь, и создать на базе этого новый набор строк).
Но вообще я там зря выбрал такой подход — это во многом proof-of-concept, по-хорошему надо сделать всё не тупыми строками, а обычными типизированными термами (типа
mov :: (Source s, Destination d) => Command 2 s d
или что-то такое). Можно даже добавить типобезопасности и явного указания SIMD-расширений, чтобы было типаи чтобы там всё при компиляции тайпчекалось и проверялось, и при этом потом в итоге генерировался обычный асм.
Учитывая, что разные команды в разных instruction set'ах поддерживают разные регистры, тут можно здорово так поупражняться во всякой наркомании на типах.
Можно потом прикрутить ещё свободную монаду поверх
Command
, и сделать. короче, чтобы оно там тестировалось, или симулировалось при отсутствии поддержки архитектуры на проце (в тех же тестах), или там какие-то показатели latency/throughput считались, ууух можно развернуться.Так, что-то меня куда-то не туда понесло, не нравится мне, куда это идёт.
KanuTaH
О да. Настоящий асм.
0xd34df00d
Ненене, я про тесты говорю. Вот написали вы какой-то алгоритм в версии SSE4.2, AVX2 и AVX512. Тогда вы можете написать
теоремытестыгде
interpret
берёт ваш асм и просто его интерпретирует согласно какой-то модели выполнения, так, что вам на вашем проце не нужен никакой AVX2 или AVX512.А в продакшене у вас будет условное
без всякой интерпретации и симуляции.
KanuTaH
Ну, не знаю. Получается, эти тесты будут тестировать не столько код на асме, сколько по факту этот interpret. А вдруг он что-нибудь не учтет, какие-нибудь branch delay slots например?
0xd34df00d
Вопрос корректности модели, естественно. Но вот я почему-то думаю, что суммарная сложность алгоритмов на асме сильно выше суммарной сложности моделей, поэтому закодить и проверить модель разумно.
А так-то и баги в процессорах бывают.
KanuTaH
Ну вот да. И их придется любовно эмулировать. Точнее, не то чтобы совсем баги (их обычно все-таки стараются исправлять), а так называемые misfeatures.
0xd34df00d
А зачем писать десктопные приложения на С?
jaiprakash
Например, общая кодовая база с микроконтроллерами.
0xd34df00d
В таком случае и на плюсах можно.
stalkerg
Ну если вы пишите под линукс то будете использовать GTK который на Си. (или Qt на C++ но это зависит от многих критериев)
0xd34df00d
Или gtkmm, который на плюсах, или одни из десятка байндингов gtk к хаскелю, например.
stalkerg
это все байндинги внутри в любом случае будет Си. Я бы тогда Python бы взял но иногда это плохо. Так что даже новые приложения для Gnome и GTK пишут на чистом Си.
0xd34df00d
Ну так байндинги уже есть, и сишный клей там уже написан. Вам эти байндинги самому писать не надо.
firk
Затем же, зачем на нём пишут системный софт.
0xd34df00d
А зачем на нём писать новый системный софт?
locutus
Если такой выбор будет давать конкурентные преимущества в такой-то отрасли в такой-то стране для такой-то фирмы — почему бы и нет?
justboris
Без конкретного примера такой аргумент звучит как демагогия (извините за влезание в тред).
0xd34df00d
Понятно, что если у вас вокруг миллион дешёвых программистов на С, которые сидят без работы, но при этом способны писать стабильный, безопасный и безбажный код, а разработчиков на других языках нет, то С будет выгоднее.
Вопрос в том, что реализуется на практике.
firk
Надёжность, отсутствие неявного оверхеда, полная предсказуемость в плане двусторонней конвертации C <-> asm (или другими словами, можно рассматривать C как набор синтаксических конструкций для компактного и удобного представления асм-кода, а не для манипуляций компиляторными абстракциями).
Для тех, кто всё это умеет использовать, разумеется, а некоторые могут хоть на пхп пытаться системный софт писать.
Sybe
если все будут пользоваться такой мыслью, то откуда появятся «самые распространённые библиотеки»?
я имею в виду, что библиотеки и становятся популярными, когда кто-то первый их использует и рассказывает другим
JustDont
Вы забыли про второй необходимый пункт — библиотека еще должна решать важные проблемы удобным образом. Вот тогда после «рассказывает» и будет происходить популяризация — другие люди начнут тоже этим пользоваться.
Рассказывание от евангелистов (как было тут на хабре со svelte) имеет под собой ту маленькую проблемку, что евангелисты обычно не используют субъект своих рассказов для решения реальных проблем.
Sybe
Павел Малышев, главный евангелист Svelte в России, использует Svelte на своей работе уже примерно 3 года
в одной из статей он рассказывает, почему именно Svelte, а не условный React (ответ: на телевизорах и кассах React тормозит, Svelte – нет)
JustDont
Я знаю, я это всё читал. PaulMaly ни одной статьи не написал с позиции «смотрите, мы вот тут решали вот такую проблему, и у нас вышло вот так с помощью svelte». Даже когда он касался своего опыта — это было написано в обратной последовательности: «смотрите, какой крутой svelte, и верьте мне, потому что я его тут юзаю для телевизоров и касс». Короче, не рассказы о реальных проблемах, а реклама с упоминанием реального опыта ради авторитетности.
И вот если рассматривать с точки зрения реальных проблем, то вышло бы так: «на телевизорах и кассах React тормозит, а множество других легковесных решений, в частности, svelte — нет». А дальше сравнивать эти решения, выбирать из них по списку критериев, вот это всё, что делают нормальные люди, когда им надо проблему решать, а не пиарить что-то заранее определенное.
Ну и в любом случае, от разбора конкретно такой проблемы — особо большого выхлопа и не будет, потому что сколько-сколько в % от всего фронтэнда пишется для телевизоров и касс?
stalkerg
Было бы классно если вы написали. Мы перед выбором Svelte пробовали Инферно и прекат но в итоге остановились на Svelte. Но это не те изыскание по которым можно было бы статью написать.
JustDont
Я остановился на вебкомпонентах и обвязке для них в лице LitElement (можно было еще Stencil брать, просто душа к jsx не лежала).
Svelte не взял потому, что во-первых, как вы сами ниже написали, «cинтаксис у всех трех разный и не совместим» — получить в проде устаревшую версию потому, что завтра кому-то захочется несовместимый Svelte v4 мне не улыбается совсем. Во-вторых — нет родной поддержки тайпскрипта, и сопротивление тайпскрипту по идеологическим причинам в стане svelte меня очень сильно напрягает, потому что это в чистом виде приоритет «шашечек» над «ехать». В проде я хочу строго обратного.
Ну и в-третьих, меня напрягает, что компонент svelte (если не билдить в веб-компоненты, а если билдить — то svelte тоже не нужен, проще сразу делать веб-компоненты) толком не доступен в рантайме для низкоуровневого доступа (там, в DOM влезть, например, или подобные вещи), и коммьюнити на обсуждения этого реагирует через «а вы просто так не пишите» — это всё прекрасно, когда всё пишется с нуля на svelte и так делать действительно не нужно, но не когда ты прикручиваешь в проект готовые библиотеки и решения, в том числе и довольно старенькие (но прекрасно работающие)
Этот момент чисто технический, и его можно бы так или иначе было обруливать (или предложить API), если б других проблем не было. А так — даже и не хочется заводиться.
mayorovp
Так вроде же use есть?
JustDont
Это половина проблемы, переход «svelte -> легаси». Есть еще «легаси -> svelte». Я что-то ничего красивого тут не придумал.
mayorovp
А в обратную сторону-то в чём сложность?
JustDont
Я вот сейчас смотрю документацию, и правда не вижу ничего сложного. Но на чём-то таком я тогда споткнулся — вполне вероятно, что за полгода с лишним я уже путаю детали, и загвоздка была в другом.
mayorovp
Тогда, пожалуйста, всё-таки попытайтесь вспомнить детали перед тем как снова говорить про проблемы взаимодействия svelte и legacy. Потому что я вижу прямо противоположную картину: именно простота встраивания во что угодно является сильной стороной svelte.
JustDont
Да, прошу прощения. Я поднял старую рабочую переписку, и в итоге выяснил, что тогдашняя техническая беда со svelte вообще даже близко не стояла к связи с легаси: я тогда взял v3.16.0, начал экспериментировать с кодом с целью выяснить, можно ли имеющееся перенести в svelte — у нас было немного кода, который можно было бы и перенести — и быстро влетел в проблемы со слотами, которые в 3.16 были здорово поломаны, вплоть до ошибок компиляции того, что вообще-то должно было компилироваться, в каких-то минорных версиях, вроде б в 3.16.1.
Слоты там к концу декабря починили, судя по гитхабу, но вместо результативных экспериментов я получил борьбу с фреймворком, и очков svelte это не добавило. Коллеги, глядя на мои терзания, к середине декабря сказали — «ну и да ну её нафиг тогда».
mayorovp
Да, это больше похоже на правду. Хотя лично меня "борьбой с фреймворком" не испугать, потому что мне приходилось бороться с каждым фреймворком который я использовал, так что я уже привык :-)
JustDont
Ну, бороться — это нормально, идеального ничего нет. Сложнее — когда берешь штуку именно ради слотов, потому что в текущем техстеке всё устраивает, кроме этого. А тут оказывается, что в штуке слоты сейчас поломанные.
Еще сложнее — когда надо убедить других людей внимательно взглянуть на штуку, а они вместо красивых решений видят ошибки компиляции.
justboris
Вы про этот тикет говорите? или у вас что-то другое было?
JustDont
Нет, я ковырялся около недели в начале декабря, а значит на этот баг не мог попасть. У меня сначала странно вела себя передача параметров в слоты через let, а потом вышла 3.16.1, и… там мой код вообще перестал компилироваться. Через несколько дней это пофиксили, но к тому моменту идея «а давайте перепишем наши небольшие компонентики на svelte» уже была коллегиально зарублена.
Скорее всего у меня вот это вот не работало.
justboris
Ясно. В общем, это еще раз подтверждает, что Svelte рановато нацепил на себя лычку "v3". По уровню стабильности это скорее "v0.3"
PaulMaly
Из вашего комментария можно сделать 2 вывода:
Либо вы утверждаете, что это был не случайный баг, а запланированный breaking change в минорной версии (что конечно недопустимо). Либо утверждаете, что в других фреймворках не бывает случайных багов, которые затесались в минорах. И то, и другое, имхо, что-то на грани фантастики.
JustDont
Я очень советую вам попробовать себя в написании фантастики и фентези. Возможно, у вас это будет получаться даже лучше, чем программирование.
PaulMaly
Вы ушли от ответа. Так это был запланированный breaking change в минорной версии или случайный баг?
JustDont
Извините великодушно, но у меня нет желания продолжать общение с человеком, который несет очевидный бред, и более того, продолжает — даже после толстого намёка на то, что не стоит так делать.
PaulMaly
Не взяли и не взяли. Дело ваше, проблем нет. Если вы умеете оценить свои потребности и риски, это отлично. У меня другой опыт, мы наоборот не взяли LitElement вот по каким причинам: 1) веб-компоненты не везде, полифилы работают коряво; 2) LitElement в сравнении со Svelte намного более громоздкий; 3) Svelte в любой момент можно скомпилировать в web components, на случай если они захавают мир (очень сомневаюсь).
Мой доклад по мотивам изысканий: «Web Components, или Туда и обратно». Отличная статья по Web components: «Почему я не использую веб-компоненты»
Есть такое дело, но я ни раз уже отвечал почему так произошло — это были поиски аутентичного подхода в рамках агрессивной среды навязанных мнений. Считаю что поиски окончены. Интересно то, что мы сами можно сказать «пострадали» от этого и пришлось заложить некоторые время на реврайт приложения со Svelte 2 на Svelte 3. В итоге мы не пожалели, реврайт прошел без проблем и на половину был автоматическим.
Нет никакого сопротивления. Есть мое мнение что TS нужен не всем, которое я время от времени высказываю и есть объективные причины почему внедрить TS в Svelte не просто. Большая часть этих причин связана с самим TS. Если бы их не было, Vue и Svelte давно бы уже обзавелись поддержкой TS, а Angular-у не понадобилось бы делать форк. Даже тот факт, что сам Svelte написан на TS говорит о том, что никакого сопротивления нет.
Прозвучит странно, но вы реально не разобрались. Наоборот, то что Svelte использует обычный DOM есть все средства делать с ним что угодно. Кроме встроенных рефок, всевозможных биндингов и оберток-экшенов, можно просто манипулировать им из DOM API. Другое дело, увлекаться этим не стоит.
PaulMaly
Предлагаю оставить стиль и предпосылки повествования его авторам. Есть много других статей, от других авторов в хабе Svelte, стиль которых возможно придется по душе. Да и моих собственных статей о Svelte не там много на самом деле. 50/50 это переводы, а уж в их повествование лезть дело вообще не благодарное.
На самом деле это восходящий тренд, но пока он дошел не до всех. Да и не стоит дискриминировать юзеров более традиционных устройств, они также хотят быстрые и качественные приложения.
JustDont
Не стоит свою нелюбовь того же реакта представлять как «дискриминацию юзеров». Реакт топ-1 не просто так, а в том числе и потому, что на более традиционных устройствах работает достаточно хорошо, чтоб никто не считал себя дискриминированым.
За исключением, конечно, случаев отстрела разработчиками своих же ног. Но это можно сделать любыми инструментами.
PaulMaly
Если вы правда так считаете, то это ваше право. Лично я вижу все больше переходов с React на другие решения именно по причине что он работает не так уж и хорошо.