Почему на node.js до сих пор нету фреймворка уровня symfony или zend?

Question

[sugadu]

Уже не мало врмени прошло с момента выхода ноды. Она уже подбирается к седьмой версии ( почти вровень с php идет:) ). Но почему до сих пор есть только микрофреймворки типа express или koa, где каждый творит что ему вздумается, а про более крупные, более академичные, фреймворки даже разговоров не ведется?

Comments

[sim3x]

Точно нет?

[ChickenGrinder]

Потому что в таком фреймворке нет необходимости. Node-стиль это маленькие модули которые выполняют конкретную задачу. Посмотрите сколько модулей можно найти для экспресс. Если будет фреймворк комбайн все в одном, то это чревато целым рядом проблем.

Answer 1

[Александр Аксентьев]

Писать логику на node.js как на php без опыта лучше вообще не стоит.
Я еще почти не встречал/сам не писал софта на nodejs который бы НЕ падал после того как выжрет всю память.
Даже на простейших 50-100-200 строк скриптах появляются утечки памяти.
Ладно у меня падают, я в nodejs разрабов не записывался, а вот те кто пишет и выкладывает в паблик, даже там постоянные утечки и падения.

При всех плюсах в виду скорости и асинхронности(из-за которых в общем-то и появляются мемори лики), постоянные мемори лики и краши от нехватки памяти, лично меня вообще отпугивают.
Я бы не стал делать серьезную логику на nodejs, от части конечно потому что нет большого опыта.

Тут как раз побеждает пхп, отработал - умер. Чтобы забить память надо очень постараться(попроовать выбрать всю базу/таблицу например в одну переменную :D).
Поэтому php невозможно убить практически, в отличии от ноды.

В итоге, при всех плюсах и минусах обоих языков, я бы выбрал php для очередного сервиса.

Comments

[xfg]

отработал - умер.

Что будете делать, когда вам понадобятся долгоживущие соединения? Например websocket? Тогда вам в любом случае придется писать демон, хоть на php, хоть на node.js или еще на чем. И в таком случае на php можно будет точно также наплодить утечек памяти, как и на ноде. Никакой разницы.

[Александр Аксентьев]

xfg: когда нужен вебсокет я использую nodejs, практически весь мой опыт с nodejs это вебсокет.
Поэтому и пишу что куча утечек, даже в простом сервере, который почти ничего не делает.

На php вебсокет-сервер я попытался как-то сделать с помощью ratchet, он вообще не тянул больше 50 соединений почему-то(после 50 коннектов переставал отвечать на любые запросы), в то время когда nodejs держал сотни, но кушал память.

Не знаю опыт ли тут нужен или что, чтобы не было утечек. В общем поднимать серьезную логику я например просто не в состоянии на ноде, да и мне кажется нода не для серьезной логики вообще.
Может кто-нибудь напишет обратное, у кого опыт имеется, а моё имхо такое :)

[napa3um]

Богу - богово, кесарю - кесарево. PHP-адепту - PHP, Node-адепту - Node. "Отчасти конечно потому что нет большого опыта" - только потому.

[keltanas]

У нас и веб-сокеты на nodejs, и консьюмеры для rabbit на nodejs и php, и все отлично, ничего не течет, все работает. Но, если это вы делали LPTracker, то все понятно.

[Александр Аксентьев]

keltanas:
>веб-сокеты на nodejs,
>консьюмеры для rabbit на nodejs и php
в таких кейсах вообще проблем нет, читайте внимательнее.

>Но, если это вы делали LPTracker, то все понятно.
да, делал один. Сколько у вас таких проектов за плечами? Делитесь опытом.

[keltanas]

Александр Аксентьев: есть пара-тройка. Но, у меня NDA, так что делиться не буду. А то, что писал один - это не плюс, а минус. Знал бы раньше, кто автор, слал бы баги напрямую, а то много стульев пригорело в свое время. Но, теперь уже неактуально.

Answer 2

[Denis Smetannikov]

Потому что в ноде до сих пор нет хоть каких-то общепринятых стандартов как PSR в PHP (или даже PEAR). И этого не будет при текущем бурном развитии самого языка. В PHP хоть и меняется синтаксис между версиями, но не так значительно, чтобы прибегать к таким монстрам как babel.

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

Когда появятся стандарты то им будут следовать все фундаментальные инструменты, например как composer+PSR4 (autoload).

Как можно выработать общие железобетонные принципы и написать что-то большое, когда буквально раз в год все становится с ног на голову и выходит очередной ES-стандарт, а популярные библиотеки могут легко сломать обратную совместимость? =) Уж не говоря про чехарду технологий.

Думаю обязательно появятся, как только там наверху авторы "угомонятся" и разработчики смогут спокойно кодить, а не подгонять полдня версии пакетов.

Answer 3

[Василий Шахунов]

Дык sailsjs есть. Всё равно все из рельс всё будут тащить.
Да и пхп 20 лет уже развивается, а нода за 2015 год прошла от версии 0.11 до 4.2 За таким быстрым развитием платформы фреймфорки не успевают писать))

Comments

[Назар Мокринский]

Не путайте изменение версий с фактическим изменением платформы. К тому же не все следуют семантическому версионированию, так что версии могут значить всё что угодно.

Answer 4

[Виталий]

Я тут нашел фреймворк революционно новый, очень модульный и асинхронный. Так что фв на пхп курите в сторонке. Koa.js (автор проекта тот же что и у express)

Comments

[Виталий]

Артём Петренков: а он полноценный, просто в виде модульных подключений. Нужно роутер + модуль роутер и так далее. Прелесть в минимализме базы и асинхронности.

[Виталий]

Артём Петренков: да не вопрос, давайте останемся каждый при своем мнении.

Answer 5

[Александр Александрович]

Не могу ответить на Ваш вопрос, но мне кажется, что такие появляются например adonisjs.com

Answer 6

[Дмитрий Гурьев]

Если нужен большой монолитный фреймворк — можно посмотреть на Meteor. А вообще в мире JS/Node.js всё стремительно меняется, потому, как и писали другие выше, монолитному фреймворку здесь трудно выжить (отчасти потому React потеснил Angular). Более гибкий подход — собрать то, что нужно в конкретном проекте из независимых npm-модулей.

Answer 7

[inkrot]

Привет из 2020, всем кто задался подобным вопросом взгляните на NestJS, тот же symfony serializer здесь class-transformer, а вместо Doctrine есть TypeORM. В самом NestJS отличное dependency injection, TypeScript со статической типизацией, а производительность выше чем у Spring (тык).

Answer 8

[Павел Малышев]

Почему нет? Может потому что большие, монолитные фреймверки - это моветон?