Comments 9
Спасибо за перевод! В целом познавательная статья, правда я ещё больше убедился, что не хочу использовать QML и то что это зло (для такого DE как KDE так точно).
Почему же? Ведь код написанный на QML всё равно будет работать быстро, как будто он писан на C++. Я вот честно — не могу понять. почему некоторые разработчики его не любят. Объясните пожалуйста?
В Qt рассылке был очень хороший тред где приводились примеры почему QML плох для тех или иных задач, увы ссылку с ходу не нашёл (это было по поводу прекращения поддержки QtGui).
1. Работает быстро но грузится всё равно дольше.
2. Работает не очень быстро при взаимодействии с внешним миром (там приводились примеры когда вызов из JS ооочень медленный, видимо особенности работы object wrapper и content wrapper). Как правило приложения они не просто GUI в вакууме.
3. По началу в QML не было никакой интеграции с десктопом, в 4.7 она появилась но тоже имеет ряд ограничений (это означает что красивые приложения делать было можно но интегрированные в рабочую среду — нини). Сейчас вроде с этим лучше.
4. Не всем нравится декларативный стиль, не всем нравится винегрет из технологий (честно я уже в вебе накушался этими CSS, HTML, JS… в диких связках).
5. Есть люди которые любят просто С++, а так же при должном подходе оно будет работать полюбому быстрее чем QML (JIT хорош но не быстрее C++).
Если подытожить то получим, что QML это просто инородная технология для C++ GUI программистов, к тому же она имеет свои неоднозначности.
1. Работает быстро но грузится всё равно дольше.
2. Работает не очень быстро при взаимодействии с внешним миром (там приводились примеры когда вызов из JS ооочень медленный, видимо особенности работы object wrapper и content wrapper). Как правило приложения они не просто GUI в вакууме.
3. По началу в QML не было никакой интеграции с десктопом, в 4.7 она появилась но тоже имеет ряд ограничений (это означает что красивые приложения делать было можно но интегрированные в рабочую среду — нини). Сейчас вроде с этим лучше.
4. Не всем нравится декларативный стиль, не всем нравится винегрет из технологий (честно я уже в вебе накушался этими CSS, HTML, JS… в диких связках).
5. Есть люди которые любят просто С++, а так же при должном подходе оно будет работать полюбому быстрее чем QML (JIT хорош но не быстрее C++).
Если подытожить то получим, что QML это просто инородная технология для C++ GUI программистов, к тому же она имеет свои неоднозначности.
1) Куда деваться, таковы все парсеры.
2) Никто не требует писать эту часть на QML
3) Да, сейчас всё классно есть qt components for desktop
4) Здесь декларативный стиль он хоть и декларативен донельзя, но всё же очень хорошо продуман.
5) Поддержка QtWidgets никуда не пропадает.
Как бы все эти недостатки кроются одной вещью — QML привносит полноценную кроссплатформенность в C++, при которой нет необходимости перекомпилировать своё приложение для win, mac, lin, ios, android — всё таки будет запускаться на самом разном железе и даже не разных архитектурах процессоров (конечно когда будет лаунчер стандартный на всех платформах). А ведь именно это ставили своей целью разработчики Java и C# в своё время.
2) Никто не требует писать эту часть на QML
3) Да, сейчас всё классно есть qt components for desktop
4) Здесь декларативный стиль он хоть и декларативен донельзя, но всё же очень хорошо продуман.
5) Поддержка QtWidgets никуда не пропадает.
Как бы все эти недостатки кроются одной вещью — QML привносит полноценную кроссплатформенность в C++, при которой нет необходимости перекомпилировать своё приложение для win, mac, lin, ios, android — всё таки будет запускаться на самом разном железе и даже не разных архитектурах процессоров (конечно когда будет лаунчер стандартный на всех платформах). А ведь именно это ставили своей целью разработчики Java и C# в своё время.
1. «Поддержка QtWidgets никуда не пропадает.» — но они на неё решили забить и не развивать.
2. «QML привносит полноценную кроссплатформенность в C++» — только если не встречается пункт номер 2. А коль приложения у нас живые то возникать такое будет часто. К примеру GUI к какой нить закрытой .so/.dll где даже из C++ приходится делать кучу wrappers.
Я не столько против QML (даже нравится в целом) сколько понимаю её ограниченность для десктоп приложений. Небольшие и средние приложения не зависимые ни от чего кроме Qt — вот это зона ответственности QML. Только всё это можно было и на C++ делать не намного дольше…
ЗЫ а для windows всё равно ведь .exe собирать для распространения? :(
2. «QML привносит полноценную кроссплатформенность в C++» — только если не встречается пункт номер 2. А коль приложения у нас живые то возникать такое будет часто. К примеру GUI к какой нить закрытой .so/.dll где даже из C++ приходится делать кучу wrappers.
Я не столько против QML (даже нравится в целом) сколько понимаю её ограниченность для десктоп приложений. Небольшие и средние приложения не зависимые ни от чего кроме Qt — вот это зона ответственности QML. Только всё это можно было и на C++ делать не намного дольше…
ЗЫ а для windows всё равно ведь .exe собирать для распространения? :(
Я согласен, технология ещё совсем молодая. Но давайте дадим ей шанс? Вот когда она переболеет всеми детскими болезнями, тогда возможно мы увидим действительно нечто потрясающее.
Некоторые российские компании используют QML и на android, например 2ГИС и Мобильная Торовля(Систех), технология вполне живая, особых проблем в общем нет(точнее они есть, но связанны больше с использованием под андроид). Единственное что меня коробит, это невозможность передать qt объект в QML по значению. Нужно всегда передавать только по ссылке. Это сильно раздражает, потому что не всегда удобно динамически выделять память, и умные указатели то же не по используешь.
Если про использование NOTIFY можно было догадаться, ибо штука чрезвычайно часто юзается, то про преобразование выражения в функцию движка V8 было достаточно интересно почитать, спасибо!
P.S. QML действительно быстро работает.
P.S. QML действительно быстро работает.
Sign up to leave a comment.
Внутренности движка QML. Часть 2: Привязки