Блог / JavaScript + Ajax / Что Node.js предоставил, что Rails не сделал?

Что Node.js предоставил, что Rails не сделал?

Когда в конце 2012 года я получил высшее образование в области компьютерных наук, Ruby on Rails достиг пиковой популярности среди начинающей аудитории., Казалось, что каждый горячий стартап использовал его. Так как я был (и до сих пор) большим поклонником стартапов, я обращался к различным стартапам, и моей первой работой после окончания колледжа стала работа в компании из девяти человек в качестве программиста на Rails. Я с головой погрузился в Rails и узнал, как быстро создавать веб-приложения. Для меня привлекательность Rails была и остается простой: доверьтесь стандартам по умолчанию, которые фреймворк устанавливает для вас, и вы сможете быстро создавать веб-приложения. мой опыт, Rails в значительной степени выполняет это обещание, Настройки по умолчанию разумны, Есть не так много gotchas.Plus, с такими хостинг-провайдерами, как Heroku, вы можете развернуть свое приложение, чтобы его можно было увидеть всего за несколько минут.

Переключение на Node.js

Через четыре года после окончания обучения (ближе к концу 2016), Rails все еще был популярен, но Node.js стал популярной новой модой для программистов, как показывает график вопросов переполнения стека:

Я закончил с работой, выполняющей работу Node.js, Для меня было хорошим изменением увидеть, как другой язык и фреймворк могут создавать веб-приложения., Я закончил тем, что делал Node.js в течение следующих двух лет. По моему мнению, были / есть две идеи, которые сделали Node.js популярным. Во-первых, неблокирующий ввод-вывод означал, что ваши приложения могли масштабироваться намного быстрее, чем фреймворки с блокирующим I / O. О, как Rails.Second, вы можете написать код на клиенте и на сервере в javascript, что позволит вам уменьшить объем кода, который вы должны были написать. Для первого преимущества Node.js легко обходит Rails, В Интернете было написано много слов о том, насколько хорошо Rails может масштабироваться или нет, поэтому я не собираюсь продолжать эту дискуссию здесь. Все, что я хочу сказать, заключается в том, что масштабирование на Node.js намного проще, чем на Rails., Существуют библиотеки и функции, которые помогают масштабировать Rails, но по умолчанию Node действительно масштабируется намного лучше. Это видно потому, что Ruby не только обычно медленнее языка, чем javascript:

Но сервер Node обычно может обрабатывать гораздо больше запросов, чем сервер Rails:

Неблокирующий ввод-вывод Node действительно светит, когда вам нужно создавать приложения в реальном времени (например, чаты), WebSockets на Node масштабируется прямо из коробки, WebSockets on Rails не легко масштабируется. Похоже, что узел создан для приложений реального времени, Rails был создан для синхронных HTTP-запросов и позже добавил функциональность в реальном времени. Во-вторых, я не чувствовал, что наличие javascript на сервере и клиенте имеет большое значение. Код на клиенте и код на сервере разные, Код, который вы сохраняете, используя один и тот же язык на сервере и клиенте, в лучшем случае незначителен. Одна из функций, которая, как я думал, будет проще в Node, чем в Rails, была одностраничными приложениями., Вместо этого я обнаружил, что подключение одной страницы к бэкэнду потребовало одинакового объема работы в обоих случаях. В конце я бы сказал, что один и тот же язык на клиенте и сервере не является ни "за", ни "против".

Что у Rails было правильно, что Node не сделал

Итак, в чем проблема с Node? Проще говоря: разработка веб-приложения на Rails всегда была проще и быстрее, чем с Node. Я настроил несколько новых проектов Node.js, и каждый раз сталкивался со странными проблемами. Система пакетов по умолчанию (npm) вызывает все виды проблем., Я говорил с несколькими программистами с многолетним опытом работы с Node, и у всех них есть страшные истории npm. Тот факт, что пряжа должна была быть создана в качестве альтернативы, говорит вам все, что вам нужно знать, Вот простой график, показывающий, насколько быстрее пряжа, чем npm:

По некоторым причинам, программисты, которые создают open- Исходные библиотеки JavaScript часто вносят серьезные изменения, Я не могу сосчитать, сколько раз я сталкивался с проблемами при обновлении пакетов в приложениях Node. Я уверен, что столкнулся с проблемами совместимости с Rails менее пяти раз за свою карьеру., Я сталкивался с проблемами совместимости как минимум пятнадцать раз в Node. Кроме того, поскольку Node не является полноценной средой, есть много важных технологий, из которых вы можете выбирать. Используете ли вы MongoDB, PostgreSQL или MySQL в качестве базы данных? Используете ли вы React или Ember или нет фреймворка? Это только вершина айсберга, Я полагаю, что вы должны сделать выбор по крайней мере из пяти важных технологий в своем приложении. Что еще хуже, если вы выберете необычную комбинацию (что вероятно), то у вас будет меньше шансов найти ответы на переполнение стека на любые вопросы, которые вы Для Rails мне казалось, что я почти всегда могу получить исчерпывающий ответ о переполнении стека на любую возникшую проблему., Я чувствовал, что редко могу получить твердый ответ о переполнении стека для любой проблемы с Node, с которой я столкнулся. Я почти гарантирую, что некоторые программисты вызовут меня и скажут, что я не понимаю Node или что я не хороший программист. Несмотря на то, что я не очень хороший программист, мои навыки и понимание не имеют значения, Что я действительно знаю, так это то, что я всегда был намного более продуктивным в Rails, чем в Node.Ruby и Rails чувствуют себя хорошо продуманными и простыми, как никогда не делали javascript и Node.

Мои последние мысли по Rails против Node

Как я размышлял о времени, проведенном с обоими, я не могу не цинично чувствовать, что настоящая причина, по которой Node так популярен, заключается в том, что миру программирования наскучил Rail.Не думаю, что Node - это плохая технология., На самом деле, я думаю, что это здорово, когда вы используете его для правильной цели: создание масштабируемых веб-приложений в режиме реального времени. Но если вы хотите создавать веб-приложения быстро без особых хлопот, я все равно не нашел лучшего выбора, чем Rails.Даже если у вас есть приложение, которое требует немного функциональности в реальном времени, я бы выбрал Rails вместо Node, Добавлять биты функциональности в реальном времени в Rails было бы меньше, чем обычные хлопоты с Node. Только если бы мне нужно было создать приложение с основным компонентом реального времени, которое я бы использовал Node (например, клон Slack). Я не говорю, что «старые» и «скучные» технологии всегда лучше, чем «новые» и «сексуальные» технологии. Вместо этого, выберите технологию, которая поможет вам создать программное обеспечение как можно быстрее., Вот что важно в конце,

danwakeem 4 августа 2019 года <Великий человек статьи, Мне очень нравится слышать о том, как другие разработчики знакомятся с программированием и развиваются вместе с технологиями.

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

Чувак да,

Я не понимаю, почему это происходит с Node.js разработка, Я чувствую, что люди устали от фреймворков во времена Java и C ++, никогда не обновляющих плохо написанные фреймворки, чтобы не нарушить обратную совместимость, Так что, конечно, они просто пошли полностью противоположным путем и обновляют свои фреймворки через день, Честно говоря, я чувствую, что со временем это становится немного лучше, но я все еще боюсь обновлять пакеты узлов, которые я использую.

Как кто-то, кто сначала попал в разработку Node.js, потом позже вошел в разработку Rails Я чувствую, что могу выбросить несколько вещей, которые, как я заметил, идет в противоположном направлении.

Первоначальные затраты времени на изучение рельсов
Написание исполняемого кода поверх фреймворк, который уже относительно менее производителен, сложен

Второе, что действительно связано с первым, что я сказал, но я думаю, что то, что отпугивает людей, Rails изучает фреймворк Rails., Определенно можно сказать, что в основном батареи включают интегрированные фреймворки, которые позаботятся о многих настройках для вас, но я думаю, что есть много разработчиков, которым нравится идея более детального контроля над тем, как их внутренний код настроен, Я чувствую себя намного более потерянным, когда что-то идет не так с чем-то специфичным для Rails, небольшая промежуточная функция, которую я написал в приложении Node.

Во-вторых, мне кажется, что для того, чтобы действительно выучить рельсы, требуется гораздо больше времени, чем думает большинство, Так как Rails работает не так хорошо, как Node, я чувствую, что любая проблема с производительностью, с которой вы сталкиваетесь с вашим собственным кодом, может затянуть приложение Rails намного проще, чем приложение Node.js., Это действительно возвращается к тому времени, затрачиваемому на изучение Rails, Я видел, как хорошие разработчики допускают небольшие ошибки с Rails, которые снижают производительность API.

В конце концов, я думаю, что они действительно являются отличными средами для веба

Продолжить обсуждение
Источник: https://hackernoon.com/what-did-nodejs-provide-that-rails-didnt-m7uh33vx

Якщо у вас виникли питання, вбо ви бажаєте записатися на індивідуальний урок, замовити статтю (інструкцію) або придбати відеоурок, пишіть нам на:
скайп: olegg.pann
telegram, viber - +380937663911
додавайтесь у телеграм-канал: t.me/webyk
email: oleggpann@gmail.com
ми у fb: www.facebook.com/webprograming24
Обов`язково оперативно відповімо на усі запитіння