Я всё понял но зачем такое извращение!? Куда проще поставить Unix и набрать что то типо emerge -v nginx,apache, memcached, php, mongodb? Оно к тому же и работать будет шустрее…
если вы не занимаетесь .NET то windows в веб разработке очень вреден.
А кто справляется с тем что MVC для публичных сайтов входит в противоречие с SEO? Да и вообще подход WebApp в место набора web pages непонятно как оптимизировать для поисковиков.
Целый месяц промучился с ExtJS после чего плюнул и ушёл в Dojo.
ExtJS имеет ооочень много ограничений, связанных с декларативной и жёсткой структурой описания GUI.
К примеру если у вас переменное количество checkbox или radiobutton то просто так это не делается. Есть плагин который это реализует но уже за дополнительный запрос к серверу что бред.
А в Dojo к тому же есть возможность писать UI прям в html, декларативно — на порядок удобнее чем эти огромные { }…
А если что то простое нужно то однозначно MochiKit верный друг уже много лет. ;) Жалко о нём мало кто знает.
1. «Поддержка QtWidgets никуда не пропадает.» — но они на неё решили забить и не развивать.
2. «QML привносит полноценную кроссплатформенность в C++» — только если не встречается пункт номер 2. А коль приложения у нас живые то возникать такое будет часто. К примеру GUI к какой нить закрытой .so/.dll где даже из C++ приходится делать кучу wrappers.
Я не столько против QML (даже нравится в целом) сколько понимаю её ограниченность для десктоп приложений. Небольшие и средние приложения не зависимые ни от чего кроме Qt — вот это зона ответственности QML. Только всё это можно было и на C++ делать не намного дольше…
ЗЫ а для windows всё равно ведь .exe собирать для распространения? :(
В 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 программистов, к тому же она имеет свои неоднозначности.
Спасибо за перевод! В целом познавательная статья, правда я ещё больше убедился, что не хочу использовать QML и то что это зло (для такого DE как KDE так точно).
40мс это норма, так что бы гарантировано нигде не дёргалось. Ниже это только для звукозаписи живых инструментов критично.
А так я могу и 4мс выжать, в целом держало но всегда был шанс что будут гличи. Я просто чаще музыку пишу, и там много всяких синтюков и прочего по этому выбираю баланс.
ЗЫ с 40мс даже нормально играть на миди клаве! Хотя возможно это дело привычки.
если вы не занимаетесь .NET то windows в веб разработке очень вреден.
ExtJS имеет ооочень много ограничений, связанных с декларативной и жёсткой структурой описания GUI.
К примеру если у вас переменное количество checkbox или radiobutton то просто так это не делается. Есть плагин который это реализует но уже за дополнительный запрос к серверу что бред.
А в Dojo к тому же есть возможность писать UI прям в html, декларативно — на порядок удобнее чем эти огромные { }…
А если что то простое нужно то однозначно MochiKit верный друг уже много лет. ;) Жалко о нём мало кто знает.
Надеюсь я ещё увижу закат x86…
2. «QML привносит полноценную кроссплатформенность в C++» — только если не встречается пункт номер 2. А коль приложения у нас живые то возникать такое будет часто. К примеру GUI к какой нить закрытой .so/.dll где даже из C++ приходится делать кучу wrappers.
Я не столько против QML (даже нравится в целом) сколько понимаю её ограниченность для десктоп приложений. Небольшие и средние приложения не зависимые ни от чего кроме Qt — вот это зона ответственности QML. Только всё это можно было и на C++ делать не намного дольше…
ЗЫ а для windows всё равно ведь .exe собирать для распространения? :(
1. Работает быстро но грузится всё равно дольше.
2. Работает не очень быстро при взаимодействии с внешним миром (там приводились примеры когда вызов из JS ооочень медленный, видимо особенности работы object wrapper и content wrapper). Как правило приложения они не просто GUI в вакууме.
3. По началу в QML не было никакой интеграции с десктопом, в 4.7 она появилась но тоже имеет ряд ограничений (это означает что красивые приложения делать было можно но интегрированные в рабочую среду — нини). Сейчас вроде с этим лучше.
4. Не всем нравится декларативный стиль, не всем нравится винегрет из технологий (честно я уже в вебе накушался этими CSS, HTML, JS… в диких связках).
5. Есть люди которые любят просто С++, а так же при должном подходе оно будет работать полюбому быстрее чем QML (JIT хорош но не быстрее C++).
Если подытожить то получим, что QML это просто инородная технология для C++ GUI программистов, к тому же она имеет свои неоднозначности.
Как пользовался Pylons так и буду дальше использовать. (или Tornado для чего то небольшого)
А так я могу и 4мс выжать, в целом держало но всегда был шанс что будут гличи. Я просто чаще музыку пишу, и там много всяких синтюков и прочего по этому выбираю баланс.
ЗЫ с 40мс даже нормально играть на миди клаве! Хотя возможно это дело привычки.