А есть ли смысл использовать C++ для web ?

Есть. CppCMS.

васян CMS ?

Тебе везде васяны мерещатся?

Васян, ты?

Эдик ЕМНИП вообще на сях писал что-то в вебе. Но он и кои8 пользует до сих пор...

Нет, я Григорий.

Нормально, Григорий!

Ну, попробуй.

Я смотрю по вакансиям - с С++ переписывают постепенно

А что именно переписывают? Разве на C++ в Web-е было так уж много написано, что теперь на Python и Go переписывают и это так заметно?

да все что угодно - обычно «какая-то хрень которая быстро работала, поэтому ее написали на с++»

можешь еще попробовать cutelyst. Архитектура фреймворка напоминает перловский Catalyst

Есть. CppCMS.

Лол :-) И компилировать шаблоны HTML компилятором цепепе в память :-) Надо же ведь какая клёвая идея посетила некогда Артёма :-) Это же так удобно и так продуктивно :-) Лол :-)

Зачем люди пытаются пропихнуть языки (C++ и Rust) в веб, хотя они для этого не предназначены? А по сабжу скажу - всякие го и питоны поддерживать, потому что намного проще крестов

Ну т.е. конкретных примеров у вас нет?

проще поддерживать*

Быстро, удобно, продуктивно. Всё так.

Не, С проще же!

Дык, работает, требует минимума усилий — что еще надо? Не пхытон же или пыхпых!

Зачем люди пытаются пропихнуть языки (C++ и Rust) в веб, хотя они для этого не предназначены?

Есть, как минимум, две очевидные ниши, в которых применение C/C++/Rust для Web-а оправданы:

1. Реально высокие нагрузки у монстров типа Google, Facebook, Yandex и пр.

2. Web-интерфейсы для «умных устройств», у которых мощностей и ресурсов для каких-нибудь RoR-ов или Django просто не хватает.

Хотя вот тех же Интернетиках всплывают темы о том, как подружить Node.js и C++. Мол, на Node.js и JS пишут принималку запросов, после чего запросы делегируют в плюсовую часть для каких-то тяжелых вычислений, после чего опять же на JS генерируют ответ.

Ну а в свете REST-ификации приложений термин «Web-приложение» стал вообще несколько своеобразным. Например, если делается REST-интерфейс к какой-то древней легаси-системе, то это уже Web или еще (уже) нет?

Смысл использовать цепепе в web заключается в экономии серверных ресурсов :-) Понимаешь, много тех, кто грезит, что его стартап непременно подвергнется высоким нагрузкам :-) И вот они в этих грёзах начинают сочинять асинхронные сервера (подразумевая под «асинхронностью» неблокируемый ввод/вывод, но они так понимают асинхронность, лол), использовать везде и всюду всякие зеро-копи стратегии, начинают бредить схемами N-процессов * M-потоков + трэд под I/O т.д. и т.п. :-) Т.е. к UI после реализации своего мега-супер сервера «под тяжёлые нагрузки» приступают спустя несколько лет, когда конкуренты уже давно пробуют на уважаемой публике аналогичную идею, аля стартап от конкурентов, сделанный на каком-нибудь PHP :-) И тогда на сервер под управлением цепепе заходят 10-20 посетителей в день, но работает быстро :-) Лол :-)

на сях писал что-то в вебе

на сях

Пф.. https://fortran.io

Нет.

1. На плюсах и си коряво описываются domain models.

2. В вебе нет необходимости в доступе к низкоуровневым данным.

3. При обработке большинства запросов, сборщики мусора и «зеленые потоки» быстрее и эффективнее используют ресурсы управляемые рантаймом, чем напрямую, что делает написание бекендов мало вертикально-масштабируемыми, особенно учитывая тот факт, что у сборщиков мусора есть управляемые стратегии, тогда как у ручного управления их нет.

4. На си и цпп нет мвц фрейимворков как и нет нормальных шаблонизаторов.

5. Предыдущий аргумент можно опустить при условии, что пишешь рест, но дрючиться с SEGMENATION FAULT при AddBlogPostModel никому не хочется.

6. Большинство веб-приложений масштабируются горизонтально, потому от увеличения скорости дробления жсона и уменьшения врепени на парсинг хттп запроса, приложение по факту, быстрее не станет. 7. Узкиим местом все равно станет база данных, какой бы она не была.

8. Современные веб-фреймворки используют все прелести динамического рантайма в парсинге и генерации sql запросов, так и прочей хрени, которая на цыпыпэ делается просто нетривиально.

Лол :-) И компилировать шаблоны HTML компилятором цепепе в память :-) Надо же ведь какая клёвая идея посетила некогда Артёма :-) Это же так удобно и так продуктивно :-) Лол :-)

Ты брат Сашки Зачало чтоли? Такой же смайлонутый на голову

6. Большинство веб-приложений масштабируются горизонтально, потому от увеличения скорости дробления жсона и уменьшения врепени на парсинг хттп запроса, приложение по факту, быстрее не станет. 7. Узкиим местом все равно станет база данных, какой бы она не была.

Позвольте просто оставить это здесь: https://engineering.instagram.com/c-futures-at-instagram-9628ff634f49

Ну а уж примеры того, как этот ваш вебчик, в котором, якобы, тормозит только БД, лихо переписывают с динамически-типизированных языков с VM (читай, с тормознутых) на статически-типизированный и нативный Go, вы и сами сможете найти в товарных количествах.

Есть ошущение, что с мантрой «Узкиим местом все равно станет база данных» вы опоздали лет на 10, если не на 15 ;)

в мегакрупной копрорации возможней.

Это на самом деле не вполне себе CMS, а

What is CppCMS? CppCMS is a Free High Performance Web Development Framework (not a CMS)

Дальше иди по ссылке и читай сам.

Я это видел и использовал в продакшне, весьма годная штука. А васяны как раз на джангах пишут.

Это на самом деле не вполне себе CMS, а

Лол :-) Идея назвать нечто как xyzFOO, чтобы потом комментировать в скобках, что xyzFOO - это не FOO выглядит таким же маразмом, как и компилировать шаблоны HTML с помощью цепепе-компилятора :-) Лол :-)

Есть ошущение, что с мантрой «Узкиим местом все равно станет база данных» вы опоздали лет на 10, если не на 15 ;)

Есть ощущение, что те, кто последние 10-15 лет днями и ночами изучал цепепе, теперь наконец могут на нём программировать и дозрели до WEBа :-) И уж теперь то они покажут всем технологический класс и прорыв, а так же как надо программировать веб :-) Лол :-)

кмк, смысла использовать никакого.

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

вчера какраз наблюдал openmonero, основан на этом https://github.com/Corvusoft/restbed/ на первый взгляд ничетак.

Есть. API в редких случаях. Очень редких.

Да что ж вы узколобые такие?! Рест сдох уже давно! Не нужны эти асинхронные запросы, когда есть вебсокеты!11111

Зачем люди пытаются пропихнуть языки (C++ и Rust) в веб, хотя они для этого не предназначены?

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

если ты эльф и тебе нечем заняться в ближайшие 10000 лет - то однозначно есть смысл.

Да, через WASM.

Зачем люди пытаются пропихнуть языки (C++ и Rust) в веб, хотя они для этого не предназначены?

Ну вебельщики вон везде пихают свой electron и ниче, почему бы плюсерам тоже не пострадать хе*ней? Есть мнение, что все банально - людям просто лень изучать что-то новое и хочется использовать знакомые вещи.

Нормально, Григорий!

Отлично, Константин!

Я пробовал было начинать:
- находил уйму фреймворков, какой их них лучше/хуже - непонятно.
- слишком много лишних телодвижений. То, что на PHP делается легко, в C++ требует что-то воротить. Примеры: сравнить hello world программы, работа с GET/POST параметрами, заголовками и т. п.
- не на каждом хостинге разместишь. А если хостинг и разрешает - не факт что там есть консоль, нужно компилить локально (еще угадать архитектуру).
- кто потом это будет поддерживать?

Вердикт: только если есть веские причины (например, performance), и не всё, а только «узкие» места.

https://www.webtoolkit.eu/

Если времени девать некуда, то пожалуйста.

Время самый ценный ресурс если что, от это и отталкивайся при выборе инструмента.

Что там сложного?

Примеров вебсокет-серверов под C/C++ в интернете завались! Обычно же от демона не требуется еще и веб-странички выдавать — он тупо ждет, пока клиент загрузит html (а для этого есть NGINX или apache), а дальше включится соединение с вебсокетом по нужному порту.

Обработка json или параметр=значение в C — элементарная штука, уже давно разжеванная. Точно так же и общение с базами данных.

Ну и откуда здесь возьмется лишняя трата времени?

Это раньше, в бородатые времена, когда не было вебсокетов и local storage, народ занимался дебилизмом: куки, POST/GET и т.п. А теперь все намного проще. Хотя, и в то время ничего сложного не было в том, чтобы на С написать сетевое приложение. Я даже библиотечку начал было варганить для облегчения работы с куками, запросами и БД (мне БД нужна была лишь для одного — хранить логины и хэши паролей).

Нет. Его вообще нигде нет смысла использовать. Кроме лютого легаси, где вариантов нема.

alenacpp работала в Bing Ads, и писала, что характерно, на C++. Может и сейчас пишет.

Я подобное только в виде cgi видел. cgit для просмотра репов.

можешь еще попробовать cutelyst

build: failing

Эдик, а покажи свою самую сложную приложуху для веба.

Нет. Этому сегфолтящемуся убожеству с перекладыванием байтиков не место в вебе.

Как минимум возможность запихнуть бинарник есть далеко не везде. Хостинги же все поголовно поддерживают тот же пых.

Вот (github.com) (из-за webgl, а со стороны сервера тупо скрипты на баше).

Еще: из последнего (с вебсокетами), картинка в SVG, а эти два и по сей день успешно крутятся: визуализатор метео-БД и информационные панели (у панелей доступ как к сишным CGI, гнуплотом рисующим графики, так и к CGI на баше; вот картинка одной из панелей).

Если соберусь очередную веб-морду делать, перейду полностью на вебсокеты, чтобы с этими дурацкими POST/GET не париться!

Кстати, полный переход на вебсокеты убьет сразу двух зайцев: можно будет как веб-мордой пользоваться, так и клиентской утилитой на чем угодно (хоть на пхытоне) — кому не нравится веб-морда, пусть рисует... А вообще, у меня пока не было острой необходимости в интерактивщине, чтобы изображения мышкой щелкать и менять параметры. Все управление на гольном CLI намного лучше работает!

И что из этого по ссылке опровергает мои слова? У них тормозил запрос данных, т.к. они фильтровались через рекомендательную систему. Ну написали они числодробилку на цпп, тогда как на картиночке все равно джанга в центре. Я бы все-таки исправился и сказал, что узким местом всегда становится агрегация данных, но это все равно справедливо, т.к. в 99% случаев этим занимается база данных. Статически типизированным го вообще назвать язык не поворачивается - https://play.golang.org/p/nIGfU_QAKY, строгим, может быть, да, но явно не статически.