Comments 31
Всех победили php и js!)
Забавно... Шаблонизатор в современном вебе... Лет 5 уже не сталкивался.
А что используете? конкатенацию строк руками?
SPA и API
Т.е. вы голый JSON пользователю выводите, или всё-таки чем-то формируете html?
Да, фронтэнд фрейворк формирует HTML, бекенд занимается только данными. Для поисковиков делается server-side rendering.
Извините за сарказм, но фронтенд фреймворк с помощью силы лунной призмы формирует HTML? А SSR делается через sed и awk?
Фронтенд Фреймворк формирует себя из кучи js и html при помощи лунной призмы, какой-то матери и вебпака. И лежит это все в виде кучи статики в каком-то веб-сервере.
Он же получает голые жсоны и засовывает их себе в стейт.
Фронтенд фреймворк в режиме SSR, конечно же, можно обозвать шаблонизатором, однако это не основной его режим работы. Принципиальное отличие современных фреймворков от старых шаблонизаторов — в том, что по возможности работа с HTML пропускается, основная работа идёт с DOM (который, может быть серилизован в HTML в SSR режиме, однако данный шаг опционален).
Всё равно это шаблонизатор. Интегрированный с языком и фреймворком - но это уже особенности. Тот же Pug/Jade - тоже не html со скобочками, а при этом самый настоящий шаблонизатор.
Самая соль в непереведённой концовке статьи (Update after Twitter storm (15/11/2022)) рекомендую пройти туда и прочитать по ссылкам
Постараюсь доперевести в свободное время :)
Вообще-то, самая соль там в топовых комментариях (перевод которых стоило бы добавить в начало статьи), где автору справедливо указывают на то, что это не очень ок - предъявлять претензии MS за участия неполноценных фреймворков в бенчах, и тут же сравнивать полноценный фреймворк (full mvc) который занял "лишь 109 строчку", с никем не используемыми реализациями на других языках, о которых никто не знает, которыми никто не пользуется, и которые делались исключительно для бенчмарков.
Хочешь сравнить с php - бери laravel, Yii (374 строчка), а не mixphp. Хочешь сравнивать c Java - тогда где Spring? А, на 351ой..
справедливости ради, jooby - один из неплохих не-спринг фреймворков на java, который вполне себе используется. емнип, несколько лет назад он был на очень скромных позициях с вялым перфомансом, теперь вот хорошо перформит.
не одним спрингом жив жава дев, слышал об использовании разных дропвизардов и жуби на продакшене
емнип, несколько лет назад он был на очень скромных позициях с вялым перфомансом, теперь вот хорошо перформит.
Так а знаете что изменилось? :) в версии 2+ из Jooby вырезали DI - без которого мы слабо представляем себе серьёзный бэк-енд, но который мягко говоря не бесплатный в плане производительности. Из-за таких моментов и некорректно сравнение с Asp, который разве что кофе не варит. (Это, разумеется, не делает Jooby плохим; речь исключительно о том, что автор статьи сделал ровно то, в чём обвиняет MS)
Не столь важна шустрость языка, сколь грамотность разработчика.
Шаловливые ручки и на ASM умудряются создать шедевры тормозов. Встречал. Улыбнуло от воспоминаний.
А грамотные разрабы и на VB пишут красивый и шустрый код.
Было бы интересно сравнить с Spring Webflux. К сожалению в 21 раунде почти его не тестировали , а там где тестировали то я не очень верю результатам, потому что в одном из тестов, Multiple queries, занял 25 место. Пока что ленивые джавовцы медленно переходят на webflux, в связи с этим думаю и низкий интерес к тестированию
Мне довелось только видеть Spring с Tomcat, а если БД, пусть даже и с одной таблицей, то Hibernate must have. Даже новые сервисы, как будто по туториалам 10 летней давности. И таких много.
Иногда проще не оптимизировать, а переписать на NET Core, хотя, возможно это потому, что с последним мне проще
Несмотря на любовь к .NET, изначально не мог поверить, что им удалось обогнать C++...
А почему нет? Jit может очень агрессивно оптимизировать, а с nTier ещё и с использованием эвристик. Аллокация памяти тоже быстрее, чем в С++, а если memory traffic per request маленький и во 2е поколение мало что попадает, то даже накладные расходы на GC могут быть не ужас-ужас. В общем допускаю, что можно подобрать сценарий, когда будет быстрее.
с переходом с net 6 до net 7 что-то улучшилось?
Помимо скорости, важно и удобство разработки.
Не знаю, насколько удобно разрабатывать веб в С++, но Раст обеспечивает сравнимое с асп.нет удобство (все же, несколько ниже - так как нету LINQ, но все же есть sqlx, который делает работу с базой не совсем ужасной, но ).
Вообще, имхо, Раст - сильно опережает другие варианты по сочетанию "скорость работы + скорость разработки"
Если говорить серьёзно, то скорость разработки на Rust может быть высокой только для хорошо подготовленного Rust разработчика, у которого несколько лет разработки на Rust за плечами. Потому, надеюсь, что высказывание про "скорость работы + скорость разработки" всё-таки в некоторой степени ирония :-)
Никакой иронии, но сужу по личному опыту.
Если сравнивать мой опыт Rust c другими популярными стеками:
- асп.нет - скорость разработки на нем выше, удобно за счет LINQ
- node.js + typescript - на Раст я пишу быстрее, система типов в Раст обеспечивает сравнимое удобство, работать с SQL базой намного удобнее с sqlx, но все таки это наиболее близкий по скорости и девелопмент экспириенсу стек
- node.js + javascript - не понимаю, как люди на этом пишут, на Rust намного быстрее (если не брать за скорость разработки то, насколько быстро можно с нуля выкатить первый эндпоинт).
В целом, если брать суммарную скорость разработки за несколько месяцев (которая включает в себя как добавление новых фич, так и правки в существующие), то связка Actix Web + SqlX проигрывает разве что asp.net. При этом Rust за счет макросов имеет огромный потенциал в сокращении бойлерплейта.
Но это, повторюсь, мой личный опыт.
Ну, у меня наверное не такой богатый опыт разработки на Rust, чтобы я мог с уверенностью сказать, что скорость разработки на Rust для меня, по крайней мере, приемлема со сокростью разработки на .NET Core.
Да, по скорости работы самих решений, тут, конечно, зависит и от решаемых задач и от применённых подходов к программированию, НО, в целом, могу, например сказать, что скорость обработки сообщений из очереди RabbitMQ при реализации на Rust в разы превышает скорость .NET Core при сравнимых подходах и реализациях (без использования LINQ). А уж про размер исполняемого кода я и подавно молчу - Rust однозначно выигрывает.
НО, в целом, могу, например сказать, что скорость обработки сообщений из очереди RabbitMQ при реализации на Rust в разы превышает скорость .NET Core при сравнимых подходах и реализациях
Я, помню, был пару дней под впечатлением, когда в VS Code Rest Client (аналог Postman) увидел микросекунды вместо миллисекунд, как обычно в дотнете или ноде.
Что? .NET обогнали C++? Никогда бы не поверил. Статья реально интересная получилась
Небольшой вопрос. Вы json выводите или html?
Насколько быстр ASP.NET Core?