«JavaScript - язык будущего?»

>

История началась с письма:

"... пора мигрировать код с Питона на Node.js ..."

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

Что есть у нас:

  • Небольшая команда разработчиков
  • Backend разработка на: python/django
  • Frontend разработка - JavaScript/CoffeeScript
  • Бэкендеры и фронтендеры чаще всего в одном лице
  • Достаточно большой опыт и набор знаний у разработчиков по python

Вопрос: Имеет ли смысл использовать язык JavaScript для новых проектов при текущем наборе людей/при обучение новых людей?

Для этого следует ответить на следующие вопросы:

  • Какие существуют веб-фреймворки для node.js? Качество фреймворков? С какими из используемых нами фреймворков их можно сравнить по функциональности (Django, Flask, etc)?
  • Качество инфраструктуры node.js (пакеты, утилиты)? В сравнении с Python (pip vs npm)?
  • Действительно ли асинхронность node.js дает преимущества?
  • Существуют ли ORM для node.js?
  • Каков порог вхождения в технологию? Может ли разработчик без опыта front-end писать back-end на node.js?
  • Каков сегодняшний тренд? Будет ли node.js мейнстримом?
  • Минусы и минусы node.js?

Существуют ли аналоги Django?

Это один из самых критичных вопросов в ситуации, когда половина новых проектов представляет из себя сайты средней сложности. Что такое сайты средней сложности? Это сервисы вроде мини-instagram/pinterest, где есть социальный функционал или контентные сайты, для которых нужна только админка, что бы добавлять контент, и минимальная логика для обычных пользователей.

Я с уверенностью могу сказать, что реальных аналогов django/rails нет, и с каждым годом я в этом убеждаюсь всё больше, т.к время тут играет очень важную роль. Оба проекта были выпущены в начале 2000-х, и за десятилетние развитие разработчики фреймворков смогли отшлифовать и сбалансировать свой функционал почти до идеального состояния.

Да, если загуглить что-то типа аналог rails для языка {name}, то можно заметить, что на каждом языке есть проекты, которые называют себя аналогом рельсов. Но, если следовать правилу 80/20, то они реализуют базовый набор необходимого функционала, а вот для реализации остальных 20% им потребуются годы.

С виду, если пройтись по туториалам всех популярных веб-фреймворкам, то покажется, что они все очень простые для изучения, но на деле просты только при написание хеллоу ворлдов, а начинать серьезный проект я бы не стал по нескольким причинам:

  • Проблемы базового функционала и предоставляемого API фреймворка

    Как и django, так и рельсы обладают очень обширным внутренним API (на мой вкус, у django лучше, просто мне не нравится программирование, построенное на соглашениях), при помощи которого можно малыми силами реализовать функционал, которого из коробки нет во фреймворке. Например: отлавливать событие регистрации пользователя и отправки ему письма. Я уже не говорю, что можно использовать из самой коробки:

    • Замечательные Class-based views, использование которых уменьшает количество повторяющегося кода
    • Замечательная ORM. Нет правда, в django она одна из лучших и покрывает 95% случаев
    • Security. Мало кто думает о clickjacking/xss/SQL injection/etc
    • Админка из коробки!
    • и т.д

    Есть ли решения на JavaScript со схожими возможностями? Нет! Все эти SailsJS/Express/Koa/etc тянут только на звание мини веб-фреймворков, но не как на аналог django/rails. Я не говорю что они плохи, они решают свою маленькую задачу, но это не альтернатива django, просто они из разных весовых категорий.

  • Количество и качество сторонних батареек.

    Тут я даже не знаю какие примеры приводить. Из-за того, что нет четкого лидера, усилия сообщества размазаны по нескольким решениями, и опять же фактор времени играет важную роль.

    Достаточно попробовать написать сайт с поддержкой авторизации через социальные сети, фоновыми задачами а-ля celery, прозрачной загрузкой файлов в S3, с ресайзом картинок, с социальными фитчами: фоловить/дружить/общаться и т.д. Да, возможно, для половины функционала найдутся батарейки, но возможности и качество их будут не на высоте. Достаточно изучить существующие решения для работы с очередями.

Выводы об альтернативах django/rails с одной стороны очевидны, но не стоит забывать о том, что веб двигается немного в другую концептуальную сторону в плане взаимодействия клиент/сервера, но об этом в выводах.

Инфраструктура

pip vs. npm

Тут коротко. Всё что угодно лечше pip'а!

Коммьюнити/библиотеки/сервисы

Коммьюнити очень большое. Но у php коммьюнити тоже не маленькое! Таким образом, это не показатель. Но отмечу, что самые интересные новые решения появляются из этого коммьюнити. P2P торенты/звонки/чаты в браузере, изоморфные приложения, которые не привязаны к клиент/серверному представлению, десктоп приложения на основе Node.js и т.п. На мой взгляд сейчас от этого немного пользы, но тренд появления на js прикольных вещей только увеличивается из года в год.

Большое коммьюнити приводит к появлению большого количества библиотек. Но это снова не показатель. Очень много библиотек плохого качества. Много интересных библиотек, которые перестали поддерживаться. Хуже всего много раскрученных библиотек, которые форсируют плохую архитектуру (применение инструментов для неподходящих задач - бич всей разработки в целом). Библиотек много, но нет устоявшегося стека. Для большинства важных задач существует как минимум два решения, с одной стороны всегда хорошо, когда есть выбор, а с другой - это очень сильно разделяет сообщество. Можно каждый раз начинать новый проект и за основу брать еще не испробованные решения. Тут у любого начнут разбегаться глаза (при условии, что разработчик смотрит по сторонам, иначе до конца жизни будет писать SPA на jQuery), еще сложнее из этого разнообразия подобрать хороший набор повседневных инструментов. Черт возьми, да, только для сборки проектов существует 5+ решений, каждый из которых вполне достоин. Рассуждать и спорить на эту тему можно бесконечно, и всё будет сводится к большому ИМХО.

Количество сервисов для JavaScript будет только расти дальше. Недавний пример AWS Lambda в которой поддержка платформы Node.js была первой. Parse/Google Node.js/etc, их будет только больше. Я считаю это всё ерундой, я за движение noBackend, а это означает почти только JavaScript.

Про асинхронность

Язык для 2015 года отвратительный. Предоставляемый API для написания асинхронного кода - просто слезы, в сочетание с другой болью вроде передачей контекста исполнения, ... Все это просто превращается в кровавую бойню. Сейчас новый тренд - хвалить новый стандарт ~~ECMAScript 6~~ ECMAScript 2015 и кричать, что он решит ВСЕ проблемы. Да, возможно, что-то он и решит, но, во-первых, он решает всё с таким типичным привкусом js, а, во-вторых, принесет новые проблемы (дополнительные контексты при задании дефолтных значений аргументов SERIOUSLY?). Тема ECMAScript 2015 заслуживает отдельного поста, у меня есть запас ярости по этому вопросу.

Существуют ли ORM для node.js?

Есть. Много. Больше чем надо. Есть ли достойные решения? Можно найти несколько решений уровня sqlalchemy, но меня больше интересует интеграция ORM с веб-фреймворком для того, что бы генерировать формы, REST API, админки, отчеты и т.д. А так да, есть вполне достойные варианты, даже с миграциями. НО я только с ними игрался, и как поведут они себя в продакшене сказать не могу.

Обучение

Обучать JavaScript'ту как первому языку я бы не стал. У меня по этому вопросу есть пара мыслей:

  • Начинать нужно со строго типизированного языка. Возможно, потому что я начинал с Pascal и как мне кажется именно на таких языках приходит понимание о системах типов и т.д
  • Первым языком должен быть язык, на котором точно не будешь работать. Это должно стать толчком на изучение второго языка, а где второй, там и третий. Хороший разработчик должен знать несколько языков.

Но если нам нужны послушные обезьянки, которые 24/7/365 способны заниматься монотонной разработкой похожих друг на друга приложений, то не могу привести доводов против.

Но тут нужно понимать, что backend ≠ frontend разработке, и это совершенно разные сферы деятельности. Громкие слова о том, что один разработчик будет писать нам и сервер, и клиентское приложение, хороши только на бумаге, еще некоторые фантазируют, что на этом можно сэкономить, возьмем одного студента, и он будет работать за двоих. Так это не работает: либо на выходе будет получаться дольше и очень плохо, либо, если всё же найдете упоротого чувака, который будет способен всё делать, то ему придется платить за двоих или за полтора человека, но при этом ириски© будут больше. Но всё же, если целенаправленно планомерно развивать команду вширь, то можно добиться хороших результатов, это потребует ресурсов, и это не значит что с другим стеком это не сработало так же.

Будущее JavaScript

JavaScript - это платформа будущего. То, на что метила Java в свое время, теперь почти победил JavaScript. JavaScript это:

  • Весь фронтенд
  • Бэкенд
  • Мобильные приложения
  • Десктоп приложения
  • Embedded. Холодильники/часы/чайники/IoT

Я тут имею ввиду под JavaScript не просто язык, а платформу, на которой, например, можно запускать другие языки. Несмотря на то, что я просто ненавижу чистый JavaScript, стоит признать, что он побеждает, к сожалению. А побеждает он только за счет того, что ему посчастливилось быть интегрированным в браузер, а браузер сейчас есть везде и нужен всем.

Все пытались влезть в эту нишу языков в браузере. Microsoft => silverlight, который умер, поверх которого можно было даже писать на python в браузере. Google => dart, который скоро умрет. Sun => Java уже давно проиграли. Тут не надо быть большим аналитиком, чтобы понять, что все подобные попытки обречены на провал, потому что для победы нужно объединится всем, а это очень тяжелый шаг для гигантов. Только сейчас они делают попытки объединится и сделать общий стандарт для asm.js, и то под другим названием т.к изначально это разработка Mozilla. И это объединение не против JavaScript, а за его улучшение. Так что у JavaScript как минимум есть будущее.

Pre-Conclusions

Прежде чем делать какие либо выводы, сначала нужно обговорить несколько моментов.

Первая проблема всей индустрии - это неумение выбирать подходящие инструменты под каждую конкретную задачу. Тут не важно, на чем писать, JavaScript или python. Выбрать язык X и думать, что вы нашли идеальный инструмент под все свои задачи, является ошибкой. Нужно постоянно смотреть по сторонам, иначе обречены на боль и страдания.

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

Далее нужно немного пофантазировать, куда будет двигаться индустрия хотя бы ближайшие 3-5 лет.

Django - это очень хороший инструмент, но это инструмент который решает задачи прошлого. Т.е это инструмент для создания сайтов web 1.0 (что бы это не значило), а всё постепенно двигается в другую сторону, когда у нас большие жирные приложения работают на стороне клиента в браузере, а сервер нужен только для того что бы получить данные, которые уже отобразятся нужным образом на стороне клиента. Т.е максимум от сервера нужен только REST API для получения данных и всё (хранения файлов, рассылка писем и т.п давно уже заменяются облачными сервисами).

Связка django + rest-framework - одна из лучших для клепания REST API. А вот делать реалтаймовые приложения с websockets на django - уже плохая идея. Тут либо уходить на решения типа tornado/twisted, вокруг которых батареек кот наплакал, либо приглядываться к решениям поверх Node.js, где с этим немного получше. Если посмотреть на roadmap django, то в ближайшем будущем кардинально ничего не поменяется.

С серверной частью немного разобрались, но JavaScript метит еще в несколько направлений. Это мобильная разработка и десктоп.

С десктоп всё просто, нативные приложения потихоньку вымирают, взамен у нас жирные веб приложения, а тем, кому лень еще и писать нативные приложения с нуля, пилят приложения поверх ~~node-webkit~~ nw.js. Почему? Да потому что это проще и быстрее. Когда есть уже готовые веб-приложения, то проще перенести наработки в виде js, чем писать под все платформы с нуля.

С мобильными всё примерно тоже самое. Т.к у меня на телефоне не стоит ни одной игрушки, то я не нашел ни одного приложения, которого я бы теоретически не смог бы написать на JavaScript. Т.е большая часть приложений заключается в том, что бы сходить дернуть REST API и показать что-то пользователю.

Conclusions

  • Если проекты хоть как-то касаются веба, то вам однозначно нужны JavaScript разработчики. Даже люксофт уже начал проводить тренинги для своих овощей на тему JavaScript/AngularJS
  • Если в компании еще нет устоявшегося серверного стека, то я бы не торопился окунаться в мир Node.js. Исключение, когда есть упоротые люди, готовые тащить это направление
  • Если компания заинтересована в оптимизации процесса разработки проектов и в будущем конкурировать в новых нишах, и есть ресурсы, то потихоньку стоит тратить ресурсы на исследования, делать прототипы и если есть подходящие задачи, пробовать решать их на новом стеке. Это позволит нарабатывать полезные знания, и когда придет время, иметь конкурентные преимущества перед остальными. Например, нужно сделать новостное мобильное приложение и вместо того, чтобы делать его усилиями трех команд (которые нужны в штате) для разных платформ и за ~500 часов, оно будет делаться двумя разработчиками и за 200 часов при этом, не уступая качеством, и дешевле в поддержке, ..., думаю, выгода очевидна
  • Если уже есть наработанный стек, то я бы не стал кидаться срочно всё делать на новом

Выбор за вами...