После трёх лет разработки представлен (http://www.cutelyst.org/2016/11/10/cutelyst-1-0-0-with-stabl...) первый стабильный релиз фреймворка Cutelyst (http://www.cutelyst.org), предоставляющего средства для разработки web-приложений с использованием технологий Qt и MVC-парадигмы в стиле Perl-фреймворка Catalyst (http://www.catalystframework.org/). В выпуске Cutelyst 1.0.0 объявлено о стабилизации API и ABI, которые в дальнейшем будут развиваться с обеспечением обратной совместимости. Код проекта написан на языке C++ и распространяется (https://github.com/cutelyst/cutelyst/) под лицензией LGPLv2+.
Ключевым достоинством Cutelyst является возможность быстро создавать высокопроизводительные web-приложения на языке C++, используя единую кодовую базу с уже существующими проектами. Например, для работы в виде web-приложения можно адаптировать программу, написанную для настольных или мобильных систем. Cutelyst имеет модульную структуру и позволяет подключать различные серверные HTTP-движки и шаблонизаторы. Например, Cutelyst может использовать как встроенный HTTP-сервер Cutelyst-WSGI, так и работать под управлением внешних серверов при помощи протоколов FastCGI или uWSGI.
Для отделения кода C++ от HTML предлагается использовать шаблонизаторы ClearSilver (http://www.clearsilver.net/) и Grantlee (http://www.grantlee.org/) (синтаксис, как в Django) или генерировать вывод в формате JSON. Загрузка данных в формате JSON автоматически транслируется в QJsonDocument. При помощи дополнительных плагинов предоставляются готовые средства для управления сеансами, аутенитификации (с поддержкой PBKDF2) и управления доступом (RoleACL). Поддерживается обработка запросов в асинхронном режиме. Для упрощения разработки приложений предоставляются средства для интеграции с QtCreator.URL: http://www.cutelyst.org/2016/11/10/cutelyst-1-0-0-with-stabl...
Новость: http://www.opennet.ru/opennews/art.shtml?num=45487
Кто-нибудь уже собрал Qupzilla для cutelyst?
Отлично! Различные наработки для разработки web-приложений на Qt были уже давно. Похоже, теперь дело выходит на новый уровень.
В идеале бы еще и QML полноценно в веб перенести
https://qmlweb.github.io/
> https://qmlweb.github.io/Этому далеко ещё до полноценности
Ждем ассемблер, а то С++ не достаточно сурово для веба.
Для ассемблера вряд ли дождемся, но для C есть неплохие фреймворки: lwan и G-wan. Очень быстро молотят Json. Так что, для отдельных вещей, чтобы пуляли по максимуму, можно использовать.
JSMN лучший по скорости парсер json в добавок к G-wan. Iwan не нашёл, поделись ссылкой.
так Lwan же, а не iwan
WebAssembly. Coming Soon. Feb 2017.Скоро на всех экранах веб-макак.
Древесная лягушка с Вами не согласна.
Очень интересно будет взглянуть на результаты 14 раунда TechEmpower, который они планируют провести. Тогда все станет ясно. У них уже есть неплохой конкурент - Treefrog.А по поводу C++ для Web. Для C++ программиста, который уже по всем граблям сходил, на C++ писать Web - одно удовольствие.
С treefrog этот cutelyst сравнивать еще рано, там уровень model вообще пока что отсутствует. А это самая небанальная часть.
> С treefrog этот cutelyst сравнивать еще рано, там уровень model вообще пока
> что отсутствует. А это самая небанальная часть.Да и судя по https://www.techempower.com/benchmarks/previews/round13 , где Treefrog поднакачался и пульнул соревноваться с urlib, ему будет очень нелегко на него равняться =)
13й раунд еще вроде preliminary results:
https://www.techempower.com/benchmarks/previews/round13/
Да, но зависимость от Qt + LGPL = досвидос
Разработчик Cutelyst - Daniel Nicoletti - тот еще знатный бракодел.
Формула успеха:
1) я придумал что-то новое и крутое, пока что это только proof of concept, хаха
2) о, нужная вещь, давайте сразу берем в апстрим
3) слишком много багов
4) забросить проект и goto 1KPackageKit/apper
print-manager
colord-kde
sessionKмногим эти названия не скажут решительно ничего, но КДЕ-шники, возможно, поймут мою боль.
> KPackageKit/apperЕсли забыть снести это при установки openSUSE, вместе с PA и NM, то работать на этой системе трудно.
> Если забыть снести это при установки openSUSE, вместе с PA и NM, то работать на этой системе трудно.Как раз в openSUSE PA и NM отключаются элементарно, можно даже несколькиими кликами мышкой, так что их можно даже не "сносить".
> KPackageKit/apper
> print-manager
> colord-kde
> sessionK
> многим эти названия не скажут решительно ничего, но КДЕ-шники, возможно, поймут мою
> боль.По уровню:
http://s4.pikabu.ru/post_img/2015/11/01/12/1446410235_119011...
тоже вроде как стильно и все такое, но с практической точки зрения ...
классная пикча. вся сущность современного веба в одной картинке.
сиплюсплюс головного мозга
заболевание видимо настолько сильное
что поциент деградирует и не способен осилить нормальные технологии, предназначеные для web
Это нода.жс что ли нормальная технология?
то был глас пыхпышника. Ниосилятора плюсов.
Пока ты будешь ашвабаждать память, появится павел дуров и быстренько напишет годный ( = денежный) стартапчик на пыхе. А ты в это время все еще будешь ашвабаждать память.
Мне кажется, для того, чтобы сравнивать что-то с С++, нужно помимо чего-то еще знать и С++. В С++ уже давно есть инструменты для автоматического освобождения памяти. Тем более в Qt это вообще заложено в структуру фреймворка.
Назови преимущества С++ перед пыхом/нодежс в условиях веба. Именно в плане обработки вводимых пользователем форм и прочих штук вроде выборки из базы и отображения записей. (А как правило только это и требуется.) С точки зрения бизнеса в том числе. (Чем окупится время, которое требуется для С++ в гораздо большем объеме, чем для пыха/нодежс? Как быть с конкурентами, которые напишут аналогичное на пыхе/нодежсе за пару месяцев, а не за пару кварталов? Как быть с поддержкой кода? -- пыхо/нодежс-разрабов в веб-девелопменте существенно больше, чем С++-ников)Давай простейший пример возьмем: мне приходит строка в виде JSON. Мне надо извлечь из нее значение свойства. На JS это можно сделать за 3 секунды: JSON.parse(string).property. Как это сделать за 3 секунды на С++ и в одну строку?
Не нужно спорить с хелоуворлдщиками, они об обязанностях перед заками и о конкурентах знать не знают.
На одной и той же машине, сериализация того же самого JSON:
Lwan (С): 479,281 rps
Treefrog (С++): 298,740 rps
PHP: 43,759 rpsОтвет на ваш вопрос:
QJsonDocument::fromJson(string).object()["property"]; // только это будет в (298 740/43 759 =) 6,83 раза быстрее.Выборка из БД:
TSqlQuery q; q.prepare("SELECT * FROM table WHERE a = ?"); q.addBind("Blah");
QVariantList l;
if (q.exec()) {
while (q.next()) { QVariantMap m; m["c1"] = q.value(0); m["c2"] = q.value(1); l << m; }
}
renderJson(l);
> Чем окупится время, которое требуется для С++ в гораздо большем объемеТем, что у Вас не украдут десяток-другой миллионов учётных записей?
Наивный мальчик. Всё хорошо у ноды с пыхом... до появления серьёзной бизнес-логики. А дальше - либо валить на джаву, либо, может, правда плюсы подтянутся.Прокладку между базой и джаваскрипт-мордой - пофиг на чём писать, это да - где скорости не хватит - кэши спасут, всё равно 95% нагрузки на них держится.
> Давай простейший пример возьмем: мне приходит строка в виде JSON. Мне надо извлечь из нее значение свойства. На JS это можно сделать за 3 секунды: JSON.parse(string).property. Как это сделать за 3 секунды на С++ и в одну строку?FTR:
Json::Value value; Json::Reader().parse(string, value); value["property"];
Чуть сложнее, но вполне себе.
> Назови преимущества С++ перед пыхом/нодежс в условиях веба.В условиях веба понадобится меньше серверов для обслуживания сайта. Экономия за счет быстродействия.
как пример-факебук. У них свой интертрепатор PHP. Специально написали.
Twitter - руби, например, изначально был.
Одноклассники - C#.
Bootcamp - Ruby.
Dropbox - Python.Ну-ка, ну-ка?
Перечисленные тобой языки как раз хороши для веба. А вот С++ изначально под него не адаптирован.
> Перечисленные тобой языки как раз хороши для веба. А вот С++ изначально
> под него не адаптирован.Плюсы изначально вообще ни под что не адаптированы. В том и их фишка - это конструктор, из которого можно собрать хоть коляску, хоть пулемёт. Взял с одной стороны - получил Qt. Взял с другой - OpenCV. Взял с третьей - ардуино. И веб там можно сделать не хуже всего прочего.
Вообще, похороны PHP/JS/Python в вебе - дело ближайших пяти лет максимум. Просто потому, что сложность задач растёт, и ей разве что питон кое-как может соответствовать - так у него со скоростью беда, плюс на больших проектах статическая типизация и прочая "бюрократия"- необходимость. С другой стороны - C++11/14, Go, возможно Rust стали попроще, чем старые плюсы, шустры и более удобны для больших проектов. И, скорее всего, через год на них вполне можно будет писать для браузера. Или какой-то новый язык придёт, но то, во что превращаются в больших объёмах PHP и JS - это как на известной картинке - гордая конструкиця из велосипедов и костылей.
> Плюсы изначально вообще ни под что не адаптированы. В том и их фишкаТы предпочитаешь готовый набор инструментов или компоненты для изготовления инструментов? Реалии веба требуют, чтобы инструментарий уже был. А в плюсах из хлебушка трамвай еще только предстоит построить, так что сразу не покатаешься.
> дело ближайших пяти лет максимум
Нынешнее поколение будет жить при коммунизме?
Ну вот его и делают. Для тех же Ruby, PHP и прочего тоже фреймворки кто-то писал.А так... надо просто понимать, что сложность задач растёт. И вот сейчас она уже стала такой, что "большие" языки подходят куда больше, чем скриптовые. Сейчас держит скорее инерция. Примерно как мелкая фирма может работать, не имея штатного расписания, формального распределения обязанностей и тому подобного. А когда в фирме тысяча человек - бюрократия не просто полезна, она жизненно важна. Ну вот есть такой момент роста, когда её приходится вводить - и обычно он сопровождается кучей обид и несогласий - только деваться по факту некуда.
> Twitter - руби, например, изначально был.
> Одноклассники - C#.
> Bootcamp - Ruby.
> Dropbox - Python.
> Ну-ка, ну-ка?Изначально, угу. А потом - все норовят на что-то сбежать - кто эрланг заводит, кто джаву со скалой, кто в раст начинает играться, кто вообще транслятор с php на плюсы пишет. С чего бы...
Дай угадаю, ты никто не писал на Qt.
> Пока ты будешь ашвабаждать память, появится павел дуров и быстренько напишет годный ( = денежный) стартапчик на пыхе. А ты в это время все еще будешь ашвабаждать память.я её с 2011 года освобождаю. Никак не освобожу...
Интересно, а в нем webview работает.
Можно написать браузер и запустить в браузере))
См. GTK+ Broadway.
Про KDE Neon кто-нить запостит новость или нет? Где админы?
http://jriddell.org/2016/11/14/upgrade-for-kde-neon-security.../
> Про KDE Neon кто-нить запостит новость или нет? Где админы?
> http://jriddell.org/2016/11/14/upgrade-for-kde-neon-security.../Всё в ваших руках. Создание новостей доступно даже для анонимов.
Это что получается, теперь можно писать сайты на C++ и через FastCGI подключать http-серверам?
Я правильно понимаю?
Можно через uWSGI (HTTP, FastCGI, uWSGI...) или вообще обойтись без http-сервера, использовав Internal HTTP. Сам исполняемый файл становится http-сервером.
Давно можно через wt.
Было:
Ща, допишу и залью
Становится:
Ща, допишу, скомпилю, залью
Смотрю, тут все как обычно. Срачи php vs. anything. Ребят, если вы не знаете ЗАЧЕМ используют C/C++ в вебе, а ПОЧЕМУ не используют, то идите попейте чайку.
Проект, конечно, интересный, однако, весьма странно, что поднялся тут ажиотаж, когда C/C++ веб-серверов, веб-библиотек, веб-недогенераторов было написано овердофига. А тут новость и вауля начали сраться как в нулевых =)
Потому что тут есть надежда на написание веб-приложений на чём-то вменяемом - то есть Qt.
Пишите на Clojure и будет вам счастье.
WAI / Warp - наше фсё!
