Comments 54
Если речь идёт о дешёвом VPS начального уровня, то PHP без вариантов. Ту же Node.js на 512Мб RAM ещё попробуй запусти (да даже на 1Гб не очень-то весело), и в любом случае это будет скорее мучение, чем работа.
У меня 5 лет живет проект на Node js на 512Mb RAM VPS. Жрет памяти 80Mb. В пике 100MB, когда много генерации xlsx отчетов.
Это миф, что Node жрет много памяти, если конечно не ставить бесконтрольно модули сомнительного качества.
Плюс в Node js можно включить ручное управление Garbage Collector, если вы ограничены в памяти и хотите более интенсивно чистить память.
Это миф, что Node жрет много памяти, если конечно не ставить бесконтрольно модули сомнительного качества.
Плюс в Node js можно включить ручное управление Garbage Collector, если вы ограничены в памяти и хотите более интенсивно чистить память.
UFO just landed and posted this here
А вообще serverless почти тоже без вариантов)
Автор не учитывает, что из рассмотренных языков лишь у джавы статическая типизация. Поэтому что-то большое в разы проще на ней писать. Компилятор кучу ошибок отловит ещё до запуска.
В node.js про ошибку же мы узнаем лишь после запуска, точнее как до соответствующего места кода дойдет исполнение. В худшем случае код исполнится без ошибок, но неправильно (например, передали функции меньше параметров чем нужно).
Поэтому статическая типизация в языке, который юзается в фреймворкк — то, на что я бы приоритетно обращал внимание. С ростом проекта хайповость и смузиевость технологии будет меркнуть на фоне его поддержки и развития.
ну как бы, у C# тоже статическая типизация, однако это не мешало постоянно ловить баги в рантайме. Нервы мои закончились, я не без скрипа перешел на PHP тогда еще 5.6 версии и счастлив. Сейчас в PHP такие же правильные типы, такое же правильное ООП как и в больших языках типа Java. Так что чувствуешь себя и уверенно и спокойно.
А самое главное, это не один большой процесс, который если упадет, то упадет все. И если что-то работает не будет, оно не будет работать в одном конкретном месте. Поймал ошибку, устранил. все остальное работает.
А самое главное, это не один большой процесс, который если упадет, то упадет все. И если что-то работает не будет, оно не будет работать в одном конкретном месте. Поймал ошибку, устранил. все остальное работает.
это не мешало постоянно ловить баги в рантайме.
Эксепшны)
Чтобы ловить исключения уровня: «Ой, у объекта нет такого свойства!» в рантайме — нужно сильно постараться.
А самое главное, это не один большой процесс, который если упадет, то упадет все.
А какой именно веб-движок?
Я не помню точно что там было в древности, но вроде везде все запросы обернуты в try/cach, так что единственное, что может упасть, это обработка запроса после чего движок покажет ошибку. Все праллельные юзеры и запросы ничего не заметят.
сначала чистый ASP.NET потом MVC. нет, это то да, сервер на IIS + ASP.NET не падал целиком, я тут просто не обозначил, что так может упасть тот же сервер на Python'е. А так да, ровно как Вы и сказали, все было обернуто, ловилось и постоянно вылезало. т.е. там где PHP просто проигнорирует какой нибудь отсутствующий параметр, ASP ругнется и покажет ошибку.
там где PHP просто проигнорирует какой нибудь отсутствующий параметр, ASP ругнется и покажет ошибку.
Просто прекрасно) Если эта ошибка приводит, скажем, к порче данных, то поиск причины рискует быть очень увлекательным.
нет, когда данные вводятся, все проверяется от и до, в других случаях было. не страшно, просто интерфейс портит и лезешь пытаешься воспроизвести проблему. Все упирается в строгую типизацию. С простыми ассоциативными массивами, такого не бывает.
просто интерфейс портит
Интерфейс портят ошибки в программе, а не инструмент, который их находит) Грамотную обработку ошибок с наличием исключений построить не сложно.
и лезешь пытаешься воспроизвести проблему.
И ведь сразу ясно, куда нужно лезть. Со слабой, да еще и динамической типизацией ошибка может дрейфовать в далекие дали и порождать спец.эффекты, вроде результата деления строк на цифры. Отладка будет печальна.
Для этого можно использовать TypeScript на Node.js.
К счастью, умные люди уже разработали (и используют) TypeScript для Nodejs, который, будучи динамически компилируемым в нативный JS, предотвращает большинство проблем, включая те, что вы описали.
Статически компилируемым же. В рантайме работает старый добрый JS.
TypeScript и рядом не компилируемый, если уж так. Он транспилируемый. В противном случае, мы бы на выходе получали не js файл, а объектный файл
Это авторская терминология.
Не Spring Boot, просто Srping. Boot — это всего лишь один из компонентов, облегчающий запуск приложения.
Так как Django основан на Python, о производительности этого фреймворка и о его поддержке можно не беспокоиться.
Имеется ввиду то, что можно не беспокоиться о производительности питона и быть уверенным, что Джанго на порядки медленнее самых быстрых фреймворков? Просто ведь так оно и есть:
www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=fortune
Какое-то непонятное сравнение…
Вроде бы Django это фреймвор на Python, и Express это фреймворк на node.js.
Но сравнивая вы берете репозиторий node.js и говорите что у него больше звезд, хотя если взять репозиторий express, что кажется логичнее, то звезд у него будет примерно столько же.
Вроде бы Django это фреймвор на Python, и Express это фреймворк на node.js.
Но сравнивая вы берете репозиторий node.js и говорите что у него больше звезд, хотя если взять репозиторий express, что кажется логичнее, то звезд у него будет примерно столько же.
Какие-то выстраданные преимущества у Django. После каждого хочется спросить: это точно особенности, которыми он выгодно отличается от двух остальных?
Благодаря тому, что в Node.js имеется система ввода-вывода, не блокирующая главный поток, эта платформа демонстрирует высокую производительность. Достойная скорость обработки запросов достигается благодаря использованию JavaScript-механизмов конкурентного однопоточного выполнения кода.
Любопытно, как главный недостаток ноды/языка — однопоточность, сделали приемуществом.
И список команий, использующих spring, явно коротковат. Тотже Netflix учавствует в разработке Spring Boot (Spring Cloud Netflix) и заявили, что теперь это их «главный» java фреймфорк. netflixtechblog.com/netflix-oss-and-spring-boot-coming-full-circle-4855947713a0
Еще одна рекламная статья ноды…
- В Node js приложение давным-давно можно запускать в кластере для утилизации всех ядер.
- 1.5 года назад в Node js появились Worker threads для реализации многопоточности
- Большинство веб приложений занимаются большим кол-во I/O, а не числодробилки. Вот поэтому многопоточность несколько лет спустя завезли
express пример прекрасной дохлой архитектурной лошади. Не используйте его. Его студаки залайкали 10 лет назад, когда больше не было вообще ничего. Есть прекрасные переосмысленные альтернативы.
Какие?
А то получается как в песне группы "Манго-Манго": "У нас есть ТАКИЕ приборы! Но мы вам о них не расскажем."
Adonisjs например
Спасибо за ответ, коллега. Мне почему-то кажется, что коллега Alexufo имел что-то другое в виду, говоря о "дохлой архитектурной лошади".
Насколько я вижу, Adonisjs — это MVC-фреймворк (как они сами себя позиционируют), заточенный для разработки web-приложений с MVC-архитектурой (некоторые находят сходство с PHP-фреймворком Laravel). В то время, как expressjs — это практически чистый web-сервер (типа apache или nginx).
В архитектурном плане я ожидал сравнения express с чем-то вроде fastify, koa, restify и им подобным. Мне жутко интересно, почему архитектура express "дохлая" и что может являться примером "живой" архитектуры.
Зайдите в комментарии к MarcusAurelius прямо вот последние как раз об этом, я, конечно, не могу с должным гонором стучать себе в грудь, заявляя — что в fastify все архитектурно академически корректно, но он сделан явно на переосмыслении накопившихся недоразумений.
Мне изначально не понравилась идея тащить кальку с лары на js. Как-то это не кошерно. Как будто-то бы мексиканец приезжает в Россию и давай рассказывать, что бурито лучше шаурмы. Кошерно, когда язык рождает свои архитектурные подходы.
А я специально умолчал. )) Да, я имел ввиду fastify и koa. Можно посмотреть лекцию мейнтейнера fastify и причины, которые побудили его переписать express. Он сильно на него похож и популярные плагины express форкнуты и адаптированы к fastify.
Не используйте его.
Скажите, пожалуйста, об этом разработчикам Nest.js. А то они, похоже, не в курсе )))
Они вкурсе и тут пишут подробнее docs.nestjs.com/techniques/performance
К экспрессу нет жесткой привязки. Я так понимаю, они еще не готовы базироваться на fastify, потому перекладывают на пользователя — если оно ему нужно. А оно может ему действительно и не нужно. Но призывы отказа от изучения отдельного express звучат не первый год. Express уже обречен и живет только из-за легаси и кучи информации для студентов. Если есть вещи эволюционно следующие, express, собственно для чего изучать и использовать — не понятно.
MarcusAurelius пилит свой фреймворк и это должно быть бомбой, по моим расчетам. То есть, есть все шансы ему быть использованным по всему шарику, если они покроют кейсы как для корпоратива так и для одиночек фриланеров. Отличный опыт, отличные теоретические знания и жесткое понимание текущих проблем.
Fastify provides a good alternative framework for Nest because it solves design issues in a similar manner to Express.
К экспрессу нет жесткой привязки. Я так понимаю, они еще не готовы базироваться на fastify, потому перекладывают на пользователя — если оно ему нужно. А оно может ему действительно и не нужно. Но призывы отказа от изучения отдельного express звучат не первый год. Express уже обречен и живет только из-за легаси и кучи информации для студентов. Если есть вещи эволюционно следующие, express, собственно для чего изучать и использовать — не понятно.
MarcusAurelius пилит свой фреймворк и это должно быть бомбой, по моим расчетам. То есть, есть все шансы ему быть использованным по всему шарику, если они покроют кейсы как для корпоратива так и для одиночек фриланеров. Отличный опыт, отличные теоретические знания и жесткое понимание текущих проблем.
Ок, убедили, завязываю пока с писать на ноде. Подожду когда MarcusAurelius зарелизит свой бомбический фреймворк )))
А если серьезно, к экспрессу у неста нет жесткой привязки, но когда читаешь документацию, то тут, то там натыкаешься, что вот то или вот это не работает, если используется фастифай.
Я разрабатывал на фастифай, но если честно не понял чем он лучше в плане разработки, чем экспресс. Нест вот другое дело, после него возвращаться на экспрес, фастифай и тд не хочется, хотя по сути, это пример того, как можно прокачать любой js-ный сервер до хорошей архитектуры. Нест устроен так, что он подталкивает разработчика выстраивать правильную архитектуру в проекте. В отличии от…
А если серьезно, к экспрессу у неста нет жесткой привязки, но когда читаешь документацию, то тут, то там натыкаешься, что вот то или вот это не работает, если используется фастифай.
Я разрабатывал на фастифай, но если честно не понял чем он лучше в плане разработки, чем экспресс. Нест вот другое дело, после него возвращаться на экспрес, фастифай и тд не хочется, хотя по сути, это пример того, как можно прокачать любой js-ный сервер до хорошей архитектуры. Нест устроен так, что он подталкивает разработчика выстраивать правильную архитектуру в проекте. В отличии от…
В nest хорошо все, кроме orm
Ну это не ваши проблемы, что nest на express и fastify у них плохо интегрирован. И не вина nest, что они его выбрали — не из чего было выбирать-то тогда. Fastify недавно 2-ую версию выдал с поломкой совместимости. По мне он только как год стал хорошо на ноги для комьюнити, а так макаронники еще висели в полуготовом состоянии — будут ли хорошо мейнтейтить или нет. Маловато было комьюнити, я поймал багу после обновления плагина, что мейнтейнер извинялся за глупость. Чтобы Я и БАГУ. Сразу чувствуешь себя идиотом, который выбрал якобы протоптанную дорожку, а по морде хлещат ветки. В экспрессе очевидно до меня нашелся бы первооткрыватель.
И пишите то вы все равно не на express-е используя nest. Меня он как-то пугает своей монструозностью и кучей этих всех инжекшинов фабрик каких-то интерцепторов — это когда с шарпа какого нибудь переходишь, там все эти паттерны родные. Но если говорите, что оно наоборот, легче… это интересно.
Я писал о том, что рассматривать самостоятельно Express как рассмартивают в статье нельзя, ну какой Express в 2020 году. Закопать его пора.
И пишите то вы все равно не на express-е используя nest. Меня он как-то пугает своей монструозностью и кучей этих всех инжекшинов фабрик каких-то интерцепторов — это когда с шарпа какого нибудь переходишь, там все эти паттерны родные. Но если говорите, что оно наоборот, легче… это интересно.
Я писал о том, что рассматривать самостоятельно Express как рассмартивают в статье нельзя, ну какой Express в 2020 году. Закопать его пора.
И пишите то вы все равно не на express-е используя nest. Меня он как-то пугает своей монструозностью и кучей этих всех инжекшинов фабрик каких-то интерцепторов — это когда с шарпа какого нибудь переходишь, там все эти паттерны родные. Но если говорите, что оно наоборот, легче… это интересно.
Угадали, я с .net перешел )))
Меня он как-то пугает своей монструозностью и кучей этих всех инжекшинов фабрик каких-то интерцепторов — это когда с шарпа какого нибудь переходишь, там все эти паттерны родные. Но если говорите, что оно наоборот, легче… это интересно.
а как вообще можно писать крупное приложение без di?
В том то и проблема js-ников, они не не хотят/не могут разобраться с простейшим паттерном и придумывают любые отговорки, лишь бы не использовать проверенные временем решения
Честно говоря, я — не фанат Java. И я не будут использовать Spring Boot для серверной разработки в 2021 году.
Только потому что вам не нравится Java вы отправили Spring на последнее место?
Вообще Spring можно использовать с Kotlin или Groovy.
Когда я вижу название «Выбираем лучший бэкенд-фреймворк», я предполагаю, что будет рассмотрено большое количество фреймворков, сколько-нибудь представленных в разработке.
О Flask'е для питона даже не упомянуто, для ноды тоже есть альтернативы помимо Express'а. Ещё есть .Net с его ASP MVC.
В общем, этой статье больше подошло бы название «Сравним Express, Django и Spring Boot».
О Flask'е для питона даже не упомянуто, для ноды тоже есть альтернативы помимо Express'а. Ещё есть .Net с его ASP MVC.
В общем, этой статье больше подошло бы название «Сравним Express, Django и Spring Boot».
Примерно такие же ощущения от статьи… Да и даже к такому подходу есть претензии — как показывает автор на SO топ-3 составляют Express, Spring и ASP.NET, но видимо автор отдаёт больше предпочтение Python, чем C#, и как писали выше, Java тоже автору не нравиться, но это не делает же фреймворки хуже по сравнению с другими рассматриваемыми
оригинал статьи удален))
видать ему так же намекнули, а он агрессивно настаивал на своей правоте)
This account is under investigation or was found in violation of the Medium Rules.
видать ему так же намекнули, а он агрессивно настаивал на своей правоте)
ru_vds ваш род деятельности предполагает доступ к как минимум каким-никаким программистам. Вы можете проводить мини тесты на качество статей. Зачем вам в сети присутствие рядом со словами вроде шлак, мусорная статья?
Да начнется холивар! 
если кому-нибуть интересно есть фрейворк для clojurescript (компилится в js)
называется Macchiato (пилит наш соотечественник кстати)
… эх… мечтаю чтобы c JavaScript и Node.js «что-то произошло», чтобы они стали «Most Loved» и «Most Wanted»…
Переключился (еще в процессе) на JS из мира PHP MVC фреймворков, так как тяжело эти два языка у меня в голове одновременно уживались.
Сильно привык к PHP, аж закостенело всё. Пока JS «заходит» тяжело. JS — не просто «немного другой» синтаксис. Он сильно другой все-таки.
Для начала выбрал nextjs (под капотом там react), есть аналог nuxtjs (по капотом vue).
Пока у меня много времени уходит на поиски информации «как правильно делать». И такое буквально на всех этапах. TypeScript — симпотечен, npm — пугает).
Кстати gitHub (Майкрософт) в этом году купил NPM.
Переключился (еще в процессе) на JS из мира PHP MVC фреймворков, так как тяжело эти два языка у меня в голове одновременно уживались.
Сильно привык к PHP, аж закостенело всё. Пока JS «заходит» тяжело. JS — не просто «немного другой» синтаксис. Он сильно другой все-таки.
Для начала выбрал nextjs (под капотом там react), есть аналог nuxtjs (по капотом vue).
Пока у меня много времени уходит на поиски информации «как правильно делать». И такое буквально на всех этапах. TypeScript — симпотечен, npm — пугает).
Кстати gitHub (Майкрософт) в этом году купил NPM.
Интересно почему cherrypy такой не популярный, если про django занют все, про bottle, flask есть упоминания, то про cherrypy вообще не слышно.
А мне кажется странным строить какие-то выводы по популярности фрейморков.
На Go, например, писать бекенд можно и без фреймворка (так часто и делают по началу, потом создают 100501 фрейморк — самый правильный и лучший ;) ).
На Go, например, писать бекенд можно и без фреймворка (так часто и делают по началу, потом создают 100501 фрейморк — самый правильный и лучший ;) ).
Sign up to leave a comment.
Выбираем лучший бэкенд-фреймворк 2021 года