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

в 6:15, , рубрики: io.js node.js javascript, javascript, node.js

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

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

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

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

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

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

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

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

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

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

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

Вывод

Если нужно склепать сайт-визитку, маленький инет-магазин, чатик или форум, то не понятно, чего не хватает в node.js. Для USS Enterprise же не годятся оба движка по хорошему счёту. О плюсах IO.js уже писали и, даже, совсем недавно о развитии движка и их, бесспорно, стоит принять во внимание.
Я же надеюсь, что не заминусуют, а помогут достучаться до разработчиков, чтобы получить гарантии, документацию, исправления и развитие проекта!

Автор: Louter

Источник

Поделиться

* - обязательные к заполнению поля