Как стать автором
Обновить

IO.js или старые грабли под новым соусом

Разработка веб-сайтов *JavaScript *Node.JS *


«Свершилось! Node.js получило развитие в виде форка io.js! Привет ES6! Привет новый V8!» радовались разработчики. Полез смотреть с надеждой, что вот сейчас, начав с нуля, ребята исправили фундаментальные косяки!

Какие фундаментальные ошибки допущены и почему без их исправления промышленный масштаб является спорным или попросту недостижимым. Это не статья-страшилка, как её можно понять, это просьба о помощи, т.к. нода показательно застопорилась, и надежда только в данном проекте.

Обратная совместимость


Нет, речь не о совместимостью с node.js, а речь об отсутствии гарантий, что после «очередного» обновления ядра движка, не отвалится что-то. Такую гарантию даёт JAVA, пускай множество методов считается deprecated и компилятор того гляди начнёт ругаться матом, тем не менее код, написанный на 2-ой яве работает и в 7-ой, и в 8-ой, и мы знаем, что будет работать в дальнейшем. Или, возможен путь C++ и GCC: компиляция с указанием на какой стандарт опираться. Так же отчасти гарантии отсутствуют на уровне документации (см. ниже)
Многие проекты теряли популярность и «горели» именно из-за потери обратной совместимости. Некоторые на её наличии «выехали».
Это критично для развивающейся платформы, движка.

Компилируемые модули


Компилируемые модули это отличная штука! Но очень опасная, увы, нестабильная (в плане сборки), да ещё и зачастую платформозависимая. Поэтому не хватает такой проверки для менеджера пакетов, как «избегать модулей с компилируемыми библиотеками». Пусть будут, если дам добро. Но мне необходимо знать, что таковые есть.
То, что соберётся легко на amd64 может не собраться на Windows и развёртывание просто не получится.
Это критично для движка, который позиционирует себя, как кроссплатформенный и абстрагирующий разработчика от потребности отслеживать платформу, на которой всё исполняется.

Документация


Доки сильно улучшили, но местами всё равно дыры (ФС, Zlib, ...). Перечисление методов и функциональности это не документация, а, скорее, её черновик.
Аргументы, их типы, аргументы и типы возвращаемые в коллбэкфункции, фатальные ошибки, которые «выкинут» ещё до вызова callback это уже документация. Думаю Гуру могут дополнить этот список.
Особое внимание стоит уделить тому, что отсутствие документации говорит о неуверенности авторов и разработчиков движка в том, что всё так и останется. А значит нет никаких гарантий, что это не изменится, типы и порядок аргументов не поменяют и т.д.
Критично для проекта, который используют много разработчиков, где нет времени проверять поведение, особенно в исключительных случаях (зависание сокета, открытие сетевого файла, др.)

Unstable методы и модули


Кто сталкивался с fs.watch поймёт о чём говорю. Напрашивается режим исполнения, при котором весь запускаемый код проверит и выведет модули или скрипты, которые используют нестабильные методы и/или модули. Так как есть шаблоны, которые позволяют обходить нестабильность, хотелось бы их видеть в некоторых аннотациях в документации.
Критично для проектов, ценящих надёжность.

Вывод


Если нужно склепать сайт-визитку, маленький инет-магазин, чатик или форум, то не понятно, чего не хватает в Node.js. Для USS Enterprise же не годятся оба движка по хорошему счёту. О плюсах IO.js уже писали и, даже, совсем недавно о развитии движка и их, бесспорно, стоит принять во внимание.
Учитывая, что движок развивается, активно принимает предложения, я надеюсь что сообщество поможет укрепить IOjs.
Теги:
Хабы:
Всего голосов 38: ↑21 и ↓17 +4
Просмотры 11K
Комментарии Комментарии 29