В стринговом описании — нет.
В посте есть наш вариант использования с кастингом (после раздела «Другие проблемы»). То есть используется и Vue проверка типа и интерфейс TS.
В VScode оно может и работает, но не через сам пакет линтера — т.к. отдельно он не умеет этого. Соответственно, нельзя запустить на CI — а значит толку от такого линтера немного.
На самом деле никто вам не запрещает, это отлично поддерживается Vue.
Нам нравится в первую очередь с точки зрения файловой структуры — очень удобно работать с едиными файлами.
С точки зрения IDE работа с .vue файлами очень удобна — подсветка синтаксиса работает, сворачивание, итд.
У нас общие стили вынесены в отдельные обще-проектные стилевые файлы, а компоненты имеют только специфичные им стили. Таким образом стили в .vue довольно небольшие, а то и отсутствуют вовсе.
Примерно так же и для шаблона. Скрипт тег также обычно довольно короткий, так как основная логика находится в store.
Спасибо за пост. Сам хотел нечто подобное описать, т.к. был очень схожий болезненный опыт перехода, но на 5ую версию. Проект также работал без CLI и был довольно увесистый.
Мы решили, что наиболее правильным решением будет перейти на CLI, и несмотря на огромное количество убитого времени (неделя боли и страданий) проект стал работать через CLI и даже с AOT компиляцией. Правда это стало последним каплей и следующие проекты мы делали уже на другом фреймворке...
Хорошим примером полезных добавленных, но позже безвозвратно убранных фич в Angular будет пресловутый роутер, а именно: именованные роуты (да они были) и, например, route reuse.
Про второе вообще можно написать отдельный пост — но суть, что раньше это был просто один параматр вроде reuse: false, а теперь нужно имплементировать немаленький класс RouteReuseStrategy
Про InversifyJS в курсе, но именно и не хочется тащить все это на фронт-энд.
Он очень пригодится для Node, но в обычным Vue приложениях считаю слишком большим оверхедом.
Вообще, то же самое касается и vue-property-decorator и vuex-class — как раз то место в статье, где описаны причины использования Vue.extend.
Все эти вещи добавляют дополнительную сложность и TS специфику там, где изначально она не предусмотрена — больше проблем и сложнее поддержка.
Мы стремимся использовать сторонние вещи только по необходимости.
ЗЫ: vuex-class использовал на pet проекте, проблемы были, а большой пользы не ощутил
Касательно производительности взята часть таблицы — если брать все результаты, разницы почти не будет, поэтому я и написал, что основное заметное место большей скорости работы Vue — начальная загрузка страницы.
Но даже так, коэффициэнт который я вижу по ссылке — 1.14, и уж никак не ниже у Angular против Vue. Вы точно сраниваете обычные версии а не с vuex, no-zone и тд?
Эх, я же специально написал что пример утрированный.
Поверьте, я хорошо понимаю разницу между миксином и плагином, к тому же написал, что и то и другое — очень полезный функционал.
Поинт в том, что есть степени свободы в сравнении с Angular. Можно также привести пример с computed vs watched property. Опять же, они преследуют разные цели и нужны для разных задач, но новичкам (особенно), не всегда очевидно что использовать и где.
Спасибо за опенсорс! Несколько лет назад действительно дико не хватало подобного открытого и рабочего решения для русского языка.
Приходилось писать правила для одного из упомянутых коммерческих решений. Работало оно хорошо, но уже одна необходимость использования хардварного лицензионного ключа порождала чудовищное количество проблем.
Пара вопросов:
1. Код еще не смотрел, но планируется ли возможноть писать, или использовать кастомные правила для английского языка? Например в тексте встретится английская имя фамилия которые хотелось бы получать вместе с русскими.
2. Это совсем далекое будущее но тем не менее… RCO и Abbyy помимо сущностей позволяют извлекать собственно факты как действия. То есть связывать сущности в тексте между собой, в основном через глаголы. Нечто подобное хотя бы в далеких планах имеется или основным направлением будет именно извлечение фактов сущностей?
И действительно, но не так и давно исправили, так как в процессе написания поста еще было актуально.
Ну хорошо, что так — исправил уже в английской версии (иначе данный пост придется актуализировать постоянно).
Ну чтож, здорово, что это наконец исчезло из документации.
Интересно что тут методы есть, а описания нет: angular.io/api/forms/Validators
Вы должны понимать, что статья писалась не за 1 день (к сожалению) и перепроверять каждую страницу документации angular ежедневно я не имею возможности.
Так что с одной стороны я рад, что API стало чище. А с другой — почему не сделали этого сразу?
Ну вот видите. И вы способны вести спокойную, аргументированную беседу без хамства.
На самом деле, если так заострять внимание на классах ES6 — в моем опыте не было случаев когда их функционала не хватало. При всей любви к ООП — не все его фичи так уж востребованны, тем более на фронтенде.
Чем Ext действительно всегда был лучше других — богатая библиотека очень мощных компонентов, такой же нет и не будет ни у одного фреймворка. Но в реальности, даже самым навороченным CRM оттуда кроме основных гридов/деревьев и форм особо ничего больше и не нужно. А купить можно только все целиком. И дорого.
Про тулсет уже писали. Не считаю Sencha CMD хорошей вещью, по той простой причине, что как и все в ExtJS она сделала только для ExtJS.
Собственно тут и есть основной его недостаток — все самописное. Собственные классы были киллер-фичей в далекие времена бесплатного ExtJS 3. Сейчас же большая часть подобных ExtJS решений доступны в вебе и так. ES6 в Хроме есть даже нативно.
И TypeScript — да это превосходный (хоть и не идеальный) язык. Он не раз спасал нашу команду от ночей поиска странных ошибок. Он значительно снизил количество необходимых юнит тестов. И да, там есть классы, со статическими полями и тд.
Спорить о том, что ExtJS делает больше — бессмысленно, это очевидно так. В реальности же, при написании приложения на ExtJS вы пишете ExtJS, а не JS.
Все постоянно ругают Angular за то что вы должны его изучать, чтобы разрабатывать на нем (вс Реакт где вы пишете JS). Но в этом плане ExtJS — это вообще практически свой язык.
Это проблема по множеству причин: найм новых сотрудников, опыт текущих разработчиков, нулевая портативность кода, отсутствие шаренных репозиториев, невозможность использования любых «недо-фич» современного JS вроде Rollup, и тд.
До сих пор все очень плохо со стилезацией, а уж мобильная разработка с Ext, на мой взгляд — вовсе кошмар.
Ну и конечно привязка к исключительно платным компонентам и невозможность их опенсорсно поддерживать, лично в нашем случае, делает невозможным использование ExtJS.
Я не нашел? Может быть вы невнимательно читали, или это не совсем ясно из статьи (хотя я пытался) — я работаю с TypeScript несколько лет, с самых первых версий, еще когда он работал только в Visual Studio.
Это невероятно полезный инструмент, и я желаю всем его хотя бы попробовать. Я даже лекцию в одной очень известной российской конторе делал о нем…
Другое дело — его нужно использовать по назначению.
Команда Angular по какой-то причине этого делать не захотела.
А ES6 классы не работают? Вообще очень печально, если вы не можете понять чем хороши все эти новые недо-фичи в сравнении с весьма спорными и давно устаревшими подходами в Ext.
Про усталость JavaScript'а написано многое, но это не делает webpack менее крутым.
Ну хотите верьте, хотите нет — работал с Ext не один год. Безусловно такой библиотеки контролов нет и не будет ни для одной из описанных библиотек/фреймворков.
Ну так зато они не стоят *тысяч долларов*, а бесплатны и опенсорсны.
А полноценные гриды в серьезных компаниях чаще пишутся либо самостоятельно. Нам в нашем проект Clarity хватило.
В посте есть наш вариант использования с кастингом (после раздела «Другие проблемы»). То есть используется и Vue проверка типа и интерфейс TS.
В VScode оно может и работает, но не через сам пакет линтера — т.к. отдельно он не умеет этого. Соответственно, нельзя запустить на CI — а значит толку от такого линтера немного.
Нам нравится в первую очередь с точки зрения файловой структуры — очень удобно работать с едиными файлами.
С точки зрения IDE работа с .vue файлами очень удобна — подсветка синтаксиса работает, сворачивание, итд.
У нас общие стили вынесены в отдельные обще-проектные стилевые файлы, а компоненты имеют только специфичные им стили. Таким образом стили в .vue довольно небольшие, а то и отсутствуют вовсе.
Примерно так же и для шаблона. Скрипт тег также обычно довольно короткий, так как основная логика находится в store.
Спасибо за пост. Сам хотел нечто подобное описать, т.к. был очень схожий болезненный опыт перехода, но на 5ую версию. Проект также работал без CLI и был довольно увесистый.
Мы решили, что наиболее правильным решением будет перейти на CLI, и несмотря на огромное количество убитого времени (неделя боли и страданий) проект стал работать через CLI и даже с AOT компиляцией. Правда это стало последним каплей и следующие проекты мы делали уже на другом фреймворке...
Хорошим примером полезных добавленных, но позже безвозвратно убранных фич в Angular будет пресловутый роутер, а именно: именованные роуты (да они были) и, например, route reuse.
Про второе вообще можно написать отдельный пост — но суть, что раньше это был просто один параматр вроде
reuse: false, а теперь нужно имплементировать немаленький класс RouteReuseStrategyИменно SFC мы и используем (смотри код стайл раздел), Vue.extend необходим для поддержки TypeScript, примерно как здесь.
Он очень пригодится для Node, но в обычным Vue приложениях считаю слишком большим оверхедом.
Вообще, то же самое касается и vue-property-decorator и vuex-class — как раз то место в статье, где описаны причины использования Vue.extend.
Все эти вещи добавляют дополнительную сложность и TS специфику там, где изначально она не предусмотрена — больше проблем и сложнее поддержка.
Мы стремимся использовать сторонние вещи только по необходимости.
ЗЫ: vuex-class использовал на pet проекте, проблемы были, а большой пользы не ощутил
Но даже так, коэффициэнт который я вижу по ссылке — 1.14, и уж никак не ниже у Angular против Vue. Вы точно сраниваете обычные версии а не с vuex, no-zone и тд?
Поверьте, я хорошо понимаю разницу между миксином и плагином, к тому же написал, что и то и другое — очень полезный функционал.
Поинт в том, что есть степени свободы в сравнении с Angular. Можно также привести пример с computed vs watched property. Опять же, они преследуют разные цели и нужны для разных задач, но новичкам (особенно), не всегда очевидно что использовать и где.
Даже как-то жалко, что даже гугл как-то подзабил на Dart…
Приходилось писать правила для одного из упомянутых коммерческих решений. Работало оно хорошо, но уже одна необходимость использования хардварного лицензионного ключа порождала чудовищное количество проблем.
Пара вопросов:
1. Код еще не смотрел, но планируется ли возможноть писать, или использовать кастомные правила для английского языка? Например в тексте встретится английская имя фамилия которые хотелось бы получать вместе с русскими.
2. Это совсем далекое будущее но тем не менее… RCO и Abbyy помимо сущностей позволяют извлекать собственно факты как действия. То есть связывать сущности в тексте между собой, в основном через глаголы. Нечто подобное хотя бы в далеких планах имеется или основным направлением будет именно извлечение фактов сущностей?
Ну хорошо, что так — исправил уже в английской версии (иначе данный пост придется актуализировать постоянно).
Интересно что тут методы есть, а описания нет: angular.io/api/forms/Validators
Вы должны понимать, что статья писалась не за 1 день (к сожалению) и перепроверять каждую страницу документации angular ежедневно я не имею возможности.
Так что с одной стороны я рад, что API стало чище. А с другой — почему не сделали этого сразу?
На самом деле, если так заострять внимание на классах ES6 — в моем опыте не было случаев когда их функционала не хватало. При всей любви к ООП — не все его фичи так уж востребованны, тем более на фронтенде.
Чем Ext действительно всегда был лучше других — богатая библиотека очень мощных компонентов, такой же нет и не будет ни у одного фреймворка. Но в реальности, даже самым навороченным CRM оттуда кроме основных гридов/деревьев и форм особо ничего больше и не нужно. А купить можно только все целиком. И дорого.
Про тулсет уже писали. Не считаю Sencha CMD хорошей вещью, по той простой причине, что как и все в ExtJS она сделала только для ExtJS.
Собственно тут и есть основной его недостаток — все самописное. Собственные классы были киллер-фичей в далекие времена бесплатного ExtJS 3. Сейчас же большая часть подобных ExtJS решений доступны в вебе и так. ES6 в Хроме есть даже нативно.
И TypeScript — да это превосходный (хоть и не идеальный) язык. Он не раз спасал нашу команду от ночей поиска странных ошибок. Он значительно снизил количество необходимых юнит тестов. И да, там есть классы, со статическими полями и тд.
Спорить о том, что ExtJS делает больше — бессмысленно, это очевидно так. В реальности же, при написании приложения на ExtJS вы пишете ExtJS, а не JS.
Все постоянно ругают Angular за то что вы должны его изучать, чтобы разрабатывать на нем (вс Реакт где вы пишете JS). Но в этом плане ExtJS — это вообще практически свой язык.
Это проблема по множеству причин: найм новых сотрудников, опыт текущих разработчиков, нулевая портативность кода, отсутствие шаренных репозиториев, невозможность использования любых «недо-фич» современного JS вроде Rollup, и тд.
До сих пор все очень плохо со стилезацией, а уж мобильная разработка с Ext, на мой взгляд — вовсе кошмар.
Ну и конечно привязка к исключительно платным компонентам и невозможность их опенсорсно поддерживать, лично в нашем случае, делает невозможным использование ExtJS.
Что объясняет все написанное далее в ветке дискуссии.
Это невероятно полезный инструмент, и я желаю всем его хотя бы попробовать. Я даже лекцию в одной очень известной российской конторе делал о нем…
Другое дело — его нужно использовать по назначению.
Команда Angular по какой-то причине этого делать не захотела.
Про усталость JavaScript'а написано многое, но это не делает webpack менее крутым.
Ну хотите верьте, хотите нет — работал с Ext не один год. Безусловно такой библиотеки контролов нет и не будет ни для одной из описанных библиотек/фреймворков.
Ну так зато они не стоят *тысяч долларов*, а бесплатны и опенсорсны.
А полноценные гриды в серьезных компаниях чаще пишутся либо самостоятельно. Нам в нашем проект Clarity хватило.