Спорным этот пулл реквест выглядит потому, что в нем предлагается сделать то, что не удавалось сделать сообществу на протяжении последних нескольких лет – создать слой абстракции над движком JavaScript и уберечь код написаный на С/С++ от постоянного переписывания вслед за изменением архитектуры v8. В MS написали прокладку (shim), эмулирующую поведение v8, и назвали ее ChakraShim.
Многих возмутила попытка MS стать участником первого класса в проекте и влиять на разработку ядра. Это и вправду можно назвать недружественным вмешательством, ведь механизм форка существует давно и хорошо себя зарекомендовал. А с учетом того, что Chakra достаточно новый движок и только зарабатывает свою первую репутацию в среде опен сорс, форк выглядит куда более логичным. Тем более, что и работает движок только под Windows.
В ходе обсуждений было принято решение не сливать проекты воедино и ограничиться форком, но уже в репозиториях nodejs, до момента появления хоть сколько-нибудь стабильной версии. После чего Chakra станет полноценным движком Node.js. Вот, собственно, и вся новость, если бы не несколько интересных деталей.
Интересные детали
Microsoft не перестает удивлять своей новоявленной открытостью, предоставляя закрытые ранее технологии общественности. Корпорация предоставляет сообществу многое из того, что разработчики хотели видеть открытым еще с начала нулевых. Более того MS открывает абсолютно новые разработки. На фоне этого участие компании в разработке Node.js выглядит логичным. Тем более, что MS планирует использовать результат симбиоза в своих IoT продуктах, а у node.js есть огромная база кода.
Но, зачем все это MS, если у них есть собственный стек от IoT до мобильной платформы и серверов, почему не сделать еще один собственный продукт, дополнив им XAML? Достаточно сделать его совместимым с Nodejs. Зачем вкладываться в сообщество, которое не слишком-то лояльно и в продукт, который не занимает значительной доли в твоем техпроцессе? Кто-то, может считать что MS отказалась от стратегии самостоятельной разработки. Но это совсем не тянет на исчерпывающее объяснение.
Давайте посмотрим в сторону WebAssembly. Это технология браузерного байткода, сочетающая скорость и энергоэффективность близкую к C; безопасность исполнения и высочайшую скорость доставки, доступную сегодня только браузеру. Так же добавьте сюда самое широкое распространение среди прочих сред. Плюс абстракция от какого-либо языка! Крайне вероятно, что эта технология перевернет рынок разработки программного обеспечения, как когда-то мобильные приложения перевернули разработку и отхватили огромную долю у веба. Но, кто сегодня занимает лидирующие позиции в вебе, не Google ли с Chrome и v8 под капотом!? Для Microsoft это сулит серьезные последствия, как минимум изнуряющую борьбу.
Но это лишь одна деталь, по ней нельзя делать достоверных прогнозов. Как js разработчик, я очень жду появления wasm, и прогнозировал включение экспериментальной поддержки в июне-июле 2016 – все-таки не такая простая задача – разработать новую всеобъемлющую технологию для веба. Но темпы разработки оказались значительно выше – Google уже тестирует wasm в v8. Интересно, что решение начать разработку слоя абстракции в Node.js, не принималось на протяжении нескольких лет из-за очевидной трудности задачи и отсутствия вообще какого-либо представления о том, как это сделать. С появление ChakraShim решение было принято меньше чем за неделю. И, что не менее интересно, без каких либо внятных причин технический коммитет принимает решение завершить работы к апрелю и назначает этой задаче самый высокий приоритет. Дело в том, что с пришествием wasm необходимость в абстракции отпадет, так как большинство модулей можно будет перенести на wasm без существенной потери производительности, но с избавлением от платформозависимости. А это значит, что Google отхватит жирный кусок уже внутри самой Windows, пусть и не напрямую, но все же.
Конечно, возможно, Microsoft просто пытается укрепить позиции. Но, судя по рискам, которые возникают перед MS, компания стремиться обезопасить свои владения и, возможно, примеряется к Nodejs перед покупкой (напомню, что Nodejs – это торговая марка Joyent, а, значит, может быть продана). В любом случае это первые признаки новой технологической войны, разворачивающейся вокруг wasm. И, в ближайшее время стоит ожидать усиления присутствия Microsoft в Node.js.
Комментарии (27)
MuLLtiQ
05.02.2016 00:30-1А зачем вообще нужна поддержка других движков в Node.js? Чем V8 плох? Зачем вообще нужны два движка в одном репозитории? Может тогда до кучи еще и SpiderMonkey, и Rhino туда запихнуть.
И я не понимаю — как они собираются обратную совместимость с плагинами обеспечить?
А вообще это новым io.js-ом попахивает, как по мне.
inf
05.02.2016 01:18+11v8 меняется и модули c++ написанные для node.js 0.10 не подходят для 0.12 и совсем не подходят для 4.х и для 5.х
Есть пакет nan для npm, но это один фиг не избавляет от необходимости переписывать модули.
Микрософт таким вливанием слоя абстракции v8 очень сильно поддержало проект. Что за этим стоит? Наверняка заговор трансконтинентальных корпораций :)MuLLtiQ
05.02.2016 01:35+5Хорошо, скажем слой абстракции нужен для того чтобы обеспечивать обратную совместимость (и почему его раньше-то не сделали :)) Но все равно — зачем нужен второй движок? Ведь в этом случае нужно обеспечивать совместимость с двумя движками одновременно, разве нет?
Вопрос вот в чем — мне, по сути, предоставляют выбор, о котором я не просил и который решает проблему которой, по сути, нет (или я ее не осознаю). Я понимаю разницу, например, между CPython и PyPy или каким-нибо Stackless, но чем Node с Chakra под капотом лучше чем Node с v8 или Node со SpiderMonkey?
uSide
05.02.2016 02:41Они хотят сделать прослойку, которая будет позволять абстрагироваться от движка. Например: у вас приложение, которое на js мапит огромный массив. Вы тестируете и обнаруживаете, что с движком Chakra в вашем случае есть прирост скорости 10%. Меняете движок на Chakra — profit. Это как перейти с Node 0.12 на io, получить прирост в ~30%, но при этом без геммороя с нативными модулями
slonopotamus
05.02.2016 09:20+1Меняете движок на Chakra — profit.
Это так не работает. Нельзя просто так взять и сменить ключевой элемент и чтобы при этом ничего не отвалилось. Попробуйте программе на C сменить libc. Попробуйте программе на Java сменить JDK. Попробуйте программу на питоне, писавшуюся под CPython, запустить на JPython. Да что далеко ходить, в браузерах до сих пор есть отличия в обработке JS/HTML/CSS.
msnre
05.02.2016 10:11-2Попробуйте сменить MyISAM на InnoDB в MySQL — у вас же просто так не получится! Oh, wait…
Eklykti
05.02.2016 10:35+6Фуллтекст индексы, например, от такого действия отвалятся. А от обратного действия отвалится поддержка внешних ключей и, если я не ошибаюсь, транзакций.
stychos
05.02.2016 14:29Окай, попробуйте заменить в материнке один микропроцессор на другой — у вас же просто так не получится? О, ведь железо — это тоже просто слой абстракции.
DarthVictor
05.02.2016 12:12+2Это так не работает.
Вообще-то работает. Существует куча софта который работает на разных платформах и собирается разными компиляторами. Просто софт должен быть написан соответстветствующем образом.
Попробуйте программе на C сменить libc.
Сравнение скорости на GCC и Clang www.phoronix.com/scan.php?page=article&item=clang-37-gcc52&num=4
У них не то что libc, у них все разное.
Попробуйте программу на питоне, писавшуюся под CPython, запустить на JPython
Прекрасно заработает, если нет нативных библиотек в зависимостях.
docs.djangoproject.com/en/1.9/howto/jython
github.com/jruby/jruby/wiki/JRubyOnRails
То что на каком-то софте такой подход не работает, это не значит, что это не возможно, это значит, что разработчикам жалко ресурсов или им это просто нафиг не нужно.
Посмотрите список поддерживаемых платформ у Qt doc.qt.io/qt-5/supported-platforms.html
А у него несколько миллионов строк кода.slonopotamus
05.02.2016 12:33+2Я не говорил, что невозможно обеспечить работоспособность софта в разном окружении, конечно возможно. Но это требует ненулевых затрат, а не просто взять и заменить окружение. И те же джангу с рельсами изрядно патчили для того чтобы они смогла работать под JVM.
ruslanys
07.02.2016 01:27Попробуйте программе на Java сменить JDK
Не буду вдаваться в подробности, но прежде чем утверждать, хотя бы попробуйте: www.oracle.com/technetwork/java/javase/downloads/index.html
hell0w0rd
05.02.2016 03:46+2Гм. Допустим Chakra умеет больше ES2015, чем v8. Вполне возможно где-то один движок превосходит другой. Альтернатива — это всегда хорошо. У v8 есть свои минусы и свои плюсы.
А еще есть интересное развитие событий — завтра google заявит о потере интереса к v8 и останется команда энтузиастов. Для мелких компаний это ничего не изменит, а крупные задумаются.MuLLtiQ
05.02.2016 17:18+3А как синхронизировать одновременно два движка в одной реализации? Если v8 реализует фичу A, а Chakra — фичу B, как обеспечить возможность использования этих фич в Node.js? Или придется ждать пока оба движка реализуют все возможности? А если движков будет три (четыре, пять)?
hell0w0rd
05.02.2016 18:08Ну смотря про какие фичи вы говорите. JS стандартная библиотека прямо сейчас никак в доках ноды не описана. Можно догадаться об определенных вещах по текущей версии v8.
А для нативных аддонов будет либо внутренняя, либо внешняя (nan) библиотека. От нее не много требуется. Просто прокидывать объекты туда и обратно.
inf
05.02.2016 15:19Вопрос вот в чем — мне, по сути, предоставляют выбор, о котором я не просил и который решает проблему которой, по сути, нет (или я ее не осознаю).
Осознаете когда какая-нибудь зависимость в пятом колене цепанёт нативный модуль на с++ и он не скомпилируется под вашу версию nodejs.
Хотели как лучше — писать на js на сервере и клиенте, но навыки с++ будут не лишними, чтобы доработать проект напильником в нужную сторону :))MuLLtiQ
05.02.2016 17:17+3Я не против иметь Plugin API который обеспечит обратную совместимость и абстрагирует меня от внутренностей V8 и если это возможно — предоставит мне возможность использовать другие движки. Меня скорее интересует зачем иметь два движка в зависимостях в кодовой базе в референсной реализации. Если Майкрософт хочет Node на Chakra, почему бы не сделать форк — какой-нибудь chakranode и его сможет использовать кто угодно, если это ему нужно.
kobezzza
05.02.2016 03:02+2Мне кажется, что в этой ситуации также поможет внедрение Wasm, т.е. С++ модули будут предварительно скомпилены в формат WebAssembly, который будет работать на любой VM с поддержкой Wasm. Ну по сути сейчас уже так можно делать с ASM.js, но это всё таки костыль, да и к тому же в полной мере в V8 его вроде так и не поддерживают.
NiPh
05.02.2016 10:38+14>> Chakra официально принят Node.js… И несмотря на то, что пулл реквест до сих пор не был принят…
Я не понимаю зачем вы так.
Yeah
05.02.2016 13:04+7>> Chakra официально принят Node.js
>> В ходе обсуждений было принято решение не сливать проекты воедино и ограничиться форком до момента появления хоть сколько-нибудь стабильной версии.
Заголовок 80-лвл. А ведь даже не Ализар…
Valery4
05.02.2016 14:27+2Ну продадут они тоговую марку, допустим. Как показала практика, сообщество спокойненько свинтило делать свою реализацию, когда начали закручивать гайки.
gxcreator
05.02.2016 14:33+6Видимо мы наблюдаем второй шаг
https://ru.wikipedia.org/wiki/Embrace,_Extend,_and_Extinguish
ZoomLS
>>Тем более, что и работает движок только под Windows.
Закапывайте.
>>Microsoft не перестает удивлять своей новоявленной открытостью, предоставляя закрытые ранее технологии общественности.
А дальше уже пошли маркетинговые сказки.
olegkrasnov
Они его вроде портировать будут.
funca
без JIT не нужно
Razaz
Yes, its currently Windows only. For cross-platform support, the key target for next six months on the roadmap is to get the interpreter & runtime working. JIT would come after that (don't read it as no JIT forever — it was just a breakdown of what we need enable and its ordering for next 6 mos).
Оригинал коммента.
funca
Поживем-увидим) Microsoft уже давно
обещаютопенсорсят. Напомните какой-нибудь их софт, который под линуксами работает классно?Встраивая ChakraCore в Node.js они решают вполне конкретную бизнес-задачу с продвижением Azure — там для Chakra (у которого CharkaCore лишь маленький кусочек) куча своих фишек, но проблемы с отсутствием конечных js-библиотек и фреймворков, которые в массе своей точатся под ноду, что снижает привлекательность платформы. Неспешно портировав базовые куски интерпретора на линуксы, они получат дополнительные возможности в плане регрессионного тестирования, и, вероятно, пересаживания разработчиков. Это все понятно. Но JIT это сильно более хитрое колдунство, как для технарей, так и для бизнесов, чем просто интерпретатор (посмотрите на Java, и историю развития альтернативных JVM). JIT для линуксов если и появится, то будет не настолько бесплатным, чтобы оставался смысл не пользоваться Azure. Тут вам не Googe))
Razaz
CoreCLR. На маке норм :)
Думаю опыта в разработке колдунств у них предостаточно. Смысла особо не вижу в платном JIT. В свете перевода финансовых потоков на рельсы subscription based model нафиг это им надо. Они нашли свою жилу в виде Azure + Office Online и необходимость в анальном огораживании резко отпала. Сейчас пилят под все подряд и стригут купоны :)
Вполне вероятен сценарий, когда на винде перфоманс будет бодрее чем на никсах. Но это вполне ожидаемо и криминала в этом не вижу. Для той же JVM то же есть платные варианты с фейрверком из одного места, цыганами и медведями :) Вот на этой копеечке они могут и заработать.