Комментарии 130
Все супер, но real-life примеров мало.
Например, я был бы рад SPA с jwt авторизацией используя SSO и Google/FB
Вообще это отличная идея! Можете дать ссылку на real-life пример подобного типа для React или Vue? Быть может я бы заморочился с этим для Svelte.
Уже есть такой в проекте realworld
Ну это не интересный пример. Там Svelte еще в том году почти всех порвал: A Real-World Comparison of Front-End Frameworks with Benchmarks .
К тому же там нет ни JWT, ни SSO.
К тому же там нет ни JWT, ни SSO.
НЛО прилетело и опубликовало эту надпись здесь
Когда-то рынком были восстребованы BackboneJS, AngularJS и ExtJS. Как думаете, те кто в 2013 году стали изучать React сильно пожалели об этом?
Ну, «реактами» в итоге стали очень немногие, по пальцам одной руки пересчитать можно. А сколько умерло по дороге… Так что теория вероятности, наверное, все же не на вашей стороне. :)
НЛО прилетело и опубликовало эту надпись здесь
Как думаете, те кто в 2013 году стали изучать React сильно пожалели об этом?
Если это были джуны, которые в итоге не смогли найти работу на React в 2013, то предполагаю, что да, пожалели.
Разработчику необходимо изучать лучшие практики. То, что сегодня востребовано рынком, завтра умрет.
Плюс поставил за кунштюк.
Для закона Мура нужна адаптация под JS фреймворки
У стороннего от разработки человека может сложиться ощущение что Vanilla JS это какой-то Rocket science, чуть легче чем удаленно перепрограммирование марсохода. На самом деле текущий DOM API и его поддержка браузерами находятся на таком хорошем уровне, что можно обезьяну научить за неделю писать простенькие скрипты, которые способны решать большинство типичных задач. Уже не надо помнить конструкции вроде
Сегодня это все стало гораздо проще. Сложновато разве что найти достойное актуальное руководство для начинающего среди огромного многообразия. Зато полученные знания не превратятся в тыкву через пол года.
Существует еще одна проблема для новичка, решившего сразу начать с фреймворков. Современные фреймворки в основном используют декларативный подход. Это сильно затрудняет переход от HelloWorld к решениям реальных задач. Императивный подход проще для новичка за счет отсутствия внутренней магии.
.main {
display: inline-block;
*display: inline;
zoom: 1;
}if (!window.addEventListener) { ... }Сегодня это все стало гораздо проще. Сложновато разве что найти достойное актуальное руководство для начинающего среди огромного многообразия. Зато полученные знания не превратятся в тыкву через пол года.
Существует еще одна проблема для новичка, решившего сразу начать с фреймворков. Современные фреймворки в основном используют декларативный подход. Это сильно затрудняет переход от HelloWorld к решениям реальных задач. Императивный подход проще для новичка за счет отсутствия внутренней магии.
Современные фреймворки в основном используют декларативный подход.
Я бы так сильно не утверждал. Ни реакт, ни ангуляр, ни вью — какой-то особой декларативщиной не страдают. Ей часто страдают авторы примеров и всяких тудушек — «Ой, нам надо параметры передать? Ну давайте навернём сверху компонент!»; «Ой, нам надо куда-то логику приложения положить? Давайте положим её в компонент и прибьем гвоздями к хукам жизненного цикла!». В то время как сам фреймворк ничего этого не диктует, и выносить логику из компонентов везде можно без особого труда. MVC в общем-то не зря придумали, и зацикленность людей на V — это не от большого ума или опыта.
Ну а декларативность в той мере, чтоб какая-то шаблонизация была и тому подобное — это неизбежность, потому что голый императивный код очень быстро перестаёт масштабироваться и поддерживаться. Знать, как там руками подёргать DOM — для общего развития пригодится, но вот именно в реальных задачах — скорее всего нет.
С Vanilla всё хорошо, пока это действительно задачки для новичка. Как только она начинает перерастать во что-то покрупнее, уже начинается неразбериха в коде и прочие трудности. В этом месте разарботчик либо пишет свой фреймворк, либо выбирает из существующих. Нужно рассматривать фреймворк не как набор всевозможных функций, а как средство для структурирования разработки и мыслей, которое существенно облегчит создание большого проекта, особенно, если разработчик не один, а целая команда.
В таком контексте, Svelte — это просто средство для написания ванильного Javascript, но в хорошо структурированном виде.
А так, конечно, соглашусь, что начинать обучение всё-таки стоит с основ. Я жене в декрете купил книжку «JavaScript для детей» — когда освоит, покажу как применить свои начальные знания в Svelte.
В таком контексте, Svelte — это просто средство для написания ванильного Javascript, но в хорошо структурированном виде.
А так, конечно, соглашусь, что начинать обучение всё-таки стоит с основ. Я жене в декрете купил книжку «JavaScript для детей» — когда освоит, покажу как применить свои начальные знания в Svelte.
Как у этого «лучшего на свете нефреймворка» обстоят дела с тайпскриптом?
Я правильно понял, раз это единственный ваш вопрос в контексте статьи, вы считаете эта самым важным для новичков?
А вы считаете этот «магически исчезающий фреймворк» пригодным только в роли букваря для новичков?
PS оно вроде как на TS напиисано github.com/sveltejs/svelte/tree/master/src но только частично (например каталоги internal и motion на JS). Надеюсь JS со временем ичезнет из проекта совсем. Кроме этого github.com/sveltejs/svelte/blob/master/tsconfig.json меня не слишком впечатлил. Но автор вроде как принимает идеи TS и можно ожидать что дела наладятся github.com/sveltejs/svelte/issues/1639#issuecomment-442974572
PS оно вроде как на TS напиисано github.com/sveltejs/svelte/tree/master/src но только частично (например каталоги internal и motion на JS). Надеюсь JS со временем ичезнет из проекта совсем. Кроме этого github.com/sveltejs/svelte/blob/master/tsconfig.json меня не слишком впечатлил. Но автор вроде как принимает идеи TS и можно ожидать что дела наладятся github.com/sveltejs/svelte/issues/1639#issuecomment-442974572
А вы считаете нормальным, что уже нельзя написать статью про javascript без обязательного вопроса о typescript в комментариях, даже если эта статья для новичков?
Если бы всем поголовно во фронтенд сообществе нужны были бы статические типы, они давно бы уже стали частью стандарта. Раз этого не происходит, значит нужны они далеко не всем. А если бы я хотел написать/перевести статью про typescript, я бы отметил ее соответствующим тегом.
typescript !== javascript и давайте закончим на этом.
Если бы всем поголовно во фронтенд сообществе нужны были бы статические типы, они давно бы уже стали частью стандарта. Раз этого не происходит, значит нужны они далеко не всем. А если бы я хотел написать/перевести статью про typescript, я бы отметил ее соответствующим тегом.
typescript !== javascript и давайте закончим на этом.
Если бы всем поголовно во фронтенд сообществе нужны были бы статические типы, они давно бы уже стали частью стандарта.Стандартизирование типизации в JS на данное время не иммет смысла потому что там постоянно нужно что-то допиливать, развивать и улучшать так как нельзя просто так взять и сразу типизировать всю мощь javascript. Посмотрите для примера как активно развивается typescript.
Если бы всем поголовно во фронтенд сообществе нужны были бы статические типы, они давно бы уже стали частью стандарта.Далеко не все принимают решение об использовании строгой типизации или отказе от нее на основе фактов и логики. Очень часто это просто предрассудки из серии «типы замедляют разработку», «типы — это сложно», «типы мешают мне самовыражаться в коде» и прочее. Так что их внедрение не происходит по другим причинам: даже если 90% за, оставшиеся 10% могут орать так громко, что инициатива пойдет ко дну.
Далеко не все принимают решение об использовании строгой типизации или отказе от нее на основе фактов и логики.
Полностью согласен. Я например, начинал с разработки под C++, так что довольно неплохо представляю себе, что такое типы, работа с указателями и ООП на классах. При этом я совершенно не считаю, что статическая типизация на фронтенде нужна настолько, чтобы со всех статьях про Javascript начинать обсуждать Typescript. А те кто считают, часто имеют бекграунд где-то в районе Java/C#, так чему тогда удивляться?
Очень часто это просто предрассудки из серии «типы замедляют разработку», «типы — это сложно», «типы мешают мне самовыражаться в коде» и прочее.
Именно так я и думаю. Большинство тех, кто сейчас внедряет TS не до конца понимают зачем это нужно именно их проекту. Просто «на хабре пишут что без ts фронтенд будет глючить» вот наиболее частый довод. А дальше мы получаем доклады от Яндекса типа этого.
Я например, начинал с разработки под C++, так что довольно неплохо представляю себе, что такое типы, работа с указателями и ООП на классах.
Боюсь опыт работы с языком тридцатилетней давности не может давать вам представление о работе с современными статически типизированными языками.
А те кто считают, часто имеют бекграунд где-то в районе Java/C#, так чему тогда удивляться?
Те, кто считают, имеют опыт разработки и поддержки больших проектов, не помещающихся в одну голову целиком.
Боюсь опыт работы с языком тридцатилетней давности не может давать вам представление о работе с современными статически типизированными языками.
А вы не бойтесь, последняя версия стандарта вышла в 17-м году. Но вообще да, наверное лет 10 назад с ним и работал в послединий раз. Расскажете, что такого я упустил за это время, что заставит меня поменять свою точку зрения на статическую типизацию во фронтенде?
Те, кто считают, имеют опыт разработки и поддержки больших проектов, не помещающихся в одну голову целиком.
То есть по-вашему это как-то зависит от языка? Вообще, я заметил что такие люди часто ходят «в чужой монастырь со своим уставом». Хорошо ли это для фронтенда? Не думаю.
А вы не бойтесь, последняя версия стандарта вышла в 17-м году.
Основа его дизайна с тех пор почти не поменялась. Даже препроцессор до сих пор не выпилили.
Расскажете, что такого я упустил за это время, что заставит меня поменять свою точку зрения на статическую типизацию во фронтенде?
Видимо вы пропустили рассвет и закат JsDoc. Это когда описание типов занимало в 2 раза больше строк, чем собственно код, чтобы IDE хоть что-то понимала в том, что нафигачил программист.
То есть по-вашему это как-то зависит от языка?
Слышали про гипотезу Сепира-Уорфа?
Вообще, я заметил что такие люди часто ходят «в чужой монастырь со своим уставом». Хорошо ли это для фронтенда?
Я как бы больше 10 лет во фронтенде. Уж наверно я в своём монастыре. Но это не точно.
Видимо вы пропустили рассвет и закат JsDoc. Это когда описание типов занимало в 2 раза больше строк, чем собственно код, чтобы IDE хоть что-то понимала в том, что нафигачил программист.
А как это связано со статической типизацией в языках со статической типизацией? Кроме того, JsDoc вполне себе и сейчас работает и используется совместно с ts-check.
Слышали про гипотезу Сепира-Уорфа?
Слышал про то, что когда есть что сказать и аргументировать, люди так и делают. Могу интерпритировать ваш пример так: именно то, что некоторые языки (фреймворки/что угодно) написаны сложно и концепции лежащие в их основе сложны, они фомируют у людей соответствующее восприятие, фактически заставляя решать простые задачи сложными способами.
Я как бы больше 10 лет во фронтенде. Уж наверно я в своём монастыре. Но это не точно.
Это точно, что не точно. Особенно, учитывая насколько популярны ваши решения во фронтенде. Вы там свой «геморрой» то вылежили? Не похоже что-то.
Это связано со статической типизацией в динамически типизированном языке. Что лишний раз показывает, что без неё никак.
Скорее о том, что разруха в языке порождает разруху в головах.
Ага, давайте измерять качество решения популярностью.
Скорее о том, что разруха в языке порождает разруху в головах.
Ага, давайте измерять качество решения популярностью.
Это связано со статической типизацией в динамически типизированном языке.
Стоп, вы мне писали что мои знания насчет статической типизации для статически типизированного языка устарели. Напомню, я писал про C++. Что мол сейчас то статическая типизация ого-го и я сразу захочу ее иметь на фронтенде. Ну и? Что такого супер нового мне дает Typescript по сравнению с C++ в плане типизации?
Что лишний раз показывает, что без неё никак.
Нет, это лишь показывает, что крутить статическую типизацию к динамически типизированному языку может быть больно. Нашли чем удивить. Но я и говорю ровно об этом, не нужна она для абсолютного большинства фронтенд проектов. Для энтерпрайзов, да пожалуй. Там выгоднее всего сейчас Angular смотрится. Но далеко не все пишут энтерпрайзы.
Скорее о том, что разруха в языке порождает разруху в головах.
Это работает в обе стороны. И видно даже на вашем примере.
Ага, давайте измерять качество решения популярностью.
А мы ничего не говорили про качество. Лишь про то, насколько вы человек из фронтенда. Сложно считать себя собакой среди собак, если ты мяукаешь, а все вокруг гавкают.
НЛО прилетело и опубликовало эту надпись здесь
Что такого супер нового мне дает Typescript по сравнению с C++ в плане типизации?Воу-воу, вы серьезно?
- Структурная типизация против номинальной
- Частичная типизация
- Типы-пересечения и типы-объединения (алгебра типов)
- Типы-отображения
- Условные типы
- Тип this
- Вывод типов на основе анализа потока управления
Вижу вы очень старались, но увы не получилось. Практически все из перечисленного либо есть в C++, либо просто решается по-другому, либо полная ересь в контексте языка.
Зачем все это на фронтенде, кроме разве что очень крупных проектов, все еще не ясно.
Еще раз предлагаю вам посмотреть доклад: Цена типизации. По-моему, там довольно доступно рассказано, когда все это действительно нужно, а когда является лишь лишним усложнением.
Зачем все это на фронтенде, кроме разве что очень крупных проектов, все еще не ясно.
Еще раз предлагаю вам посмотреть доклад: Цена типизации. По-моему, там довольно доступно рассказано, когда все это действительно нужно, а когда является лишь лишним усложнением.
Вкратце для тех, кому лень смотреть сорокаминутное видео…
Чел пол часа с пеной у рта разглагольствует о том, что статическая типизация не нужна. А потом, без тени взаимоисключающих параграфов на лице, предлагает использовать ts-check (то есть статическую проверку типов) полагая, что этот ts-check найдёт все ошибки (афайк не найдёт и половины из-за вылезающего тут и там неконтролируемого any). А под конец предложил вообще писать тайпинги для своего JS кода в отдельных d.ts файлах.
Чел пол часа с пеной у рта разглагольствует о том, что статическая типизация не нужна. А потом, без тени взаимоисключающих параграфов на лице, предлагает использовать ts-check (то есть статическую проверку типов) полагая, что этот ts-check найдёт все ошибки (афайк не найдёт и половины из-за вылезающего тут и там неконтролируемого any). А под конец предложил вообще писать тайпинги для своего JS кода в отдельных d.ts файлах.
Вкратце для тех, кому лень читать ваш длинный комментарий…
Вы как всегда самый умный и все понимаете. Все вокруг дураки, ниче не шарящие и непонятно как вообще их в Яндекс взяли.
В целом все тоже самое, что мы читаем во всех ваших комментах. Единственное что мне до сих пор не понятно, а где же ваши искрометные выступления?
Вы как всегда самый умный и все понимаете. Все вокруг дураки, ниче не шарящие и непонятно как вообще их в Яндекс взяли.
В целом все тоже самое, что мы читаем во всех ваших комментах. Единственное что мне до сих пор не понятно, а где же ваши искрометные выступления?
Мои выступления тут: https://www.youtube.com/playlist?list=PLXyFFhv8ucKSC96WOd7Ju2HmEWTA3jPa5
Пытались взять на слабо, но не получилось :D
Про объектное реактивное программирование понравилось
Про объектное реактивное программирование понравилось
Мои выступления тут: www.youtube.com/playlist?list=PLXyFFhv8ucKSC96WOd7Ju2HmEWTA3jPa5
Кстати, не смотря на нашу полемику, мне понравились видео. Спасибо, много правильных идей.
Практически все из перечисленного либо есть в C++Ссылки на документацию или аргументы почему это не нужно, пожалуйста, или слив засчитан.
Зачем все это на фронтенде… все еще не ясно.Просто выразительная система типов: «А или B», «и A и B», «как A, только с промисами». Никакого рокет-сайенса.
Ссылки на документацию или аргументы почему это не нужно, пожалуйста, или слив засчитан.
Ну я попробую. Хотя я и редко пользуюсь ВСЕЙ мощью шаблонной магии C++, поэтому могу что-то не сообразить сходу, но, может, кто-то дополнит и углубит.
1. Структурная типизация против номинальной
Что-нибудь типа такого:
template<typename Iter, typename Val>
requires Input_iterator<Iter> &&
Equality_comparable<Value_type<Iter>, Val>
? То есть привязка не к имени типа, а к каким-то его свойствам.
2. Частичная типизация
Что-то типа std::any?
3. Типы-пересечения и типы-объединения (алгебра типов)
Множественное наследование и std::variant?
4. Типы-отображения
Сходу не могу придумать, аналог, да. С другой стороны, «A common task is to take an existing type and make each of its properties optional», серьезно? Common task? Не лучше построить нормальную иерархию наследования? :)
5. Условные типы
std::enable_if? Причем он не ограничен отношением extends, но и в него могет, через std::is_base_of или std::is_convertible.
6. Тип this
Не очень понял, в чем прикол в контексте C++. Возврат this? Эка невидаль. Видимо, тут ноги растут из «странностей» JS в отношении поведения this в функциях, но в C++ такие проблемы в принципе отсутствуют.
7. Вывод типов на основе анализа потока управления
Тот же std::enable_if или концепты (из первого примера, с requires) плюс перегрузки в случаях, подобных требованию «pet is Fish» к аргументам функции из примера по ссылке? Плюс typeid и dynamic_cast (в случае, если мы имеем дело с иерархией) для примеров ниже с typeof/instanceof?
Во, отлично, наконец-то разговор перешел в область фактов и обоснованных утверждений!
1. Структурная типизация подразумевает, что объект удовлетворяет интерфейсу, если у него есть все необходимые свойства. При этом на момент объявления класса объекта этот интерфейс указывать не надо. Я не знаю С++ настолько, чтобы понять ваш пример, но подозреваю, что с ним есть несколько проблем: он очень вербозный, он наверняка дает непонятные сообщения об ошибках, и без наличия в языке object literals он в целом не так полезен.
2. Если я правильно понимаю, то
3. Множественное наследование с состоянием чревато известной проблемой ромба, объединение типов такое не дает.
4. Это common task, потому что TS призван помочь обуздать хаос в существующем коде на JS, а там и функциональщина, и прототипное наследование, и манки-патчинг…
6. Это когда вы в базовом классе объявляете метод, который возвращает
В целом я верю, что на плюсах можно очень многое наворотить. Все-таки, шаблоны — это отдельный тюринг-полный язык. Но есть два значимых момента. Во-первых, плюсы изначально язык со статической типизацией и многие вещи принято изначально решать иначе. TS же наводит порядок в существующем коде на джиесе, и, судя по популярности, делает это довольно успешно. Во-вторых, стоит поставить рядом аналогичные куски кода на С++ c шаблонами\препроцессором и на TS, а также сообщения об ошибках, и многие вопросы сразу отпадут сами собой.
1. Структурная типизация подразумевает, что объект удовлетворяет интерфейсу, если у него есть все необходимые свойства. При этом на момент объявления класса объекта этот интерфейс указывать не надо. Я не знаю С++ настолько, чтобы понять ваш пример, но подозреваю, что с ним есть несколько проблем: он очень вербозный, он наверняка дает непонятные сообщения об ошибках, и без наличия в языке object literals он в целом не так полезен.
2. Если я правильно понимаю, то
std::any — это что-то типа void *, т.е. перед использованием значения вам нужно все-таки привести его к конкретному типу? Если так, то нет. Any в TS больше похоже на dynamic в шарпе. Просто вызываете методы и обращаетесь к полям, как будто вы пишете на голом джиесе и типизации не существует, а оно либо работает, либо падает в рантайме.3. Множественное наследование с состоянием чревато известной проблемой ромба, объединение типов такое не дает.
std::variant, насколько я понимаю, позволяет хранить одно значение из возможного списка, но это не то же самое, что пересечение: оно требует реализации нескольких интерфейсов одновременно. Например, можно сделать функцию, которая будет объединять два объекта в один, и тип результата будет строго выведен.4. Это common task, потому что TS призван помочь обуздать хаос в существующем коде на JS, а там и функциональщина, и прототипное наследование, и манки-патчинг…
6. Это когда вы в базовом классе объявляете метод, который возвращает
this, и при вызове его на объектах-наследниках возвращаемый тип не будет сбрасываться до базового. В плюсах это можно сделать костылем типа CRTP, а в TS поддерживается более элегантно.В целом я верю, что на плюсах можно очень многое наворотить. Все-таки, шаблоны — это отдельный тюринг-полный язык. Но есть два значимых момента. Во-первых, плюсы изначально язык со статической типизацией и многие вещи принято изначально решать иначе. TS же наводит порядок в существующем коде на джиесе, и, судя по популярности, делает это довольно успешно. Во-вторых, стоит поставить рядом аналогичные куски кода на С++ c шаблонами\препроцессором и на TS, а также сообщения об ошибках, и многие вопросы сразу отпадут сами собой.
но подозреваю, что с ним есть несколько проблем: он очень вербозный, он наверняка дает непонятные сообщения об ошибках, и без наличия в языке object literals он в целом не так полезен
Вербозность — это вопрос вкуса. Зато гибко.
Если я правильно понимаю, то std::any — это что-то типа void *, т.е. перед использованием значения вам нужно все-таки привести его к конкретному типу?
Переменная типа std::any может хранить внутри себя вообще любой тип, а также быть пустой. Для вызова чего-то конкретного из того, что она хранит в данный момент, нужно проверить, что она не пуста, через вызов has_value(), а затем привести ее к нужному типу через any_cast, типа такого:
std::any a = 1;
if (a.has_value()) {
std::cout << std::any_cast<int>(a);
}
Можно еще получить инфу о типе хранимого значения через метод type(), типа a.type().name(), например. Это все работает в рантайме. В compile time есть auto, который можно использовать, если компилятор может вывести тип, с auto все проще, никакие касты не нужны, можно написать просто:
std::string f() {
[...]
}
auto s = f();
cout << s.length();
без всяких лишних кастов.
Множественное наследование с состоянием чревато известной проблемой ромба
Это решается через виртуальное наследование:
class A {
[...]
}
class B : public virtual A {
[...]
}
class C : public virtual A {
[...]
}
class D : public virtual B, public virtual C {
[...]
}
но это не то же самое, что пересечение: оно требует реализации нескольких интерфейсов одновременно. Например, можно сделать функцию, которая будет объединять два объекта в один, и тип результата будет строго выведен
Несколько интерфейсов одновременно — это и есть множественное наследование. std::variant — это когда на данном месте может быть ЛЮБОЙ ИЗ каких-то типов, то есть это «или», а множественное наследование — это «и».
Зато гибко.Спорный момент. Я предпочту систему, которая позволяет хорошо решать частые проблемы и плохо редкие, чем любые — средне.
std::any может хранить внутри себя вообще любой типЭто я понял, но это не то же самое, что
any. Считайте, что any — это запасной план на экстренный случай, когда вы говорите компилятору «не лезь, я беру ответственность на себя, этот код точно будет работать» — и он ничего не проверяет. По поводу auto — это вообще локальный вывод типов. В TS он работает при объявлении любой переменной по умолчанию, хотя можно указать и явно :)Это решается через виртуальное наследованиеПонял, принимается, но опять же — вербозно. Вам нужно описывать все эти типы самостоятельно, и вы не можете написать функцию, которая создаст новый тип из существующих. Максимум вы можете подставить или вытащить тип из шаблона. TS же позволяет делать нечто вроде зависимых типов, хотя и очень ограниченное по меркам языков с настоящими ЗТ (типа Idris).
плюсы сейчас и 30 лет назад это совершенно разные языки. а вообще за последний год много на чем разрабатывал и заметил одну тенденцию: языки со статической типизацией берут вещи из языков с динамической типизацией, и наоборот
При этом я совершенно не считаю, что статическая типизация на фронтенде нужна настолько, чтобы со всех статьях про Javascript начинать обсуждать Typescript.Вы не считаете — и поэтому остальные не должны это обсуждать? Серьезно?
Статическая типизация улучшает поддерживаемость и облегчает рефакторинг для любого мало-мальски серьезного проекта, и в TS она реализована совсем не так сковывающе, как в C++ — особенно если вы имели в виду более старые стандарты. Возможно, вам стоит освежить знания?
Большинство тех, кто сейчас внедряет TS не до конца понимают зачем это нужно именно их проекту.Даже если TS им не зайдет — так у них хотя бы будет опыт в обоих подходах, с которым потом можно будет обоснованно решать, какой выбрать.
Вы не считаете — и поэтому остальные не должны это обсуждать? Серьезно?
Нет, просто если статья про один язык программирования, то я упорно не понимаю, почему любители другого языка считают что нужно обязательно зайти на огонек и поучить всех жить. Еще раз — если бы я хотел написать про Typescript, я бы так и сделал.
Статическая типизация улучшает поддерживаемость и облегчает рефакторинг для любого мало-мальски серьезного проекта
Вы где-то это прочитали, да?
Возможно, вам стоит освежить знания?
А с чего вы взяли, что я не писал на TS? Ну ей богу, смешно как-то рассуждаете.
Даже если TS им не зайдет — так у них хотя бы будет опыт в обоих подходах, с которым потом можно будет обоснованно решать, какой выбрать.
Не дешевый такой опыт, которые при этом часто никак не обоснован. Если бы речь шла о JsDoc или Flow, когда «попробовать» не значит переписать весь проект на новом языке, я бы еще понял.
Еще раз, давайте договоримся: Typescript !== Javascript !== Dart !== Clojurescript
Статья про Javascript.
Svelte тоже не чистый JS, если уж на то пошло. Так что не стоит включать борца за чистоту крови.
И раз уж зашло обсуждение TS, то до появления CoffeeScript, JS активно стагнировал без свежих идей. CS заставил комитет подсуетиться и начать какие-то телодвижения. Это привело к реальным изменениям в языке, иногда более продуманным, чем в источнике.
Если вы посмотрите, то сегодня в комитете началась гонка идей. Так например вместо того, чтобы решить проблему с кривым механизмом формирования ошибок и единым форматом трейса, комитет двигает скрытие кода функции от вывода через toString (я серьезно). Последняя фича уже добралась до Stage 2, а обработка ошибок за два года не смогла выйти из Stage 1.
Я это к тому, что TS – это важная веха в развитии JS и, он сегодня делает для JS, возможно, даже больше, чем разработчики JS. О его значимости говорит количество проектов, которое однажды перерастет в качество. А самое главное, делает он это, чтобы однажды умереть, оставив после себя след в самом JS.
И да, мне не нравится порождаемая им фрагментация, как и хайп вокруг чего бы то ни было (кроме WASM, кончено). Но лучше экспериментировать в отдельной ветке, а не в мастере, как JS.
Svelte тоже не чистый JS, если уж на то пошло. Так что не стоит включать борца за чистоту крови.
А вы проверьте JS код Svelte компонента и компонента написанного на TS через JS валидатор и посмотрите. Сам по себе синтаксис внутри компонента Svelte — это вполне валидный ES6+. Никакие дополнительные, неустановленные языком конструкции не используются. Поэтому с точки зрения самого синтаксиса — это чистый JS. То есть чтобы начать писать код, не нужно знать никаких иных вещей, кроме JS (в отличии от TS).
Другое дело, что после компиляции он обрастает дополнительным функционалом, но это уже особенность фреймворка. Но даже после компиляции, мы можете совершенно свободно открыть итоговый компонент и прочитать его как есть, без проблем, потому что внутри все тот же ванильный хорошо читаемый JS.
Так что тут я не согласен. Svelte не привносит ничего нового в синтаксис, просто дополняет его новыми возможностями о которых мы всегда мечтали.
Я это к тому, что TS – это важная веха в развитии JS и, он сегодня делает для JS, возможно, даже больше, чем разработчики JS.
Послушайте, я ведь совершенно не имею ничего против TS как такового. У нас даже были проекты на нем. Для некоторых видов проектов, например, энтерпрайзов без него писать реально было бы сложнее.
Я лишь против того, чтобы любая статья про Javascript превращалась в срачь про Typescript и необходимость статической типизации для 100% проектов. Все это не так.
Так что тут я не согласен. Svelte не привносит ничего нового в синтаксис, просто дополняет его новыми возможностями о которых мы всегда мечтали.
Вы об одном мечтаете, мы о другом. Мне бы хотелось, чтобы JS вообще транспилирвоать не приходилось. Svelte не чистый JS, хоть и в меньшей степени его видоизменяет, но транспиляции все равно требует. Особой разницы я не вижу, можно спорить о степени, но это бессмысленно.
Я лишь против того, чтобы любая статья про Javascript превращалась в срачь про Typescript...
Обращаю ваше внимание на то, что срач устроили именно вы. На вопрос закрытого типа про поддержку TS, можно было ответить односложно.
Вы об одном мечтаете, мы о другом.
То есть вы никогда не мечтали о нативной реактивности? Или вот когда меняешь переменную и если в DOM есть зависимые ноды, они тоже обновляются, сохраняя 100% консистентность, не? Если не мечтали, тогда пожалуй да.
Мне бы хотелось, чтобы JS вообще транспилирвоать не приходилось.
Можете не транспилировать. После компиляции вы получаете чистый ES6. Если вам не нужны браузеры без ES6, тогда зачем вам транспиляция? Более того, ни babel ни buble в стартер-шаблоне Svelte нет.
Обращаю ваше внимание на то, что срач устроили именно вы. На вопрос закрытого типа про поддержку TS, можно было ответить односложно.
Это не так. Я лишь удивился тому, что в статье для новичков единственный вопрос это TS. Хотя TS кстати, по секрету вам скажу, поддерживается примерно также как в том же Angular, только без прямой привязки на него. То есть в скриптах можно завести, но в шаблонах типизации не будет (это кстати проблема TS).
Дрочева на TS я не понимаю, это правда. Сам компилятор Svelte написан на TS по понятным причинам — это инструмент, который идет лишь dev-зависимостью.
То есть вы никогда не мечтали о нативной реактивности?
Боюсь это несбыточная мечта в мире JS.
Или вот когда меняешь переменную и если в DOM есть зависимые ноды, они тоже обновляются, сохраняя 100% консистентность, не?
И работает это исключительно с локальными переменными. Причём объявлены они должны быть так:
$: foo = 123;Очень нативненько. А стоит импортировать что-то из внешнего модуля и всё, закончилась реактивность, лепи костыли руками.
в скриптах можно завести, но в шаблонах типизации не будет (это кстати проблема TS)
Если у нас что-то не работает, то это не наша проблема? Удобная позиция :-)
Сам компилятор Svelte написан на TS по понятным причинам — это инструмент, который идет лишь dev-зависимостью.
То есть для дев-зависимостей статическая типизация понятно зачем, а для приложений — не понятно?
Svelte безусловно интересный проект, но порой вас сильно заносит в попытке выставить его недостатки за достоинства.
Рад что вы спросили)))
Пожалуй, но Svelte позволяет разработчику получить похожий DX.
Это не так, вы просто не разобрались.
И даже снаружи компонента через инстанс:
Во-первых, это обычный JS Label, то есть чисто с точки зрения синтаксиса вполне валидно. Во-вторых, это не способ сделать реактивную переменную, а сделать реактивную декларацию, которая зависит от других реактивных переменных. Раньше это называлось вычисляемое свойство и можно было лишь сохранять в свойство. Теперь можно делать даже так:
Это тоже не так. Во-первых, все что импортируется может быть сразу использовано везде, даже в шаблонах. Например, если мы импортируем функцию, то она будет пересчитываться вместе с параметрами по pull-принципу:
Кроме того, есть еще реактивный сторы, которые можно импортировать в разные компоненты и использовать:
// Component1.svelte
// Component2.svelte
А у кого-то TS работает в шаблонах? Слышал вроде в Angular что-то сами они пилили для этого под каким-то флагом, но глубоко не вникал. Но базово TS не поддерживает такую кастомизацию из коробки и это прежде всего его ограничение. Так как в Svelte нет упора на TS, а отличии от Angular, нет смысла тратить на это ресурсы чтобы патчить его. Кстати, а как вы type-checking в tree-view заставили работать?
Я не это сказал. Автору может нравиться TS и вероятно для компилятора TS даже имеет смысл. Но большинству разработчиков из Svelte сообщества TS не особо нужен, поэтому было бы странно со стороны автора делать упор на TS в зависимостях. Пока он в dev-зависимостях, это никого не парит, но если бы TS шел зависимостью в стартере и мне пришлось бы его выпиливать, чтобы начать нормально работать со Svelte, я был бы печальнее.
Так что за недостатки то, вы так и не сказали. Кстати, отвечая на ваш первый вопрос про TS — поддержка в скрипте есть, в шаблонах нет, по причинам описанным выше. Какие еще недостатки я выставляю за достоинства?
Боюсь это несбыточная мечта в мире JS.
Пожалуй, но Svelte позволяет разработчику получить похожий DX.
И работает это исключительно с локальными переменными. Причём объявлены они должны быть так:
Это не так, вы просто не разобрались.
<h1>Hello {name}</h1>
<script>
export let name = 'world';
...
name = 'vintage'; // DOM auto-magically updated
</script>
И даже снаружи компонента через инстанс:
import HelloWorld from './HelloWorld.svelte';
const hw = new HelloWorld({ ... });
hw.name = '$mol'; // DOM auto-magically updated
Очень нативненько.
Во-первых, это обычный JS Label, то есть чисто с точки зрения синтаксиса вполне валидно. Во-вторых, это не способ сделать реактивную переменную, а сделать реактивную декларацию, которая зависит от других реактивных переменных. Раньше это называлось вычисляемое свойство и можно было лишь сохранять в свойство. Теперь можно делать даже так:
let foo 1, bar = 2, baz = 3, qux, quux;
$: { // пересчитается только если изменятся foo или bar
qux = foo + bar;
quux = bar * 4;
// any js expression or side-effect
}
А стоит импортировать что-то из внешнего модуля и всё, закончилась реактивность, лепи костыли руками.
Это тоже не так. Во-первых, все что импортируется может быть сразу использовано везде, даже в шаблонах. Например, если мы импортируем функцию, то она будет пересчитываться вместе с параметрами по pull-принципу:
<h1>Hello {getLocaleName(name)}</h1>
<script>
import { getLocaleName } from './helpers.js';
export let name = 'world';
</script>
Кроме того, есть еще реактивный сторы, которые можно импортировать в разные компоненты и использовать:
// Component1.svelte
<input bind:value={$name}> <!-- пишем тут -->
<script>
import { name } from './store.js';
</script>
// Component2.svelte
<h1>Hello {$name}</h1> <!-- обновлятся везде -->
<script>
import { name } from './store.js';
</script>
Если у нас что-то не работает, то это не наша проблема? Удобная позиция :-)
А у кого-то TS работает в шаблонах? Слышал вроде в Angular что-то сами они пилили для этого под каким-то флагом, но глубоко не вникал. Но базово TS не поддерживает такую кастомизацию из коробки и это прежде всего его ограничение. Так как в Svelte нет упора на TS, а отличии от Angular, нет смысла тратить на это ресурсы чтобы патчить его. Кстати, а как вы type-checking в tree-view заставили работать?
То есть для дев-зависимостей статическая типизация понятно зачем, а для приложений — не понятно?
Я не это сказал. Автору может нравиться TS и вероятно для компилятора TS даже имеет смысл. Но большинству разработчиков из Svelte сообщества TS не особо нужен, поэтому было бы странно со стороны автора делать упор на TS в зависимостях. Пока он в dev-зависимостях, это никого не парит, но если бы TS шел зависимостью в стартере и мне пришлось бы его выпиливать, чтобы начать нормально работать со Svelte, я был бы печальнее.
Svelte безусловно интересный проект, но порой вас сильно заносит в попытке выставить его недостатки за достоинства.
Так что за недостатки то, вы так и не сказали. Кстати, отвечая на ваш первый вопрос про TS — поддержка в скрипте есть, в шаблонах нет, по причинам описанным выше. Какие еще недостатки я выставляю за достоинства?
вы просто не разобрались.
Неужели надо документацию прочитать перед использованием? Я-то думал, что везде всё интуитивно понятно, и только в $mol треш и угар.
это обычный JS Label, то есть чисто с точки зрения синтаксиса вполне валидно.
А ведёт себя не как JS вообще. Это даже хуже, чем JSX, где хотя бы видно, где JS, а где что-то ещё.
Например, если мы импортируем функцию,
А если импортируем объект, то изменения в нём никто не протрекает.
она будет пересчитываться вместе с параметрами по pull-принципу
Я бы не хотел, чтобы она пересчитывалась на каждый чих.
есть еще реактивные сторы
Вот и обсерваблы подъехали :-)
Кстати, а как вы type-checking в tree-view заставили работать?
Транспиляцией в TS.
мне пришлось бы его выпиливать, чтобы начать нормально работать
То есть мнение разработчика вашего любимого фреймворка для вас не аргумент в том, как этот фреймворк лучше использовать?
вопрос про TS — поддержка в скрипте есть
Как мы уже выяснили, Svelte использует свой язык программирования, внешне похожий на JS. TS анализатору потока исполнения это определённо снесёт крышу.
Неужели надо документацию прочитать перед использованием? Я-то думал, что везде всё интуитивно понятно, и только в $mol треш и угар.
Полагаю вы просто и не пытались. То бишь не прилагали никаких усилий. Между прочим я в свое время приложил некоторые усилия чтобы понять как работает TreeView и даже написал небольшой компонент. Просто не зашло в итоге все равно.
А ведёт себя не как JS вообще
К сожалению, в JS нет существует destiny operator'а. Можно было пойти по пути $mol/treeview и придумать полностью кастомный синтаксис, либо навесить новые смыслы на существующий. Так как сообществу очень понавилась эта идея, так и сделали. Меня сперва тоже смущало, но в итоге когда поюзал, оказалось настолько удобно, что «верно-не-верно» отошло на второй план.
Это даже хуже, чем JSX, где хотя бы видно, где JS, а где что-то ещё.
Здесь только JS, ничего «еще» нет. Просто некоторые конструкции перегруженны.
А если импортируем объект, то изменения в нём никто не протрекает.
Да, причем Svelte даже не пытается это делать. Только по принципу иммутабильных структур. Обычно этого и не надо. Данные используются максимально плоско в рамках компонента. Если нужно вглубь работать, то идет разбиение на подкомпонент и уже он отвечает на новый уроверь вложенности. Просто и понятно.
Вот и обсерваблы подъехали :-)
По сути да, но они очень простые, во-первых. Во-вторых, магия компилятора дает возможность работать с ними удобно.
Транспиляцией в TS.
Ну мне пожалуй это не надо. Уверен, если сообщество будет требовать, сделать это можно. Одна фигня компиляция идет. Можно ведь и TS код генерировать.
То есть мнение разработчика вашего любимого фреймворка для вас не аргумент в том, как этот фреймворк лучше использовать?
А какое у него мнение? У него мнение, что в компонентах TS не нужен. Собственно и мне он там не нужен и видимо большей части сообщества, раз никто не занимается этим.
Как мы уже выяснили, Svelte использует свой язык программирования, внешне похожий на JS. TS анализатору потока исполнения это определённо снесёт крышу.
Это не так. В 2-ке да, были проблемы, но в Svelte 3 в скрипте по сути находится произвольный JS код. Чтобы все работало нормально, нужно TS код транспилировать в JS код до компиляции Svelte. Это можно сделать с помощью прероцессора.
если статья про один язык программированияС чего вы взяли, что статья про конкретный язык программирования? JS — это платформа с множеством инструментов поверх нее, и нет ничего плохого и удивительного в том, что люди интересуются взаимодействием с собственным инструментарием. Если кто-то напишет крутую библиотеку на Scala, наверняка многим будет интересно, как ее можно вызвать из проекта на Java / Kotlin / Groovy.
Любой нормальный алгоритм, подход или структуру данных можно строго типизировать с помощью достаточно мощной системы типов. Если это не получается, то есть три варианта. Первый — нужно дорабатывать сам TS. Второй — некий гениальный алгоритм, который можно использовать с типами
any. И третий, самый часто встречающийся — программист написал какую-то фигню :)Вы где-то это прочитали, да?Прочитал и подтвердил на собственном опыте.
Не дешевый такой опыт, которые при этом часто никак не обоснован.Во-первых, отсутствие опыта часто обходится дороже, чем его получение. Во-вторых, если вы не видите обоснований или не согласны с ними — это совсем не значит, что их нет. Существует много историй о том, как крупный проект перевели с чистого джиеса на TS / Flow или даже Reason и поимели с этого профит. А вот чтобы наоборот — такого я практически не встречал.
А вы считаете нормальным, что уже нельзя написать статью про javascript без обязательного вопроса о typescript в комментариях, даже если эта статья для новичков?А чего ненормального? Новичок, может, typescript тоже хочет изучить.
вот только не надо пожалуйста TypeScript тащить во все что касается JavaScript, вполне устраивает обычный JS.
Нет ни Angular $scopeВ Angular нет $scope.
Опять же, я понимаю любую критику в отношении синтаксиса, но мне нравится то, насколько легко понять это.Подобного вида шаблоны с кастомным синтаксисом появляются/умирают/существуют уже десятки лет в самых рзличных фреймворках и библиотеках.
Вместо того, чтобы вкладывать JavaScript в наш HTML-код, мы просто говорим: эй, давайте сделаем цикл по этому массиву и создадим элемент для каждого из них.Как раз для новичков полноценно освоить обычный JS было бы полезнее чем учить язык размерки определенного фреймфорка и здесь JSX ближе к стандартному JS чем svelte и многие другие фреймворки. Но я JSX не перевариваю.
Для узких задач, например внедрить виджет куда-то в чужую систему, возможно это решение удобное. То есть я бы рассматривал этот фреймворк как средство решения специализированных задач. Для крупных проектов с большой командой не вижу смысла выбирать нишевые вещи. К тому же новичкам будет проще найти работу зная что-то о react/angular/vue чем фокусироваться на svelte.
Если вы пытаетесь на полном серьезе апеллировать к тезисам статьи, надеюсь вы обратили внимание что это перевод.
Уверен автор имел ввиду AngularJS. Думаю он просто не в курсе концепции авторов ангуляра о том, как различать Angular 2+ и первую версию.
Не сказал бы что прям умирают. Думаю примерно в половине фреймворков используется DSL подобного вида. Тот же Angular. Другая половина раверное используется «типа Javascript», в виде JSX, который точно такой же DSL.
А мне кажется именно то, что JSX позиционируется как просто Javascript путает еще больше. Потому что раз это Javascript, тогда где же мои if/else, for/while, etc? А раз их нет, тогда какой же это JS и как понять, что можно использовать, а что нет?
Можете уточнить, с чего вы взяли, что на Svelte не получится написать все тоже самое, что на Vue или React, например? Желательно обоснованно.
Например, в нашей компании мы уже почти 2 года используем Svelte совместно с Vue и Ractive. Многие вещи на Svelte пишутся даже быстрее и удобнее.
Спорить про кол-во вакансий я не буду, потому что это правда. Но ведь лет 5 назад кол-во вакансий по Backbone/AngularJS/Ember/ExtJS было в разы больше чем по React, а сейчас где они все? Сейчас даже по Vue не так много вакансий (кроме Китая), так что из вашей логики делаем вывод, что все должны писать на React. А как же прогресс?
В Angular нет $scope.
Уверен автор имел ввиду AngularJS. Думаю он просто не в курсе концепции авторов ангуляра о том, как различать Angular 2+ и первую версию.
Подобного вида шаблоны с кастомным синтаксисом появляются/умирают/существуют уже десятки лет в самых рзличных фреймворках и библиотеках.
Не сказал бы что прям умирают. Думаю примерно в половине фреймворков используется DSL подобного вида. Тот же Angular. Другая половина раверное используется «типа Javascript», в виде JSX, который точно такой же DSL.
JSX ближе к стандартному JS
А мне кажется именно то, что JSX позиционируется как просто Javascript путает еще больше. Потому что раз это Javascript, тогда где же мои if/else, for/while, etc? А раз их нет, тогда какой же это JS и как понять, что можно использовать, а что нет?
Для узких задач, например внедрить виджет куда-то в чужую систему, возможно это решение удобное. То есть я бы рассматривал этоn фреймворк как средство решения специализированных задач. Для крупных проектов с большой командой не вижу смысла выбирать нишевые вещи.
Можете уточнить, с чего вы взяли, что на Svelte не получится написать все тоже самое, что на Vue или React, например? Желательно обоснованно.
К тому же новичкам будет проще найти работу что-то зная и react/angular/vue чем фокусировать на svelte.
Например, в нашей компании мы уже почти 2 года используем Svelte совместно с Vue и Ractive. Многие вещи на Svelte пишутся даже быстрее и удобнее.
Спорить про кол-во вакансий я не буду, потому что это правда. Но ведь лет 5 назад кол-во вакансий по Backbone/AngularJS/Ember/ExtJS было в разы больше чем по React, а сейчас где они все? Сейчас даже по Vue не так много вакансий (кроме Китая), так что из вашей логики делаем вывод, что все должны писать на React. А как же прогресс?
Если бы всем поголовно во фронтенд сообществе нужны были бы статические типы, они давно бы уже стали частью стандарта.А где я написал что не получится? На чистом JS очевидно тоже можно сделать все то же что и на фреймворках, вопрос в целесообразности. Дело ведь не просто в том чтобы написать, но развивать, поддерживать, рефакторить, оптимизировать, интегрировать, использвать множество существующих совместимых модулей, нанимать новых мемберов в команду и тд.
Мне почему-то кажется, что вы выбрали неверную цитату, но я вроде бы понял на что вы отвечаете.
Именно так. Поэтому мы и выбрали Svelte в свое время, очень довольны, а с выходом 3-ки станем еще больше. Код пишется невероятно быстро и точно. Протестированный код требует минимум поддержки, а его простота позволяет любому новому программисту быстро понять, как все это работает. Рефакторинг практически моментальный, опять же из-за лаконичности и простоты кода.
На чистом JS очевидно тоже можно сделать все то же что и на фреймворках, вопрос в целесообразности. Дело ведь не просто в том чтобы написать, но развивать, поддерживать, рефакторить, оптимизировать, интегрировать, использвать множество существующих совместимых модулей, нанимать новых мемберов в команду и тд.
Именно так. Поэтому мы и выбрали Svelte в свое время, очень довольны, а с выходом 3-ки станем еще больше. Код пишется невероятно быстро и точно. Протестированный код требует минимум поддержки, а его простота позволяет любому новому программисту быстро понять, как все это работает. Рефакторинг практически моментальный, опять же из-за лаконичности и простоты кода.
А мне кажется именно то, что JSX позиционируется как просто Javascript путает еще больше. Потому что раз это Javascript, тогда где же мои if/else, for/while, etc? А раз их нет, тогда какой же это JS и как понять, что можно использовать, а что нет?
JSX это синтаксический сахар к вызову React.createElement, соответственно можно использовать только то, что и при обычных вызовах функций
https://reactjs.org/docs/introducing-jsx.html#jsx-represents-objects
Это я знаю, но часто его позиционируют именно как «просто JS», но по факту это не так. Это такой же DSL, только с JS-подобным синтаксисом. А ведь JS — это по большей части императивный язык, а HTML — чисто декларативный. Поэтому нет никакого удобства создавать DSL для декларативной предметной области на основе императивного синтаксиса. Такое положение дел зачастую вызывает больше проблем у новичков, чем запомнить 3 конструкции DSL, которые присутствуют в Svelte, удобно встроены (нет лишних скобок и тп) в предметную область (html) и делают ровно то, что нужно.
Потому что раз это Javascript, тогда где же мои if/else, for/while, etc?
if/else
if(condition) {
return <div>Condition is met</div>
} else {
return <div>Not met</div>
}for
const elements = [];
for(const item of items) {
elements.push(<div>Element {item}</div>)
}JSX просто добавляет вам еще один литерал в дополнение к стандартным литералам массивов и объектов.
Если бы я был новичком, то лучше потратил бы время на изучение нативного JS.
А потом выбрал бы тот фрэймворк(и), который в тренде и на котором реально заработать можно.
Не зная основ, можно очень легко увязнуть в этой магии, если что то пойдет не так.
А изучить все фрэймворки, голова лопнет, они хоть и похожи, но каждом куча нюансов.
А потом выбрал бы тот фрэймворк(и), который в тренде и на котором реально заработать можно.
Не зная основ, можно очень легко увязнуть в этой магии, если что то пойдет не так.
А изучить все фрэймворки, голова лопнет, они хоть и похожи, но каждом куча нюансов.
С вами сложно не согласиться. Собственно автор статьи и рассуждает на эту тему. Его основной довод — в реальных проектах уже давно мало кто пишет на ваниле и все абстрагировано донельзя. Svelte в этом смысле наоборот наиболее ванильный фреймворк, по сравнению с остальными, где магия спрятана в дебрях рантайма. В Svelte вы можете открыть скомпилированный компонент и посмотреть как манипуляции в DOM работают напрямую, а не завернутые в абстракции типа VDOM.
Второй довод автора — очень просто можно перегореть, когда начинаешь разбираться в разработке с нуля. Да, вроде как принято сперва информатику изучать в теории, но если не начать достаточно быстро решать интересные и практические задачи, можно и не завершить обучение вообще. Лично я за итеративное обучение, а не последовательное. Когда на разных этапах, мы как бы возвращаемся к оному и тому же, только на новом уровне познания. Как по спирали.
Второй довод автора — очень просто можно перегореть, когда начинаешь разбираться в разработке с нуля. Да, вроде как принято сперва информатику изучать в теории, но если не начать достаточно быстро решать интересные и практические задачи, можно и не завершить обучение вообще. Лично я за итеративное обучение, а не последовательное. Когда на разных этапах, мы как бы возвращаемся к оному и тому же, только на новом уровне познания. Как по спирали.
Чтобы привлечь внимание к Svelte стоит упомянуть что его автор — Rich Harris на счету у которого Rollup и Ractive примененный в The Guardian.
Ractive примененный в The GuardianВполне логично ведь Rich Harris работал в The Guardian судя по этому материалу shoptalkshow.com/episodes/349
Именно так, а сейчас он работает в NYT и там используют Svelte. Не знаю как, но крупные издания с высонагруденными сайтами почему-то доверяют ему и его разработкам. И даже оплачивают занятия open-source проектами в рабочее время.
Вполне допускаю что например админка в NYT написана на других фреймворках, там легковесность и неконфликстость с другими решениями на странице особенно не важны. А штуковины сделанные на svelte что называется user facing, легковесные виджеты встраиваемые например в страницы статей. Также могу предположить что на svelte сделаны виджеты которые встраивают себе другие ресурсы.
Не знаю по поводу админки, но уверен, что публичный сайт любого серьезного издания — это довольно большой легаси, построенных еще на классических способах сайтостроения, где SSR привалирует. Но это же и одна из сильный сторон Svelte.
На нем не только можно написать SPA приложение любой сложности, но и встроить в существующий сайт в качестве виджетов. Более того, можно его компоненты встроить вообще в любое приложение, написанное хоть на React, хоть на Angular. Мы например, такое делали для легаси приложений на Ractive. Благодаря своей концепции, Svelte также прекрасно работает поверх концепции микрофронтендов.
На нем не только можно написать SPA приложение любой сложности, но и встроить в существующий сайт в качестве виджетов. Более того, можно его компоненты встроить вообще в любое приложение, написанное хоть на React, хоть на Angular. Мы например, такое делали для легаси приложений на Ractive. Благодаря своей концепции, Svelte также прекрасно работает поверх концепции микрофронтендов.
Кстати, как у него с SSR?
Прекрасно. Это же компилятор. В данный момент он поддерживает компляцию в DOM (ванильные DOM манипуляции) и SSR (html строка), а также дополнительную опцию customElement если нужно получать DOM код в виде готового веб-компонента. Поддержка стандарта 100%.
Однако, так как формат Svelte-компонентов обобщен, в будущем, возможно, эти же компоненты можно будет скомпилировать и в другие таргеты, например, в нативные мобильные приложения. Все это конечно зависит от того, куда пойдет развитие.
Конкретно по поводу SSR есть готовый к использованию изоморфный фреймворк поверх Svelte где все настроено из коробки: https://sapper.svelte.technology
Однако, так как формат Svelte-компонентов обобщен, в будущем, возможно, эти же компоненты можно будет скомпилировать и в другие таргеты, например, в нативные мобильные приложения. Все это конечно зависит от того, куда пойдет развитие.
Конкретно по поводу SSR есть готовый к использованию изоморфный фреймворк поверх Svelte где все настроено из коробки: https://sapper.svelte.technology
пока читал не покидало ощущение дежавю, что если бы я не видел названия Framework'а, то я бы подумал что это о RiotJS :-) и код даже частично похож. И к слову, я считаю что RiotJS действительно лучший JS фреймворк. К слову, ушел на RiotJS с RactiveJS в свое время, это по моему родитель Vue фреймворка. По крайней мере они очень похожи. В ReactJS считаю очень много магии, дополнительных компонентов Babel, Redux и т.п.от которых он зависит. А вот Riot самодостаточный, легкий, быстрый и максимально простой, хотя откровенно говоря что он очень походит на React
Легкость и простота подходят для легких/простых/однорзовых задач. Для задач другого плана подходят другие инструменты.
И к слову, я считаю что RiotJS действительно лучший JS фреймворк. К слову, ушел на RiotJS с RactiveJS в свое время,
Мы тоже пробовали Riot в свое время, когда еще Muut пытались его пиарить. Тогда он был еще сыроват и местами глючил. Поэтому мы так и не сделали его альтернативой Ractive. А после после выхода Vue 2 добавили его в стек. В 2017-м добавили еще Svelte и перестали писать новые проекты на Ractive, несмотря на то, что он до сих пор развивается.
это по моему родитель Vue фреймворка. По крайней мере они очень похожи.
Да, Vue изначально очень многое взял от Ractive. Сейчас клонирует решения из Angular/React. Вообще, китайский менталитет чуствуется конечно)))
Кстати, Single File Components, которые в том или ином виде реализованы в Vue, Svelte, Riot, первыми появились в Ractive тоже: component-spec.
Могу добавить, что вы смотрите только на синтаксис и не концентрируете внимание на главной особенности Svelte — нет никакого svelte.min.js в рантайме.
НЛО прилетело и опубликовало эту надпись здесь
Это не совсем так. Есть небольшой набор хелперов, которые выполняют рутинные операции с DOM, но это сложно назвать фреймворком. Основная особенность Svelte, в этом плане, в том что у него наиболее полная AoT-компиляция, среди всех известных фреймворков. Иными словами он не только прекомпилирует декларативные шаблоны в js, как делают многие, но статически анализирует все связи между данными и DOM, заранее обсчитывая все возможные манипуляции при изменениях и генерируя готовый к испольнению ванильный код, не требующий расчетов в рантайме.
Это очень похоже на то, как если бы вы вдруг захотели сами написать приложение полностью на ваниле. Скорее всего делали бы примерно тоже самое, только руками. К тому же неминуемо столкнулись с «комбинаторным взрывом». Svelte позволяет вам писать ванильные приложения без необходимости писать на ваниле и решать все эти проблемы вручную.
Это очень похоже на то, как если бы вы вдруг захотели сами написать приложение полностью на ваниле. Скорее всего делали бы примерно тоже самое, только руками. К тому же неминуемо столкнулись с «комбинаторным взрывом». Svelte позволяет вам писать ванильные приложения без необходимости писать на ваниле и решать все эти проблемы вручную.
НЛО прилетело и опубликовало эту надпись здесь
такой же который лежит дистрибутиве фреймворка?
Код, который можно прочитать как есть, на месте, который внутри не использует интерполяцию строк или еще что-то, а напрямую манипулярует с DOM через API.
не совсем понял, что это такое.
Ну это что-то вроде метапрограммирования наверное. В итоге вы пишете декларативно так:
<h1>Hello {name}!</h1>
<script>
export let name = 'world';
</script>
После компиляции это превращается в что-то вроде (всевдокод):
...
const h1 = document.createElement('h1'),
t1 = document.createTextNode('Hello '),
t2 = document.createTextNode(name),
t3 = document.createTextNode('!');
...
if ('name' in changed) {
t2.nodeValue = name;
}
...
То есть максимально понятно и прямолинейно, без каких-либо вычислений в рантайме. В тоже время вы сами не захотите писать такой код руками, несмотря на то, что он очень эффективный. В этом и смысл — вы дикларативно описываете бизнес-логику на высоком уровне абстракции, а Svelte генерирует максимально эффективный код с минимальным кол-во вычислений в рантайме.
Вообще на мой взгляд это выглядит примерно так: «При программировании на C мы не будем использовать stdin. Вместо этого у нас есть очень умный препроцессор, который разворачивает все stdin-подобные вызовы в vanilla-C код. При этом он проводит статический анализ исходного кода и генерирует максимально эффективный выходной код для каждого случая».
Я бы не сказал, что это какой-то супер уникальный подход. Метапрограммирование существует много лет. Есть даже целые языки, которые на это заточены.
Я не спорю, что такой подход имеет право на жизнь. Вот только совершенно не очевидно, какие это дает преимущества по сравнению с фреймворком/библиотекой.
Ну можно взять например VDOM, который на каждое изменение стейта стоить виртуальное DOM дерево просто чтобы вычислить что изменилось и как нужно пропатчить реальный DOM. Это большая рантайм абстракция, которое еще и память нехило кушает. В Svelte вместо этого будет что-то вроде того, что я привел выше — просто сразу патчим DOM. Все потому VDOM вычисляет изменения в рантайме, а Svelte во время компиляции.
В Svelte вместо этого будет что-то вроде того, что я привел выше — просто сразу патчим DOM.
Это тоже не правда. Он не может никак протрекать, что именно вы изменили в дереве объектов и какие именно части приложения нужно обновить, поэтому он пойдёт реконцилировать всё, что прямо или косвенно зависит от изменённой переменной.
В частности, будут проблемы следующих типов:
Если вы измените объект так, что это не будет выглядеть как изменение с точки зрения компилятора (например, вызов
setMonth()уDate), то компилятор не сможет протрекать это изменение.
Чтобы понять надо ли что-то перерендеривать, ему придётся дёрнуть все выражения, для всех мест, что прямо или косвенно зависят от изменённой переменной, что может быть очень медленно (например,
toLocaleString()уDateдля каждой задачи в списке, при изменении, например, названия любой из них).
Это тоже не правда. Он не может никак протрекать, что именно вы изменили в дереве объектов и какие именно части приложения нужно обновить, поэтому он пойдёт реконцилировать всё, что прямо или косвенно зависит от изменённой переменной.
Неа, вы видимо не понимаете как это работает.
Если вы измените объект так, что это не будет выглядеть как изменение с точки зрения компилятора (например, вызов setMonth() у Date), то компилятор не сможет протрекать это изменение.
Все это решается как и везде — иммутабильным изменением объектов. Svelte вообще ничего не трекает. Он делает простое сравнение !== и все. Все эти реконсилейшены и не нужны. KISS.
Чтобы понять надо ли что-то перерендеривать, ему придётся дёрнуть все выражения, для всех мест, что прямо или косвенно зависят от изменённой переменной, что может быть очень медленно (например, toLocaleString() у Date для каждой задачи в списке, при изменении, например, названия любой из них).
Медленно или нет это мерить надо. Svelte конечно не самый быстрый и микрооптимизациями не страдает. Но быстрый достаточно для любых видов задач. Плюс у него неплохие все остальные метрики. Если вы пришли сюда опять письками мериться, то давайте закончим этот диалог. Мне это не интересно.
Неа, вы видимо не понимаете как это работает.
Svelte вообще ничего не трекает.
реконсилейшены и не нужны.
Да уж представьте себе почитал код, который он генерит. Характерный пример:
function submit(event) {
items[editing].description = event.target.value;
$$invalidate('items', items);
}И понеслись проверки каждого айтема, не изменилось ли что. Это и есть реконциляция.
НЛО прилетело и опубликовало эту надпись здесь
Всегда интересно было, на React без jsx кто-нибудь писал что-нибудь посерьезнее hello world?
Компоненты без jsx попадались, но не могу однозначно сказать, был это результат компиляции или ручной код.
НЛО прилетело и опубликовало эту надпись здесь
Вопрос не о том что такое jsx, а про реальные примеры без него. Ваш пример как-раз из разряда hello world. Под реальными примерами я подразумеваю какие-то открытые проекты. Ну или просто упоминание, на подобие «мы в своем проекте содержащем 100+ компонентов не пользуемся jsx».
НЛО прилетело и опубликовало эту надпись здесь
Спасибо. Много такого кода на реакте получается? Насколько по ощущениям читабельность снижается?
Попробуйте vue и его X-Templates, для таких случаев самое оно.
Маятник JS качнулся в обратную сторону?
А запросы к серверу и селект элементов как реализовывать, инструмент какой-нибудь есть? Или предложите использовать fetch или подключать к проекту jQ?
а что мешает подключить какой нибудь axios? там же веб пак есть
Или предложите использовать fetch
А чем fetch не угодил?
Тем, что он не throw'ит ошибки на не 2xx коды от сервера и не позволяет трекать прогресс
или отменить его.
С этим уже все в порядке. AbortController завезли во все современные браузеры, где был нативный fetch.
НЛО прилетело и опубликовало эту надпись здесь
Да, fetch. Если IE нужен — с полифилом. А с селекторами еще проще, querySelector работает в ie8+
Все же Svelte это UI фреймворк. Поэтому вы вольны использовать любые средства для работы с ajax. На проектах посложнее, мы обычно используем axios. Он изоморфный и очень «feature rich». Если нужно что-то попроще, тогда unfetch — 500B полифил для fetch.
Кроме того, есть еще Sapper — изоморфный фреймворк для PWA поверх Svelte. Там встроен и роутинг и фетчинг: sapper.svelte.technology
Кроме того, есть еще Sapper — изоморфный фреймворк для PWA поверх Svelte. Там встроен и роутинг и фетчинг: sapper.svelte.technology
Используем Svelte параллельно с Vue. Вещь достаточно приятная, но очень молодая и сыроватая. Документация слабая, на Stackoverflow вопросов/ответов мало, так что в случае не совсем банальной проблемы приходится сложно. И именно поэтому я бы не советовал новичкам начинать с него.
Лично мне очень не хватает поддержки Typescript, недавно пришлось городить костыли для нее, но это уже другая история, которую обсудили выше.
А что дал такой вариант в чем выразилось преимущество Svelte? что мешало использовать только Vue?
Я даже нормальных UI компонент не нашел под Svelte
Я даже нормальных UI компонент не нашел под Svelte
Там большой и старый проект, часть страниц сделана на первом Angular, часть — на Vue. Svelte решили использовать для тех элементов, которые должны подключаться и там и там (например, сквозная навигация). Мол, исчезающий фреймворк, все будет шустро и круто.
Ну и определяющая причина была в том, что фронт-тимлид и несколько других ребят решили поиграть с модной штукой :) Я работаю немного на другом направлении и изначально меня про этот выбор и не спрашивали.
На самом деле, в итоге, я не вижу больших преимуществ. Размер и скорость выполнения кода сопоставимы (хотя, серьезных сравнительных тестов не проводили), все тоже самое можно было сделать и на Vue, не добавляя новых зависимостей и оставаясь в более стабильной и развитой экосистеме.
Ясно спасибо, так и думал примерно.
и в статье и комментах пока никто не привел конкретного примера, где Svelte бы всех резко уделал в каком то моменте, так что пока да, интерес есть, но и только.
и в статье и комментах пока никто не привел конкретного примера, где Svelte бы всех резко уделал в каком то моменте, так что пока да, интерес есть, но и только.
Ну вообще преимуществ уйма, а сравнение на реально примере можно по-быстрому хотя бы тут глянуть: medium.freecodecamp.org/a-real-world-comparison-of-front-end-frameworks-with-benchmarks-2018-update-e5760fb4a962
В нашей компании используем Vue в проектах, когда заказчик хочет «что-то из популярного» и всегда Svelte, если заказчику все равно.
В нашей компании используем Vue в проектах, когда заказчик хочет «что-то из популярного» и всегда Svelte, если заказчику все равно.
Я бы не сказал, что их уйма, кроме размера бандла и скорости. Однако и эти преимущества, скорее всего, будут нивелироваться при увеличении приложения, потому что на небольшом примере "исчезающий" Svelte предсказуемо выигрывает у фреймворков, которые тащат в рантайм много всего разного, однако чем больше проект, тем меньшую долю в его производительности занимает загрузка и старт самого фреймворка.
Производительности других фреймворков на данный момент тоже вполне достаточно для большинства случаев, а в экосистеме же Svelte пока явно уступает "большой тройке".
Я ничего не имею против этого фреймворка (кроме того, что мне больше по душе стандартные экшены-мутации, чем местный store), однако считаю, что для крупных проектов он ещё слишком молод. Скоро, кажется, выйдет третья версия — будем посмотреть.
Я бы не сказал, что их уйма, кроме размера бандла и скорости.
Этого мало? В Svelte 3 еще упрощенный синтаксис самих компонентов и сторов, который позволяте писать в 1.5-2 раза меньше кода по сравнению конкретно c Vue. Имхо это тоже сильный плюс.
Однако и эти преимущества, скорее всего, будут нивелироваться при увеличении приложения, потому что на небольшом примере «исчезающий» Svelte предсказуемо выигрывает у фреймворков, которые тащат в рантайм много всего разного, однако чем больше проект, тем меньшую долю в его производительности занимает загрузка и старт самого фреймворка.
Когда проект разрастается, то в игру вступает code-splitting. Благодаря тому, что Svelte собирает в каждый бандл только то, что действительно необходимо для его работы и сами бандлы являются полностью независимыми, это значительно упрощает работу на больших проектах. Потому что с классическим подходом — даже самый маленький кусочек вашего кода зависит от всего фреймворка.
а в экосистеме же Svelte пока явно уступает «большой тройке».
Тоже самое было и с Vue года 2-3 назад. Так что это так себе аргумент.
однако считаю, что для крупных проектов он ещё слишком молод.
А все видимо поголовно пишут энтерпрайзы, да? Это даже чисто статистически невозможно.
Скоро, кажется, выйдет третья версия — будем посмотреть.
Данная статья именно о Svelte 3.
(кроме того, что мне больше по душе стандартные экшены-мутации, чем местный store),
Как раз мемчик на эту тему:
Моя точка зрения заключается в том, что пока что Svelte подходит для больших/долгоживущих проектов меньше, чем «большая тройка», потому что единственный его плюс — производительность, но и производительности других фреймворков для большинства задач вполне достаточно, даже на слабых устройствах.
Минусы же, в лице пока что слабо развитой экосистемы, отсутствия хорошей документации и прочих детских болячек — на лицо.
Если ваша точка зрения отличается — ок, у меня с этим нет никаких проблем.
Свое отношение я высказал — вещь интересная, возможно, перспективная, но большой проект я бы на ней пока не писал. Однако, всячески желаю ей расти, развиваться и чтобы через год-два-три я изменил свое мнение.
Что касается «Тоже самое было и с Vue года 2-3 назад.», то тут я не соглашусь с вашей логикой. Кроме Vue несколько лет назад существовала прорва других начинающих фреймворков, однако большинство из них сгинуло, а Vue стал популярен, во многом, благодаря хорошей документации и простоте освоения. Если у проекта пока нет хорошей документации, это не значит, что через несколько лет он станет таким же популярным, как Vue. Это значит лишь то, что пока у проекта нет хорошей документации.
Минусы же, в лице пока что слабо развитой экосистемы, отсутствия хорошей документации и прочих детских болячек — на лицо.
Если ваша точка зрения отличается — ок, у меня с этим нет никаких проблем.
Свое отношение я высказал — вещь интересная, возможно, перспективная, но большой проект я бы на ней пока не писал. Однако, всячески желаю ей расти, развиваться и чтобы через год-два-три я изменил свое мнение.
Что касается «Тоже самое было и с Vue года 2-3 назад.», то тут я не соглашусь с вашей логикой. Кроме Vue несколько лет назад существовала прорва других начинающих фреймворков, однако большинство из них сгинуло, а Vue стал популярен, во многом, благодаря хорошей документации и простоте освоения. Если у проекта пока нет хорошей документации, это не значит, что через несколько лет он станет таким же популярным, как Vue. Это значит лишь то, что пока у проекта нет хорошей документации.
производительности других фреймворков для большинства задач вполне достаточно, даже на слабых устройствах
Это совсем не так.
Минусы же, в лице пока что слабо развитой экосистемы, отсутствия хорошей документации и прочих детских болячек — на лицо.
С первым абзацем не согласен, но это ваше мнение. Тут могу отметить, что детские болячки есть конечно, как и у всех. Однако для v3 доки стали значительно лучше, чего только новые Tutorial и REPL стоят. Начать пробовать можно прямо в REPL и просто скачать готовый проект оттуда.
Свое отношение я высказал — вещь интересная, возможно, перспективная, но большой проект я бы на ней пока не писал. Однако, всячески желаю ей расти, развиваться и чтобы через год-два-три я изменил свое мнение.
Все верно! Тут ведь как, любую новую вещь кто-то раньше оцениват по достоинству, кто-то позже.
Интересно выглядит. Даже если сам фрэймворк не взлетит, то концепты, выпиливающие как можно больше сущностей (не в ущерб функциональности) из нынешнего зоопарка, должны развиваться.
Если кому интересно, то я делал не сложный ui на этом фреймворке: https://github.com/reddec/monexec-ui
Это SPA UI для супервизора https://github.com/reddec/monexec
В целом удобно.
Веб компоненты итд уже являються очень хорошей альтернативой фреймворков — а когда введут вот это — github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md — зачем нужны будут вообще какие либо фреймворки?
Как видно из секции "3.3. Conditionals and Loops using Nested Templates", всю самую интересную часть оформлению циклов и условий предполагается делегировать фреймворкам. А без этой базовой функциональности даже простую страничку не собрать.
P.S. тем не менее, спасибо за ссылку, расширили мой кругозор.
Это спокойно реализуется кастомным элементом — пихать это в темплейт не обязательно. Там даж дальше по тексту об этом написано)
зачем нужны будут вообще какие либо фреймворки?
Это спокойно реализуется кастомным элементом
Как-то вот эти два утверждения не складываются. В любом случае придется подключить какой-то дополнительный код, чтобы все заработало как надо.
Решить можно все. Чтобы хоть как-то писать нормально на веб-компонентах уже придумали lit-element/lit-html, но ведь это тоже фреймворки по-сути. Да и сами веб-компоненты, если включить shadow-dom становятся довольно медлеными.
Кроме того, раз уж речь про Svelte, если вдруг ситуация с веб-компонентами изменится к лучшему, всегда можно скомпилировать Svelte-компоненты в веб-компоненты с помощью одного флага и продолжить юзать их таким образом. Так что мы ничего не теряем!
Кроме того, раз уж речь про Svelte, если вдруг ситуация с веб-компонентами изменится к лучшему, всегда можно скомпилировать Svelte-компоненты в веб-компоненты с помощью одного флага и продолжить юзать их таким образом. Так что мы ничего не теряем!
А можно источник — где описываеться как и почему шэдоу дом негативно влияет на производительность
Источника дать не могу, это просто тесты показывают. Попробуйте создать веб-компонент с shadow-root и без него. Сделайте замеры и сами все увидите, насколько станет медленнее.
Могу вот еще дать ссылку на тесты, которые делались к другой статье. Они конечно искусственные, но разница в скорости слишком существенная, чтобы списать на погрешность.
Могу вот еще дать ссылку на тесты, которые делались к другой статье. Они конечно искусственные, но разница в скорости слишком существенная, чтобы списать на погрешность.
Есть еще [Riot.js](https://riot.js.org/), который местами очень схож со Svelte. И тот и другой сгодятся максимум для каких-нибудь небольших pet-project, да и в них лучше заюзать React, если уже знакомы с ним.
В целом действительно неплохо для новичков, как переходной этап к более серьезным фреймворкам типа React, Vue и Angular.
> Это означает, что нет виртуального DOM, нет фреймворков поверх фреймворков и нет фреймворка в рантайме.
> Все это довольно серьезные аргументы для более опытных разработчиков
Не увидел аргументов.
В целом действительно неплохо для новичков, как переходной этап к более серьезным фреймворкам типа React, Vue и Angular.
> Это означает, что нет виртуального DOM, нет фреймворков поверх фреймворков и нет фреймворка в рантайме.
> Все это довольно серьезные аргументы для более опытных разработчиков
Не увидел аргументов.
Мы используем Svelte уже для второго крупного проекта и я не понимаю о чем вы говорите.
В нем все делается проще, работает быстрее, памяти жрет меньше, бандл в итоге то же компактнее. Я не знаю зачем React и Vue нужны… для любого новоого проекта ответ один — Svelte.
В целом действительно неплохо для новичков, как переходной этап к более серьезным фреймворкам типа React, Vue и Angular.
А можете как-то аргументировать чем React более серьезен? Vue ладно, примерно схож по возможностям. Angular, очень замороченный, но действительно фактически комбайн. Но React то в каком месте я понять не могу?
Не увидел аргументов.
Не увидели аргументо в том, что у вас код будет работать быстрее, размер бандла будет меньше, кода придется писать в разы меньше и в целом эффективнее, не? Ну тогда я не знаю, действительно, никаких плюсов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему SvelteJS возможно лучший фреймворк для новых веб-разработчиков