Как я начал любить Vue

С кастингом решение совсем никуда не годится, я думал Vue уже научился из коробки делать как-то так Vue.extend<DemoGridProps, DemoGridData>({...}) habr.com/post/351216/#comment_10716424

Как я начал любить Vue

То есть пропсы не типизированы?

Обновляем Angular до 6-ой версии в проекте без использования CLI

каких-то проблем по переходу с Angular 5 на Angular 6 я не увидел.

Потому что проблем нет, тоже без CLI обновлялся, по сути только небольшиме изменения связанные RxJS потребовались и они выполнялись автоматически скриптом предоставленным самой же RxJS командой.

Обновляем Angular до 6-ой версии в проекте без использования CLI

Неделя времени не так и много учитывая что у CLI много преимуществ в случае работы в команде и над долгосрочным проектом. Хотя он и кривоватый местами, и не дает возможность пост-конфигурирования вебпак конфига.

Обновляем Angular до 6-ой версии в проекте без использования CLI

В свое время просто сделал eject конфига из Angular CLI, выбросил то что не нужно было и таким образом без CLI живу с 4й версии. С выходом новой версии повторял процесс, это муторно на самом деле, но зато понятнее что они там понаделали с вебпаком. Но это для простого опенсорс проекта, в случае работы в команде и в компании выбрал бы CLI конечно.

Обновляем Angular до 6-ой версии в проекте без использования CLI

Angular 6 по-умолчанию использует Webpack 4

Angular CLI, самому Angular Webpack без надобности.

Как я начал любить Vue

Это одна из причин почему удобнее держать скрипты, стили и шаблон в разных файлах.

Как я начал любить Vue

PPS: Кстати английский вариант предыдущей статьи был настолько успешен, что у меня даже состоялось прямое общение (видео) с основными виновниками — но работу не предложили =(

Статей от товарищей с реальным опытом немного, в основном все по верхам, успешность заслуженная.

Как я начал любить Vue

А чем удобно все сваливать в один файл? Я бы делал шаблон в этом vue файле, а скрипт и стили подключал обычным образом (link / script теги) — vue поддерживает такой подход. Тогда получились бы трех файловые компоненты, что как по мне удобнее по многим причинам, а на выходе после сборки пускай это будет 1 файл.

Безопасный SOCKS5 прокси для Telegram за 1 Евро и 10 минут

Именно так. Как и аналогичные предложения с LeS lowendspirit.com/locations.html

Безопасный SOCKS5 прокси для Telegram за 1 Евро и 10 минут

Брал у них под VPN на год во Франции, все в целом было норм.

Строгая типизация для приложений Vue.js на TypeScript

Сразу скажу с Vue не работаю, но сказать что имею. Разве явный каст

as DemoGridData

во множестве мест не нивелирует преимущества строгой типизации? Вот подумайте, чтобы сделать каст, вам нужно знать во что кастить в том или ином случае, и так в каждом участке кода, ошибиться с таким кастом очень легко, создается видимость что типизация есть, когда в полноценном виде ее нет. То есть по хорошему типы для props и data нужно бы при их объявлении указать один раз и дальше никогда каст/as не делать. Вот vue-class-component пропаганирует подобный подход, но не ваш пример. И например, абстрактно, с дженериками это могло бы выглядеть как-то так

Vue.extend<DemoGridProps, DemoGridData>({...})

Кроме того, интерфейсы дают возможность повторного использования определений типов для входных и выходных данных Vue-компонент. Ведь тип входных данных одной компоненты часто совпадает с выходными данными другой.

Разве нельзя использовать интерфейсы совместно с vue-class-component (прямо в декораторе, вместо инлайн описания типа)?

PS если уж хочется делать явный каст, то почему не один раз, например так (и можно развить идею, вынести метод cast в базовый класс и сделать его generic, тогда DemoGridData/DemoGridProps фигурировали бы только одни раз в шапке класса как generic параметры):

cast() {
    return {
        $data: this.$data,
        $props: this.$props,
    } as {$data: DemoGridData, $props: DemoGridProps};
}

И далее использовать как-то так:

    const {$data, $props} = this.cast();
    ...

Immer: новый подход к иммутабельности в JavaScript

Здесь immer подход поддерживается как частный случай github.com/hydux/hydux-mutator

Удивительный Angular

options.add5ton && weight += 5000;

Такой код приведет к ошибке, в случае присвоений выражение нужно в скобки брать options.add5ton && (weight += 5000);

Я так раньше тоже писал, но перестал, считаю плохим тоном, ну и точку дебага так просто не поставишь на true или false. Линтеры для того и нужны чтобы стиль кодирования был консистентным, и это для меня это важнее нескольких лишних строк кода.

Удивительный Angular

Зачем на всех ровняться? Не забывайте что во фронт-енд разработке большая часть скрипт-кидди.

Удивительный Angular

Соглашусь что родной роутинг кривоватый (допустим навигация из лейзи модулей как внутри так и глобально как-то нелогично работает, баги непофикшенные давно висят в гитхабе), а вот как ui router с ангуляром?

Удивительный Angular

Кстати с какой ошибкой падает? По логике при типе any ошибки быть не должно. Есть у меня догадка что у вас падает линтинг, тк в в CLI вроде codelyzer рулы настроны на {{ data.field }} формат выражения, а не {{data.field}} (то есть с пробелами нужно). PS лучше any использовать поминимуму и включить stric:true опцию компиляции TS.

Удивительный Angular

Что значит dev и prod, имеется ввиду CLI на настройка по умолчанию? Там в prod AOT включен и fullTemplateTypeCheck поставлен в true если не ошибаюсь, а в dev по уполчанияю это выключено, но скоро планирубт включить. Но вообще можно ведь настроить как угодно сборку, не полагаясь на CLI (который кривоватый в целом). Включите себе AOT и fullTemplateTypeCheck в dev режиме и будет более строгая валидация.

Удивительный Angular

Опять же, из-за переусложнённой архитектуры, требующей кучу приседаний, вам просто жизненно необходимы кодогенераторы. Ибо на каждый компонент нужно создать от 4 файлов и провязать их друг с другом и приложением.

Кодогенерация совсем не обязательна, моем мнение что это зло, возможно допустимое для начинающих. CLI тоже зло как по мне, возможно допустимое для начинающих.

Вы можете написать любую чушь в них и они мало того, что скомпилируются, но даже в рантайме не выдадут ошибок — у вас просто что-то не отрендерится.

Это вы когда последний раз ангуляр пробовали?

Удивительный Angular

из коробки Angular показывает довольно невысокую оптимизацию

Даже если CLI использовать?
Но понимать хотя бы onPush в связке с иммутабельным стором желетельно, что не идет из коробки вместе с CLI.
PS лично я не большой сторонник использования CLI, но в реальности выбор зависит от проекта и команды.