Здравствуйте, Jack128, Вы писали:

J>Здравствуйте, Serginio1, Вы писали:

S>>Например Json не поддерживает кучу конструкций Xaml. Насколько ammy перекрывает Xaml?

J>На 100% он покрывает xaml. И не понятно что значит "Json не поддерживает кучу конструкций Xaml"
Например комментарий, свой форматер для дат
https://rsdn.org/forum/flame.comp/6249488.hot

Автор: Нахлобуч
Дата: 19.11.15

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Serginio1, Вы писали:

C>>>Визуальный редактор — это огромный анти-паттерн. Он означает, что UI невозможно нормально положить в репозиторий и работать над ним нескольким людям.
S>>Почему? Чем он хуже ручного ввода?
C>В коде проще смотреть структуру. Вдобавок, при ручном вводе код получается человеческим.
Я вот код набирая всегда пользуюсь интеллисенсом и форматированием и с ужасом смотрю кто этим не пользуется

C>>>И при этом он не сокращает время разработки, совсем.
S>>Поверь сокращает как и интеллисенс
C>Я пробовал, по сравнению с HTML+JS — разницы нет.

Даа? Тот же ангулар, Блазор и разор позволяют использовать интеллисенс. И разница очевидна.
Но им ой как далеко до WPF

Здравствуйте, Serginio1, Вы писали:

S> Например комментарий, свой форматер для дат
S>https://rsdn.org/forum/flame.comp/6249488.hot

Автор: Нахлобуч
Дата: 19.11.15

Именно в ammy всё есть. Он использует json'о подобный, но не полностью совместимый с json язык.

Здравствуйте, Jack128, Вы писали:

J>Здравствуйте, Serginio1, Вы писали:

S>> Например комментарий, свой форматер для дат
S>>https://rsdn.org/forum/flame.comp/6249488.hot

Автор: Нахлобуч
Дата: 19.11.15

J>Именно в ammy всё есть. Он использует json'о подобный, но не полностью совместимый с json язык.
Ну осталоcь, что бы MS сделала поддержку его например в Xamarin.Forms

Здравствуйте, SaZ, Вы писали:

SaZ>Так Qt уже умеет WebAssembly. Да и вообще они далеко замахнулись, но боюсь что будет как с QBS — не пропихнут из-за плохого маркетинга.
Там дело не в маркетенге, до него не дошло, qbs никогда официально не пиарили за пределами блогов. Это внутренняя политика. Я прочитал все доступную переписку по этому вопросу и у меня сложилось впечатление что это решение продавил мэйнтейнер QtCore Thiago Macieira. Он преднамеренно выдвинул не выполнимые для qbs требования: типа быть доступной из коробки в нескольких линуховых дистрибутивах 3 года или что-то такое, он открыто заявлял, что система сборки должны быть "стандартной" (autotools и cmake), даже если она плоха.
Может еще KDABчто-то пообещали, они любят cmake.

В общем в цифром аду есть особое место для Ларша Кнола и Тиаго Масейра

SaZ>Впрочем, у того же Qt есть огромная ниша, куда .net+WPF не влезут — это embedded разработка.
Причем ниша растет семимильными шагами из-за роботизации

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>И все как один — уродские.
ТЫ наверное про WYSIWYG редакторы? НУ да, они не очень.
Мне хватает html редактора в chrome :)

_>>Чем тебе не нравятся существующие?
НС>Тем что они генерят кривой html. Нормальный html написать — даже для человека серьезная задача, требующая большого и специфического опыта, и правильного мышления. WPF в этом плане сильно дружелюбнее.
Ну да, проблема с WYSIWYG редакторами — большая.
Но сейчас тебе не надо писать с нуля все стили для страницы. Подключаешь bootstrap, указываешь стили bootstrap и вуаля — готово.
Похоже с html у тебя не очень. Я сам был таким, потратил недельку упорного труда и теперь не смотрю на html с подозрением.
Сравнивая WPF vs HTML, могу сказать, что таки да, верстка на html более декларативная и понятная. Подключение стилей в css, тоже более понятно, ни каких статический / динамических словарей.

Здравствуйте, white_znake, Вы писали:

_>Сравнивая WPF vs HTML, могу сказать, что таки да, верстка на html более декларативная и понятная. Подключение стилей в css, тоже более понятно, ни каких статический / динамических словарей.

Если посмотреть как они перекрываются то оочень непонятная

Здравствуйте, novitk, Вы писали:

НС>>>>Что там насчет пруфлинка?
N>>>Ты это серьезно?
НС>>То есть ты все придумал. ЧТД.
N>Странные у тебя фантазии. А зачем мне это придумывать?

Да просто Ночной Смотрящий предпочитает жить в своём уютном воображаемом мирке. И если вдруг где-то встречается информация, противоречащая его воззрениям (а отказ кого-то от .net однозначно относится к такой категории), то она тут же классифицируется им как "лживые нападки ненавистников".

Самое забавное, что если бы ты вдруг каким-то образом всё же предоставил ссылку в доказательство своих слов, то это ничего не изменило бы. Он бы просто не стал её читать, а в ответе тебе стёр бы её из цитаты, сделав вид, что там ничего не было и продолжил бы обвинять тебя в выдумках.

Так что по своему опыту могу только посоветовать не тратить время на подобные дискуссии.

Здравствуйте, Serginio1, Вы писали:

S>>>Почему? Чем он хуже ручного ввода?
C>>В коде проще смотреть структуру. Вдобавок, при ручном вводе код получается человеческим.
S> Я вот код набирая всегда пользуюсь интеллисенсом и форматированием и с ужасом смотрю кто этим не пользуется
Ручной ввод, естественно, подразумевает автодополнение и прочие интеллисенсы.

S>>>Поверь сокращает как и интеллисенс
C>>Я пробовал, по сравнению с HTML+JS — разницы нет.
S> Даа? Тот же ангулар, Блазор и разор позволяют использовать интеллисенс. И разница очевидна.
S>Но им ой как далеко до WPF
Причём тут вообще Intellisense? Речь идёт о сравнении с графическим редактором.

Здравствуйте, white_znake, Вы писали:

_>>>Чем тебе не нравятся существующие?
НС>>Тем что они генерят кривой html. Нормальный html написать — даже для человека серьезная задача, требующая большого и специфического опыта, и правильного мышления. WPF в этом плане сильно дружелюбнее.
_>Ну да, проблема с WYSIWYG редакторами — большая.

И проблема эта вызвана тем, что html для этого непригоден. С другой стороны, Blend вполне себе рабочий инструмент. ЧТД.

_>Похоже с html у тебя не очень.

Скорее у тебя не очень. Но я рад что ты перешел от аргументов к личным наездам. Значит понял что не прав.

_> Я сам был таким, потратил недельку упорного труда

Недельку мало. Дзен где то через полгода появится. Так что продолай работать над собой.

_>Сравнивая WPF vs HTML, могу сказать, что таки да, верстка на html более декларативная и понятная.

Здравствуйте, novitk, Вы писали:

НС>>То есть ты все придумал. ЧТД.
N>Странные у тебя фантазии. А зачем мне это придумывать?

Без понятия. Но факт остается фактом — ничем обосновать свои выдумки ты не в состоянии.

Здравствуйте, Ночной Смотрящий, Вы писали:


НС>И проблема эта вызвана тем, что html для этого непригоден. С другой стороны, Blend вполне себе рабочий инструмент. ЧТД.

HTML — непригоден для создания UI?
Что я могу сказать, сейчас в вебе есть только HTML & CSS. Ни чего другого — нет.
А для винды до фига UI фреймворков, помимо WPF. Что как бы намекает :)

НС>Недельку мало. Дзен где то через полгода появится. Так что продолай работать над собой.

Бугага, я в html & css с 2013 :)

_>>Сравнивая WPF vs HTML, могу сказать, что таки да, верстка на html более декларативная и понятная.

НС>:facepalm:

А контраргумент?

Здравствуйте, alex_public, Вы писали:

_>...
_>Вообще то концептуально вся Qt — это один большой "костыль", т.к. занимается самостоятельно прорисовкой всех контролов, мимикрируя под нативный вид платформы с помощью соответствующих (создаваемых по информации из системы) стилей. И на 99,9% у неё это отлично получается, так что многие даже не догадываются, что это не системные контролы.

Нормальное решение. Как я понимаю, в конечном счёте, если не делать кастомизацию через стили, то дёргаются наитивные функции типа винапишного DrawFrameControl. А то что на каждую кнопку не создаётся свой HWND — не вижу в этом проблемы.

_>А вот wxWidgets использует исключительно контролы системы (если они есть — если нет, то дорисовывает свои, но на современных ОС это уже редкость), так что интерфейс нативный на 100%. Причём тут важно не только то, что он выглядит всегда как надо, но и поддержка различных системных вещей (типа удалённого десктопа, инструментов для инвалидов и т.п.).

Кроме удалённого десктопа — не вижу причин использовать wxWidgets, а это очень редкий случай. Аксесебилити уже нормально поддерживается в Qt.
Зато сделать кастомный контрол на wxWidgets на порядок сложнее, чем на Qt.
Субьъективно для меня — ваши аргументы очень незначительны, относительно стоимости разработки на Qt.
Если уж сильно хочется — то пишется лёгкий клиент, который через remote objects работает с серверной частью.

SaZ>>Ну и чисто субьективно — код Qt куда более прозрачный и понятный.
_>Qt написана в ужасном Java стиле, полностью противоречащем стилю современного C++ (который можно увидеть в STL или Boost'е). Да, в последние пару лет они начали процесс движения правильную сторону, но реально на это потребуются десятилетия.

Причём тут джава? Нормальный кодстайл. Главное, что весь фреймворк выдержан в едином стиле. Как внешние API, так и внутренности. Код реально легко читается, в отличие от того же буста (я знаю, почему буст такой, но тем не менее). В Unreal Engine тоже достаточно специфический кодстайл, но тем не менее он работает и работает эффективно.

SaZ>>Это всё не говоря о том, что в Qt помимо GUI есть очень много чего полезного.
_>От Qt интересен только GUI, т.к. всё остальное есть во множестве других библиотек (в первую очередь в Boost'е) и в намного более высоком качестве.

Сигналы/слоты в Qt вообще вне конкуренции.
Интроспекцию в бусте я не трогал (а в Qt достаточно много), ничего не скажу, но слышал что с отладкой там ад, в отличие от Qt.
Не помню, чтобы в бусте были базы данных.
Или что-то удобное для работы с http (обычно все curl прикручивают или поверх asio что-то изобретают). Beast появился не так давно.
Или работа с изображениями (я не про GUI).

Не говоря о том, что если тянуть разные 3rdparty для всего этого добра, то придётся городить кучу проксей, чтобы всё это связать. А Qt умеет практически всё из коробки.

Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, white_znake, Вы писали:

_>>Ты просто не можешь аргументировано спорить. То, что html, css, js развиваются (ну да, старые фреймворки умирают, новые появляются) — это наоборот хорошо. А то, что WPF так и застыл на уровне 2000-х — это ни есть плюс, а скорее минус.
K>:facepalm:
Меньше эмоций, юбольше аргументов.

K>Это хорошо только для короткоживущих говнопроектов хомячков. Ибо реальные приложения надо поддерживать годами, а то и десятилетиями. И "поддерживать" не значит постоянно переписывать на очередной говнофреймворк, которые хомячки объявили "крутым" в определённый момент времени.

Компания, в которой работал, занималась разработкой трейдингового софта с 90-х. в конце 2000-х выпустили клиента на WPF для трейдеров. Потом клиенты компании осознали, что еще больше бабок можно зарабатывать на хомячках, которые решили заработать на трейдинге. И решили заказывать трейдинговые клиенты, работающие через веб. После запуска веб-клиента, сами проф.трейдеры, работающие на клиентов компании, начали переходить с WPF версии на веб-версию.
А потом поступил заказ на разработку мобильной версии трейдингового клиента.
Так что тут мир и технологии меняются и заставляют меняться сами компании, до конца 2000-х широкополосной интернет был не у всех, так же не были распространены смарфтоны, поэтому большинство использовали десктопные приложения. С развитием широкополосного доступа, народ начал мигрировать в веб. Сейчас в мобилки.

Если ты один из разработчиков корпоративного приложения, которое ни куда не собирается мигрировать (нет смысла и все) — это не значит, что у всех такая же ситуация.
Я прошел путь от разработки клиентов на WInAPI, MFC, WPF до разработки веб клиентов на js (как на голом js, так и с использованием ангуляров и реактов) и до мобильной разработки (ionic, kotlin). О чем не жалею.


_>>Не бред, просто посмотри стиль для кнопки на html5 + css3 и аналогичный стиль в XAML. В XAML букв будет больше :)
K>Мдя. Ты точно знаешь WPF?
Знаю ;)
Сравним:

<Button>
<Button.Style>
<Style>
<Setter Property="Control.FontFamily" Value="Calibri"></Setter>
<Setter Property="Control.FontSize" Value="18"></Setter>
<Setter Property="Control.FontWeight" Value="Bold"></Setter>
<Setter Property="Control.Padding" Value="5"></Setter>
<Setter Property="Control.Margin" Value="5"></Setter>
</Style>
</Button.Style> 
</Button>

VS

button {
font-family: calibri;
font-size: 18;
font-weight: bold;
padding: 5;
margin: 5;

_>>Ни кто не заставляет тебя делать продукт на самой первой версии фреймворка.
_>>Я сам не стал изучать Angular1, потому что решил подождать, когда выйдет вторая версия, и не прогадал.
K>Ты какая там нынче версия актуальна? ;)
Angular 6. Но начиная со второй — все обратно совместимы. Но я ни когда на первую версию фреймворка и не перехожу :)

_>>P.S. А в WPF пофиксили необходимость костылей для натягивания MVVM на popups? Или до сих пор "магия" нужна?
K>Если руки растут из правильного места, то ничего никуда натягивать не нужно.
Ну может руки и были кривоваты тогда, а может уже забыл какие-то детали, т.к. с 2013 на WPF не пишу.

Здравствуйте, Cyberax, Вы писали:

S>> Даа? Тот же ангулар, Блазор и разор позволяют использовать интеллисенс. И разница очевидна.
S>>Но им ой как далеко до WPF
C>Причём тут вообще Intellisense? Речь идёт о сравнении с графическим редактором.

А то, что в WPF есть и графический редактор и Intellisense который тебе подскажет какие свйства выбирать, создаст методы по F12 итд.

Там что писать ручками очень мало нужно

Здравствуйте, white_znake, Вы писали:

_>Меньше эмоций, юбольше аргументов.
Это факты и есть.

_>Если ты один из разработчиков корпоративного приложения, которое ни куда не собирается мигрировать (нет смысла и все) — это не значит, что у всех такая же ситуация.
_>Я прошел путь от разработки клиентов на WInAPI, MFC, WPF до разработки веб клиентов на js (как на голом js, так и с использованием ангуляров и реактов) и до мобильной разработки (ionic, kotlin). О чем не жалею.
Ну то есть я прав про короткоживущие говнопроектики. ЧТД

_>Знаю
_>Сравним:
А как насчёт применения стиля только ко кнопкам, отображающую определённую команду? Тут уже внужен говноскрипт — а в WPF можно декларативно

_>Angular 6. Но начиная со второй — все обратно совместимы. Но я ни когда на первую версию фреймворка и не перехожу
ЧТД 2

_>Ну может руки и были кривоваты тогда, а может уже забыл какие-то детали, т.к. с 2013 на WPF не пишу.
ЧТД 3

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, c-smile, Вы писали:

CS>>Для эффективной параллельной обработки "стилей элементов, их границ и т.д." этот самый browser должен реально захватить всю машину — все её cores. Иначе это сплошные context switches.
CS>>Т.е. больше ничего не делать полезного кроме как рисовать UI на том бедном PC. Это путь в никуда.

C>Но реально получается. Насколько я понимаю, они используют его для достаточно крупных блоков.

В абстрактном случае когда browser это единственная программа работающая на PC — да, что-то может ускорится, но не в разы.
Да и то, в то же самое время в потоках работает подкачка ресурсов, видео декодер, WebRTC, WebWorkers и прочая хрень.

На layout calculations в реальных условиях хорошо если хотя бы один core остается.

Весь этот multithread fuzz хорошо если не навредит в итоге. Если сильно повезет то 10% прибавит.

Но это явно не стоит таких титанических усилий.

Здравствуйте, SaZ, Вы писали:

_>>Вообще то концептуально вся Qt — это один большой "костыль", т.к. занимается самостоятельно прорисовкой всех контролов, мимикрируя под нативный вид платформы с помощью соответствующих (создаваемых по информации из системы) стилей. И на 99,9% у неё это отлично получается, так что многие даже не догадываются, что это не системные контролы.
SaZ>Нормальное решение. Как я понимаю, в конечном счёте, если не делать кастомизацию через стили, то дёргаются наитивные функции типа винапишного DrawFrameControl. А то что на каждую кнопку не создаётся свой HWND — не вижу в этом проблемы.

Основные инженерные минусы этого решения не в HWND:

— интерфейс конечно же выглядит нативно (Qt в этом смысле хороша, но за счёт чисто экстенсивных усилий), но всё же не на 100% (иногда проскальзывают отличия)
— огромная часть кода приложения занята банальном эмуляцией поведения ОС, на которой при этом исполняется. Т.е. просто глупо.
— не все функции ОС (это мы обсуждали уже ниже) работают с таким GUI.

_>>А вот wxWidgets использует исключительно контролы системы (если они есть — если нет, то дорисовывает свои, но на современных ОС это уже редкость), так что интерфейс нативный на 100%. Причём тут важно не только то, что он выглядит всегда как надо, но и поддержка различных системных вещей (типа удалённого десктопа, инструментов для инвалидов и т.п.).
SaZ>Кроме удалённого десктопа — не вижу причин использовать wxWidgets, а это очень редкий случай. Аксесебилити уже нормально поддерживается в Qt.

Использовать wxWidgets для программирования GUI на десктопе стоит хотя бы потому, что там это можно делать на нормальном чистом C++, а не на неком сомнительном убожестве, требующем препроцессора.

SaZ>Зато сделать кастомный контрол на wxWidgets на порядок сложнее, чем на Qt.

С чего бы это? Сделать кастомный контрол было просто даже на банальном WinAPI. А уж на Qt и wxWidgets вообще по сути нет никаких отличий — наследуешься от нужного класса и рисуешь что хочешь. Только вот качественная GUI библиотека как раз и отличается тем, что там таким в большинстве случаев страдать не надо — есть уже готовый набор качественных контролов нативного вида.

SaZ>Субьъективно для меня — ваши аргументы очень незначительны, относительно стоимости разработки на Qt.
SaZ>Если уж сильно хочется — то пишется лёгкий клиент, который через remote objects работает с серверной частью.

А откуда взялось мнение, что стоимость разработки (естественно если говорить про GUI для десктопа) у wxWidgets и Qt отличаются?

SaZ>>>Ну и чисто субьективно — код Qt куда более прозрачный и понятный.
_>>Qt написана в ужасном Java стиле, полностью противоречащем стилю современного C++ (который можно увидеть в STL или Boost'е). Да, в последние пару лет они начали процесс движения правильную сторону, но реально на это потребуются десятилетия.
SaZ>Причём тут джава? Нормальный кодстайл. Главное, что весь фреймворк выдержан в едином стиле. Как внешние API, так и внутренности. Код реально легко читается, в отличие от того же буста (я знаю, почему буст такой, но тем не менее). В Unreal Engine тоже достаточно специфический кодстайл, но тем не менее он работает и работает эффективно.

Я говорю не про оформление, а про архитектуру. В которой сплошные указатели, виртуальные функции, динамическая память, COW, позднее связывание и т.п. Это полностью противоречит современному C++, в котором отдаётся преимущество типам-значениям, семантики перемещения, статическому полиморфизму, шаблонам и т.п. Причём делается не из-за каких-то "вкусов", а из-за того, что такой код намного надёжнее и производительнее.

В последние несколько лет в Qt это осознали и начали постепенное движение в направление нормального C++. Например отказываются от своих контейнеров (которые как раз COW), в пользу STL (где типы-значения, оптимизированные семантикой перемещения), добавляют нормальное (прямое) связывание функций (в том числе и лямбд) с сигналами и т.д. и т.п. Но с учётом огромных размеров этого монстра, похожим на нормальный C++ он станет только через десятилетия таких усилий.

И да, всё вышеперечисленное оставляло за скобками такую дикую ересь, как специальный препроцессор, который для решения задач GUI библиотеки не нужен в принципе. Пока они от него не избавятся, говорить о нормальном C++ будет нельзя. Ну и кстати говоря, с учётом последних добавок к механизму связывания, это вполне можно было бы сделать, но к сожалению, не смотря на эти добавки, все их инструменты продолжают использовать старые механизмы.

SaZ>>>Это всё не говоря о том, что в Qt помимо GUI есть очень много чего полезного.
_>>От Qt интересен только GUI, т.к. всё остальное есть во множестве других библиотек (в первую очередь в Boost'е) и в намного более высоком качестве.
SaZ>Сигналы/слоты в Qt вообще вне конкуренции.

Это убогая динамическая хрень, корректность работы которой компилятор в принципе не способен проверить? Даже не смешно...

SaZ>Интроспекцию в бусте я не трогал (а в Qt достаточно много), ничего не скажу, но слышал что с отладкой там ад, в отличие от Qt.

Интроспекции в Бусте очевидно нет, т.к. её нет (до прихода стандарта C++23) в самом языке. То, что в Qt с помощью препроцессора делается некая динамическая (ужасно не эффективно с точки зрения языков типа C++) надстройка — это не преимущество, а недостаток.

SaZ>Не помню, чтобы в бусте были базы данных.

Я говорил не только про Boost.

SaZ>Или что-то удобное для работы с http (обычно все curl прикручивают или поверх asio что-то изобретают). Beast появился не так давно.
SaZ>Или работа с изображениями (я не про GUI).
SaZ>Не говоря о том, что если тянуть разные 3rdparty для всего этого добра, то придётся городить кучу проксей, чтобы всё это связать. А Qt умеет практически всё из коробки.

Да, умеет много чего из коробки. Но всё (кроме GUI) хреновенько так, на троечку, если сравнивать с отдельными профильными инструментами.

P.S. Забавно так спорить с фанатом Qt, хотя при этом я сам использую Qt для GUI всех своих проектов. ))) Только вот я осознаю, что делаю это от безысходности: Qt — ужасна, но ничего лучшего для GUI с такой же кроссплатформенностью нет.

Здравствуйте, white_znake, Вы писали:

НС>>И проблема эта вызвана тем, что html для этого непригоден. С другой стороны, Blend вполне себе рабочий инструмент. ЧТД.
_>HTML — непригоден для создания UI?

Перечитай еще раз для чего он непригоден.

_>А для винды до фига UI фреймворков, помимо WPF. Что как бы намекает

Уга, намекает что ты споришь с голосами в голове.

НС>>Недельку мало. Дзен где то через полгода появится. Так что продолай работать над собой.
_>Бугага, я в html & css с 2013

А я с 2001. Так что у меня все равно длинее, и мерянье можно заканчивать.

_>>>Сравнивая WPF vs HTML, могу сказать, что таки да, верстка на html более декларативная и понятная.
НС>>
_>А контраргумент?

А смысл, если ты про WPF ничего почти не знаешь? Все равно ведь не поверишь.

Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, white_znake, Вы писали:

_>>Меньше эмоций, юбольше аргументов.
K>Это факты и есть.

_>>Если ты один из разработчиков корпоративного приложения, которое ни куда не собирается мигрировать (нет смысла и все) — это не значит, что у всех такая же ситуация.
_>>Я прошел путь от разработки клиентов на WInAPI, MFC, WPF до разработки веб клиентов на js (как на голом js, так и с использованием ангуляров и реактов) и до мобильной разработки (ionic, kotlin). О чем не жалею.
K>Ну то есть я прав про короткоживущие говнопроектики. ЧТД :facepalm:

Нет, не прав, чисто твои додумки. WPF клиент прожил с 2008 по 2012, в 2013 от него отказали окончательно. Веб клиент живет с 2012 по текущее время, живет и развивается.
Мобильный клиент живет с 2014.

Выводы сделаешь сам.

_>>Знаю ;)
_>>Сравним:
K>А как насчёт применения стиля только ко кнопкам, отображающую определённую команду? Тут уже внужен говноскрипт — а в WPF можно декларативно ;)

Что значит отображающую определенную команду? Может имел ввиду привязку к команде?
Задай стили в CSS:

button.ok{

}

button.cancel {
}

а потом используй:

<button class="ok" (click)="ok()">OK</button>
<button class="cancel" (click)="cancel()">Cancel</button>

Не менее декларативно :)

_>>Angular 6. Но начиная со второй — все обратно совместимы. Но я ни когда на первую версию фреймворка и не перехожу :)
K>ЧТД 2
А ты переходил на .NET 1.0? И Silverlight небось использовал, при драфте html5 & css3? :)