Корпорация Microsoft признала, что Node+ChakraCore работает более эффективно, чем NOde+V8. На днях редмондская компания отправила официальный запрос ( «pull request») на аппрув уже реализованной корпорацией поддержки ChakraCore в Node.js.
С самого начала своего существования Node.js всегда работал с V8 JavaScript, и эта связка работала весьма эффективно, обеспечивая функционирование многих real-time приложений, в чем Apache, nginx, Tomcat никогда не были особенно хороши. Сообщество Node.js процветало, а Node становился все более и более популярным в среде разработчиков. Крупные компании вроде PayPal, Yahoo, IBM и других присоединились к сообществу проекта.
Одним из самых ранних сторонников проекта стала компания Microsoft. При этом редмондская корпорация стала работать с open-source сообществом все чаще, а относительно недавно компания разработала новый браузер, практически с нуля, используя здесь EdgeHTML и новый JavaScript движок, получивший название Chakra.
Характеристики системы: Intel Core i5-34755 @ 2.90 ГГц с 4.0GB ОЗУ с Windows 10
Изначально новый браузер собирались назвать Spartan, затем переименовали в Edge, и в конце-концов этот обозреватель стал дефолтным в Windows 10, заменив Internet Explorer.
В декабре прошлого года Microsoft пошла дальше, выложив исходники движка Chakra, ChakraCore, в качестве open-source. Никогда до этого компания не предпринимала ничего подобного.
Microsoft тестировала связку Node+Chakra
Совсем недавно компания официально опубликована код ChakraCore на GitHub. Не теряя времени, Microsoft также отправила запрос сообществу Node.js на предмет возможности включения Chakra в качестве альтернативы V8 для разработчиков.
Компания начала проводить тесты работы такой связки еще в мае, и оказалось, что все работает прекрасно. Разработчики Chakra также создали библиотеку, которая получила название chakrashim. С ее помощью происходит автоматическая конвертация API-запросов существующих приложений для V8 в запросы для Chakra.
Удовлетворение запроса может занять некоторое время, поскольку исходники от Microsoft должны быть проверены вручную. Тем не менее, вероятность одобрения запроса командой Node.js довольно высока.
Сообщество Node уже начало работу по отделению V8 от ядра Node
Для подготовки этой работы команда Node стала предлагать разработчикам писать приложения с использованием нового API Native Abstractions для Node.js, чтобы быть уверенными в удалении любых специальных зависимостей от V8 и различными версиями движка.
Не так давно компания Samsung опубликовала информацию относительно того, что Node.js и JavaScript работают на низкопроизводительных системах лучше, чем любые другие платформы.
Если учесть то, что Джиануго Рабеллино (Gianugo Rabellino), занимающий пост руководителя подразделения Open Source Programs в Microsoft также является секретарем совета директоров в Node.js Foundation, то исход дела представляется довольно ясным.
Комментарии (78)
terryP
24.01.2016 16:47+18На днях редмондская компания отправила официальный запрос ( «pull request») проекту Node.js, в котором команду проекта просят обеспечить поддержку ChakraCore, JavaScript движка, наравне с V8, движком Google.
Тут может быть непонимание, «pull request» это обычно предложения залить в репозиторий УЖЕ сделанные изменения, а не просьба изменений (просьба это «new issue»). То есть правильно эту новость видимо читать так «Microsoft реализовала в Node.js поддержку ChakraCore и теперь просит команду проекта заапрувить эти изменения в качестве альтернативы V8» это не совсем тоже самое что «команду проекта просят обеспечить поддержку ChakraCore» (что создает впечатление что команда проекта должна сама сделать эти изменения).
RGB
24.01.2016 17:59+7Что там у nginx не так с realtime?
erlyvideo
24.01.2016 18:38+19он не написан в микрософте. Других объяснений из такого джинсового поста не видать
mayorovp
24.01.2016 22:02+2nginx не имеет исполнять скрипты, поэтому производительность приложений на нем ограничена производительностью бэкенда. Самые же популярные бэкенды для nginx — это, я думаю, apache и php-fpm. Вот так nginx и попал в этот список :)
Crandel
24.01.2016 23:40+2Я на днях хотел скрипт на луа к нджинксу написать, но спасибо, что Вы предупредили меня, что в нджинксе нету возможности исполнять скрипты)
Viacheslav01
24.01.2016 18:54+6«Не так давно компания Samsung опубликовала информацию относительно того, что Node.js и JavaScript работают на низкопроизводительных системах лучше, чем любые другие платформы.
»
Что то я не понял, оно работает лучше чем родная среда с нативными прилоежниями?
Borz
24.01.2016 21:05+2ещё бы ссылочку на эту публикацию, а то на картинке сравнение только NodeJS с NodeJS
Bagobor
25.01.2016 09:35Да, очень сильное замечание (подозреваю что на 3ем цитировании список платформ потеряли :) ). Например github.com/luvit/luvit.io — должно показывать большую производительность.
ComodoHacker
24.01.2016 20:56+2Что ж, очень разумный ход со стороны Microsoft. Если только это не возрождение старой мелкомягкой стратигии «трех E».
Eklykti
24.01.2016 21:08+11Зоопарк движков: теперь и в server-side!
Razaz
24.01.2016 22:01+7Теплый привет от JVM и RVM :) Конкуренция не повредит. Как минимум задумались над слоем абстракции от V8 и не будет завязки на продукты Гугл.
Simplevolk
24.01.2016 22:44+3Вот мы и поняли, какой профит дает «свой» разработчик\менеджер в open-source проекте:)
Razaz
25.01.2016 13:26+9Разве конкуренция это плохо? Там в комментах достаточно подробно обсуждают то, как Гугл подходит к обновлению своего движка. Сильной радости обсуждающие не испытывают. А вот слой абстрации, который разрешит еще SpiderMonkey заиспользовать будет весьма полезен. Раньше все ныли про вендор лок MS, а теперь готовы так же устроить себе вендор лок с Гуглом.
Smerig
26.01.2016 16:13правильно, надо было на нетскейпе оставаться или на осле. Зачем эти ФФ с хромами только придумали…
rumkin
24.01.2016 22:48-5Ну, блин, Майкрософт. Не обижайся, ты клевый, но давай ты просто будешь играть в своей песочнице, а мы в своей.
rumkin
25.01.2016 16:45+2А что минусуете-то? Забыли радости «почти стандартного» поведения? Или почему гугл форкнул webkit в blink? Или как nodejs затормозил в развитии и команда разработчиков была вынуждена форкать проект для возобновления темпов разработки?
mayorovp
25.01.2016 18:43+6Альтернативные движки затем и нужны, чтобы можно было выделить стандартное поведение. Когда реализация всего одна, то ее детали неявно преобразуются в стандарты, и чем дольше ситуация «одна реализация» существует — тем сложнее перейти на что-то другое.
Появление API Native Abstractions можно только приветствовать.rumkin
25.01.2016 19:20+2То о чем вы говорите прекрасно! Но, для этого вовсе незачем внедряться в рабочий проект – сделай форк. Никто ведь не запрещает! Весьма вероятно, что на практике мы получим не только сумму плюсов, но и сумму минусов v8 и Chakra. И если ваш пакет не работает, в Chakra, то пользователь Win будет помечать пакет как нерабочий, потому что полурабочих пакетов не бывает. Это засорит репозиторий пакетов, который уже и так местами попахивает (за последний месяц я несколько раз натыкался на абсолютно нерабочие пакеты, при наличии исправных, но с менее релевантными названиями). Так же стоит вспомнить, что «почти одинаковое поведение» хуже чем просто разное, потому что его сложнее детектить, сложнее отслеживать микро-изменения. Может вы так же верите, что рассинхронизации циклов разработки между Chakra и v8 никогда не произойдет? Тогда история вас ничему не учит.
А самое главное, ответьте на вопрос, почему нельзя сделать форк, отдать на пробу сообществу, чтобы обнаружить скрытые проблемы, а потом мерджиться, когда будет отточено взаимодействие между проектами?mayorovp
25.01.2016 20:06+3С точки зрения github любой Pull Request автоматически подразумевает наличие форка. Более того, традиции требуют чтобы этот форк был еще и рабочим. Так что технически — этот форк уже есть. И его и так каждый может попробовать. Можно начинать пробовать прямо сейчас.
Будут ли приняты изменения в основной проект, и как скоро они будут приняты — зависит не от Microsoft, а от разработчиков ноды.rumkin
25.01.2016 21:38-3Давайте не будем играть понятиями, технически форк, а организационно и информационно? Есть много серверных JS-сред и у каждой свое название, хотя некоторые так же используют, например commonJS-модули, но название у каждой свое, хотя они тоже могли назваться node-something. Очевидно, что это внесет путаницу.
Так вот, если смотреть с точки зрения разработчика, я выступаю за разнообразие и за конкуренцию, но я совершенно не хочу конкуренции внутри моего кода. Опыт подсказывает, что в сложных системах лучше подчеркнуть различия, чем пытаться их замаскировать. Примеры я уже привел, но могу продолжить: Harmony переименовали в es2015, только чтобы избежать путаницы.
В данном случае есть два варианта – объединение и объединение через тестирование, второй более рациональный. Но почему MS не применяет его? Более того у MS есть полный технологический стек, который они могут подключить не задействовав ни строчки стороннего кода, скопировать интерфейсы, назвать это MS Node.NET® и жить припеваючи. Все просто – потому что отдельный проект не даст возможности перетянуть аудиторию. Они хотят получить не просто имя, но и аудиторию разработчиков, так что вместо запуска отдельного проекта они мимикрируют под существующий. Сколько продлится эта мимикрия и не окажется ли паразитной для сообщества предсказать невозможно. Но, если исходить из управления рисками, то пока что MS не сделала для опенсорс сообщества чего-то такого, чтобы получать привилегии первоклассного мейнтейнера и вмешиваться в стратегическое управление. За последние 15 лет, они могли изменить стратегию, но делают это почему-то именно сейчас, когда на горизонте появился WASM, который не то что изменит правила игры, а вероятнее всего в корне перевернет рынок разработки: мы получим быстрый как Си, исполняемый в браузере и на десктопе код. Если помните, то нода с этого и выстрелила – она заманивала разработчиков тем, что язык один и тот же. Так что для меня это выглядит попыткой недружественного вмешательства, без оглядки на последствия. Для начала Майкрософт должна доказать свою лояльность годами сотрудничества, как это делал, например, Гугл, а уже потом лезть со своим уставом.terryP
26.01.2016 13:27+4назвать это MS Node.NET® и жить припеваючи
Уже, проходили с J# вместо Java. Не стоит так делать, ничего хорошего все равно не получится, уж лучше развивать разные движки в рамках одного проекта, чем пытаться пилить свою nod'у c блекджеком и поэтессами. Та же фрагментация Linux платформ одна из главных проблем Linux'a как альтернативной ОС.rumkin
26.01.2016 15:35-3Ну, вы сами себе противоречите. Ок J# умер, доказав, что не особо-то был и нужен. При этом он не засорил собой код Java, а просто тихо ушел. Если у MS проблемы с запуском продуктов зачем пускать его в ядро проекта. Фрагментация Linux – не причина, а результат его гибкости. В linux не заложен механизм мерджа изменений происходящих между дистрибутивами, для устранения фрагментации. Но это другая история.
Движок MS уже поддерживает async/await, v8 – нет. Вот вам готовая фрагментация.
Повторюсь, если MS не может запустить свой проект, то это проблема MS. Если их продукт так полезен и нужен – пусть делают форк с полной поддержкой совместимости, механизм форк/мердж был отработан на iojs. Но MS опять действует в своем стиле, что заставляет задуматься о намерениях и последствиях.terryP
26.01.2016 16:18+3Ок J# умер, доказав, что не особо-то был и нужен. При этом он не засорил собой код Java, а просто тихо ушел.
Он был нужен, только вместо J#, нужен был open-source аналог Java для Net полностью совместимый со стандартом так чтобы программа и под JVM и под Net работала одинаково.
Фрагментация Linux – не причина, а результат его гибкости
Когда программа в дебиане не запускается в федоре, это сложно назвать гибкостью и удобством для пользователей.
Но MS опять действует в своем стиле, что заставляет задуматься о намерениях и последствиях.
Как будто, монополия гугла с его хромиумом чем-то лучше монополии MS. Без конкуренции теряется смысл open-sourc'a, если open-sourc'е зависит от решений одного вендера это всегда плохо, каким бы белым и пушистым он не казался.
Намерения MS просты и понятны — попытаться подвинуть монополию гугла, если при этом хороший open-source получит дополнительные возможности, фичи и независимость от одного вендера это благо. Успех открытых решений Java мира почти всегда завязан на такой вот конкурентной борьбе крупных корпораций, от которой в первую очередь выигрывает само open-source сообщество.
Если их продукт так полезен и нужен – пусть делают форк с полной поддержкой совместимости, механизм форк/мердж был отработан на iojs
Бессмысленно, практически никто не будет пользоваться таким отдельным форком от MS. Это значит что он 100% гарантировано вымрет, то есть вы предлагаете просто выкинуть весь этот код и оставить полную зависимость от решений гугла.rumkin
26.01.2016 18:01-1Я не против конкуренции, а против конкуренции внутри ядра.
Он был нужен, только вместо J#, нужен был open-source аналог Java для Net полностью совместимый со стандартом так чтобы программа и под JVM и под Net работала одинаково.
J# нужен был не сообществу, а MS для популяризации платформы .NET. При этом они допустили грубейшую ошибку, реализовав «почти одинаковое» поведение. Если бы они сделали один-в-один, тогда можно было бы говорить о пользе сообществу.
Когда программа в дебиане не запускается в федоре, это сложно назвать гибкостью и удобством для пользователей.
Вы говорите что фрагментация – зло. При этом предлагаете поместить источник фрагментирования прямо в ядро. Не понимаю вашей логики.
Как будто, монополия гугла с его хромиумом чем-то лучше монополии MS. Без конкуренции теряется смысл open-sourc'a, если open-sourc'е зависит от решений одного вендера это всегда плохо, каким бы белым и пушистым он не казался.
Опять же MS пытается влезть в ядро именно для получения аудитории. Если бы она заботилась о сообществе, то для этого есть более дружественный способ – это форк.
Бессмысленно, практически никто не будет пользоваться таким отдельным форком от MS. Это значит что он 100% гарантировано вымрет...
Или это означает, что он не нужен. Это даже не выглядит улучшением: работать оно будет только на MS и при этом должно работать на 100% одинаково, это означает что мы не получим никакой существенной выгоды, но зато получим сумму недостатков. При этом node.js в данный момент не испытывает существенных трудностей в работе в Windows. Т.е. пока что это улучшение ради улучшения.
При этом я прекрасно понимаю потребности .NET-разработчиков. И, уверен, если бы я был одним из них, я бы хотел получить возможность запускать node.js из кода например на C# без накладных расходов и с максимальной интеграцией в .NET с подробной отладкой. Но для этого незачем внедряться в ядро node.js для этого достаточно сделать форк с полной совместимостью. Еще раз повторю io.js уже так делал, это 100% работает.
Но, даже, если это решение такое полезное и MS так заботится о разработчиках, то давайте MS внедрит свой ChakraShim в .NET для поддержания полной совместимости с v8, а уже потом начнет предлагать его сторонним проектам.Razaz
26.01.2016 19:10+1Зачем запускать ноду из C# кода? 0_о :) Я думаю весь смысл поддержки ноды — больше опций для хостинга на WinServer и дополнительные разработчики для всяких XBox и IoT.
mayorovp
26.01.2016 19:19Нода — это не только сервер, но и куча программ на js для сборки веб-проектов. А ASP.NET-разработчики хотят насладиться возможностями ES6, SASS или LESS ничуть не меньше node.js-разработчиков.
Как в ASP.NET Core я еще не смотрел, но в старом была такая фишка, что изменение .cshtml или .aspx-файла подхватывалось сразу же, без билда проекта. Если захочется сделать такое для скриптов на последней версии js — то без запуска ноды из C# не обойтись.Razaz
26.01.2016 19:32Ну а зачем в коде то это дергать? Сейчас и так все отлично работает. Совершенно нормально нода на билд машине крутится. Причем Core для этого не надо. При билде обновляются скрипты, есть встроенный таск раннер который детектит галп таски.
Зачем это делать напрямую из C# то? :)mayorovp
26.01.2016 19:35Я же написал: чтобы билд проекта при простых изменениях был не нужен. Это значительно сокращает время итераций «изменить файл — посмотреть результат в браузере»
Razaz
26.01.2016 19:38А зачем его билдить? Я просто не понимаю проблемы. Весь фронт — собирается и вотчится через gulp. Вьюхи серверные тут непричем. Билд бэка и фронта совершенно не зависят друг от друга.
mayorovp
26.01.2016 20:25А кто этот самый gulp запустит? Это мне надо, открывая проект, запускать gulp в отдельном консольном окне, которое потом будет мешаться?
А работая над 12ю проектами, надо запускать 12 гулпов? Или запускать их при открытии проекта, и потом закрывать обратно?
Каждому C#-программисту, пришедшему в проект, надо объяснять что такое gulp и что его надо запустить чтобы проект заработал?
Ну и самый веселый вопрос. Как включить выходные файлы гулпа в проект студии — чтобы и в интерфейсе все нормально отображалось, и в выходной пакет при сборке они попали?Razaz
26.01.2016 20:39http://www.dotnetperls.com/process
Вы серьезно? Вы знаете как сейчас Optimization работает?
Если вы открыли 12 студий и решили поработать над 12 проектами — то в чем проблема?
Я не буду говорить про раннер тасков в 15 студии, хотя он все прекрасно находит, но если ваши коллеги не могут хотя бы $ gulp в консоли — это очень тревожный звоночек, так как Optimization deprecated в Asp.Net Core и gulp — рекомендуемый способ сборки всего и вся для фронта.
Серьезно?
ASP.NET Web Deployment using Visual Studio: Deploying Extra Files
Судя по вашим вопросам вы не в курсе что нас ожидает в .Net и Asp.Net Core.mayorovp
26.01.2016 20:54Разумеется, я не в курсе что там меня ожидает. Я об этом прямо написал:
Как в ASP.NET Core я еще не смотрел
Но независимо от того что там — есть куча старых проектов, которые еще пилить и пилить, и новые возможности добавить к ним было бы неплохо.
PS Что вы хотели сказать ссылкой на Process.Start?Razaz
26.01.2016 21:10Если вам надо запустить ноду — то для этого есть Process.Start. Вы так и не объяснили на кой фиг в C# и .Net поддержка ноды.
mayorovp
26.01.2016 21:42Если вам надо запустить ноду — то для этого есть Process.Start
То есть вы все-таки согласны, что запускать ноду из C# нужно?
Вы так и не объяснили на кой фиг в C# и .Net поддержка ноды.
Я про поддержку ноды в C# и .Net ничего и не говорил.Razaz
26.01.2016 22:13Вы издеваетесь? :)
Вы можете запустить все что угодно через Process.Start. Вам не нужна никакая специальная «интеграция».
Нода участвует только в билд процессе и тут хоть батником ее запускайте, хоть из PowerShell, хоть билд процесс на ней нарисуйте и дергайте MSBuild как gulp task.
rumkin Как мне кажется имел ввиду реализацию движка JS для ноды на CLR. В этом ключе это нафиг не нужно, так как как раз есть Chakra.
rumkin
26.01.2016 19:40Ну, например, для создания приложений наподобие atom на .NET платформе.
Razaz
26.01.2016 19:43+1А зачем? MS спокойно пилит на электроне свой редактор и не жужжит. Я имхо вижу единственный смысл поддержки ноды — привлечение разработчиков на pure MS платформы для развития экосистемы. Так как на сервере самому MSу Нода профита никакого не несет. И опять же поддержка Чакры никак не связана с .Net вообще.
rumkin
26.01.2016 22:18Что значит зачем? А зачем они тогда пилят Чакру, когда есть v8 и SpiderMonkey? Зачем они .Net пилят, когда есть Qt? Может для упрощения, ускорения и удешевления разработки? А еще для того чтобы предоставить потребителям полный технологический стек? Или для того чтобы получить общую платформу для любых задач в ОС?
Razaz
26.01.2016 23:08-21. Они уже отказались от идеи сделать все самим.
2. Chakra конкурент V8 и SpiderMonkey. QT не является прямым конкурентом или заменой .Net. Это сравнение теплого с мягким. .Net это рантайм + набор библиотек и он конкурирует с JVM/Java.
3. Разработку они решили удешевлять за счет использования OpenSource :)
4. Еще раз повторюсь, нода нужна для поддержки и расширения экосистемы XBox, IoT и где-то WinServer. Ну и билды, разработка фронтэнда и тд. Больше каких-то применений на Win платформе не вижу. Еще бы VB дропнули и все силы на тюнинг CLR, новые фичи C# и кроссплатформенность.
Antelle
24.01.2016 23:03+3До сих пор мне интересно, что планируется делать с нативными аддонами: компилировать под каждый движок или вводить дополнительную абстракцию?
Fesor
25.01.2016 03:33В статье же написано: Microsoft предоставил ChakraShim, который по сути конвертит вызовы API V8 в вызовы Cackra. Ну и да, с учетом событий с переходом на node4 абстракция не повредит.
ForNeVeR
25.01.2016 08:22А что с переходом на node4? Там какие-то проблемы с нативными аддонами? Поделитесь новостями, пожалуйста.
heilage
25.01.2016 09:39+1Были проблемы. Не зря NAN появился. Бинарные модули, использовавшие api v8 напрямую (в версиях 0.10 и 0.12), были непригодны для компиляции с новой nodejs, когда она появилась. Своими руками портировал node-rsvg, например, после перевода его на NAN отпали проблемы с компиляцией на всех существующих версиях node/io.
Kain_Haart
25.01.2016 10:30+13Корпорация Microsoft признала, что Node+ChakraCore работает более эффективно, чем NOde+V8.
А до этого усердно отрицала?
Ununtrium
25.01.2016 10:52+12Гуманитарные новости на хабре. Pull request, оказывается, «запрос на аппрув реализации» или «официальный запрос». Золотое правило в технических статьях — не знаешь термин, не переводи. Понятнее будет.
mayorovp
25.01.2016 11:15-2Осталось придумать способ отличать незнакомые термины от обычных слов…
Ununtrium
25.01.2016 14:53Технические статьи это не журналистика, переводить могут люди, которые в теме. Это вам не гиктаймс.
mayorovp
25.01.2016 18:45Золотое правило в технических статьях — не знаешь термин, не переводи.
Разговор изначально шел о переводчиках, которые «не в теме».Ununtrium
27.01.2016 14:06Нет, имелось ввиду «не знаешь термин на русском».
mayorovp
27.01.2016 14:10Мне почему-то казалось, что исходный комментарий был советом переводчику обсуждаемой сейчас новости. А он явно «не в теме», потому что человек «в теме», даже не зная правильного перевода термина «Pull request», никогда не назовет его так, как назвал.
JCHouse
25.01.2016 11:37-6Я так понял они сделали очередной ИЕ6, в котором есть все плюшки из последнего JS и даже больше. Но, на это раз, все сделали правильно и отдали на опенсорс. Ну что сказать, молодцы, растут!
Ununtrium
25.01.2016 15:45+2>сделали очередной ИЕ6
>в котором есть все плюшки из последнего JS
Как-то не стыкуется.JCHouse
25.01.2016 17:07+7Судя по всему все минусующие, и вы в том числе, несколько моложе чем запуск ИЕ6 :) И просто не понимают насколько прорывным был тот браузер на момент запуска. И что на самом деле у него просто не было конкурентов. И уже спустя несколько лет он стал он стал отстой и тяжелым интерпрайзом жестко привязанным к версии ОС. перестал развиваться и блокировал переходы на новую версию. Конечно если не менять продукт несколько лет и террорить пользователей он станет для всех страшилкой, но так было далеко не всегда.
Ununtrium
25.01.2016 17:51-3Судя по всему, вы достаточно стары чтобы не понимать концепцию опен сорса. Если популярный опен сорс проект начинает стагнировать, его можно форкнуть и делать свой. Пример — MySQL. Так что сравнение неуместно в этом случае.
JCHouse
25.01.2016 18:26+1А где я выступил против? Может все таки прочитать мой коммент, где я похвалил МС за открытие исходников, и посетовал что они не сделали это с ИЕ в отличие от NS с их firefox из которого потом восcтал Fenix. Право дело, не стоит обижаться, стоит внимательно читать.
Ununtrium
26.01.2016 12:47Ваша ошибка в том, что вы используете IE6 как синоним «прорывной браузер». Не надо так. Это браузер, который поддерживался в обращении абсолютно неадекватный срок после устаревания. Таким он и останется в памяти большинства веб-разработчиков.
JCHouse
25.01.2016 17:14+1Еще напомню, что на момент выхода ИЕ6 не было не Лисы не Оперы, точнее Опера-то была, но еще не престо, а поделка с отключаемой за деньги рекламой, как и Нетскайп, который кстати и умер из-за того что (внимание!) ИЕ был бесплатным.
k12th
Надо заметить, что ChakraCore заметно выигрывает по крайней мере в реализации ES2015. V8 как-то поотстала с этим.
k12th
После релиза 4.9 беру свои слова назад:)