Comments 78
Надо заметить, что ChakraCore заметно выигрывает по крайней мере в реализации ES2015. V8 как-то поотстала с этим.
После релиза 4.9 беру свои слова назад:)
На днях редмондская компания отправила официальный запрос ( «pull request») проекту Node.js, в котором команду проекта просят обеспечить поддержку ChakraCore, JavaScript движка, наравне с V8, движком Google.
Тут может быть непонимание, «pull request» это обычно предложения залить в репозиторий УЖЕ сделанные изменения, а не просьба изменений (просьба это «new issue»). То есть правильно эту новость видимо читать так «Microsoft реализовала в Node.js поддержку ChakraCore и теперь просит команду проекта заапрувить эти изменения в качестве альтернативы V8» это не совсем тоже самое что «команду проекта просят обеспечить поддержку ChakraCore» (что создает впечатление что команда проекта должна сама сделать эти изменения).
Node.js c движком ChakraCore только на Windows работает?
ОМФГ, теперь «костылинг под ослов» и до сервер-сайда доберется? О__о
а проясните: это смена движка под капотом или будет выбор с каким движком запускать ноду?
Что там у nginx не так с realtime?
он не написан в микрософте. Других объяснений из такого джинсового поста не видать
nginx не имеет исполнять скрипты, поэтому производительность приложений на нем ограничена производительностью бэкенда. Самые же популярные бэкенды для nginx — это, я думаю, apache и php-fpm. Вот так nginx и попал в этот список :)
«Не так давно компания Samsung опубликовала информацию относительно того, что Node.js и JavaScript работают на низкопроизводительных системах лучше, чем любые другие платформы.
»
Что то я не понял, оно работает лучше чем родная среда с нативными прилоежниями?
»
Что то я не понял, оно работает лучше чем родная среда с нативными прилоежниями?
Возможно, подразумевалось сравнение с другими интерпретируемыми системами.
ещё бы ссылочку на эту публикацию, а то на картинке сравнение только NodeJS с NodeJS
Да, очень сильное замечание (подозреваю что на 3ем цитировании список платформ потеряли :) ). Например github.com/luvit/luvit.io — должно показывать большую производительность.
Что ж, очень разумный ход со стороны Microsoft. Если только это не возрождение старой мелкомягкой стратигии «трех E».
Зоопарк движков: теперь и в server-side!
Теплый привет от JVM и RVM :) Конкуренция не повредит. Как минимум задумались над слоем абстракции от V8 и не будет завязки на продукты Гугл.
Вот мы и поняли, какой профит дает «свой» разработчик\менеджер в open-source проекте:)
Разве конкуренция это плохо? Там в комментах достаточно подробно обсуждают то, как Гугл подходит к обновлению своего движка. Сильной радости обсуждающие не испытывают. А вот слой абстрации, который разрешит еще SpiderMonkey заиспользовать будет весьма полезен. Раньше все ныли про вендор лок MS, а теперь готовы так же устроить себе вендор лок с Гуглом.
правильно, надо было на нетскейпе оставаться или на осле. Зачем эти ФФ с хромами только придумали…
Ну, блин, Майкрософт. Не обижайся, ты клевый, но давай ты просто будешь играть в своей песочнице, а мы в своей.
Они поняли, что в одиночестве играть неинтересно, предлагают дружить.
А что минусуете-то? Забыли радости «почти стандартного» поведения? Или почему гугл форкнул webkit в blink? Или как nodejs затормозил в развитии и команда разработчиков была вынуждена форкать проект для возобновления темпов разработки?
Альтернативные движки затем и нужны, чтобы можно было выделить стандартное поведение. Когда реализация всего одна, то ее детали неявно преобразуются в стандарты, и чем дольше ситуация «одна реализация» существует — тем сложнее перейти на что-то другое.
Появление API Native Abstractions можно только приветствовать.
Появление API Native Abstractions можно только приветствовать.
То о чем вы говорите прекрасно! Но, для этого вовсе незачем внедряться в рабочий проект – сделай форк. Никто ведь не запрещает! Весьма вероятно, что на практике мы получим не только сумму плюсов, но и сумму минусов v8 и Chakra. И если ваш пакет не работает, в Chakra, то пользователь Win будет помечать пакет как нерабочий, потому что полурабочих пакетов не бывает. Это засорит репозиторий пакетов, который уже и так местами попахивает (за последний месяц я несколько раз натыкался на абсолютно нерабочие пакеты, при наличии исправных, но с менее релевантными названиями). Так же стоит вспомнить, что «почти одинаковое поведение» хуже чем просто разное, потому что его сложнее детектить, сложнее отслеживать микро-изменения. Может вы так же верите, что рассинхронизации циклов разработки между Chakra и v8 никогда не произойдет? Тогда история вас ничему не учит.
А самое главное, ответьте на вопрос, почему нельзя сделать форк, отдать на пробу сообществу, чтобы обнаружить скрытые проблемы, а потом мерджиться, когда будет отточено взаимодействие между проектами?
А самое главное, ответьте на вопрос, почему нельзя сделать форк, отдать на пробу сообществу, чтобы обнаружить скрытые проблемы, а потом мерджиться, когда будет отточено взаимодействие между проектами?
С точки зрения github любой Pull Request автоматически подразумевает наличие форка. Более того, традиции требуют чтобы этот форк был еще и рабочим. Так что технически — этот форк уже есть. И его и так каждый может попробовать. Можно начинать пробовать прямо сейчас.
Будут ли приняты изменения в основной проект, и как скоро они будут приняты — зависит не от Microsoft, а от разработчиков ноды.
Будут ли приняты изменения в основной проект, и как скоро они будут приняты — зависит не от Microsoft, а от разработчиков ноды.
Давайте не будем играть понятиями, технически форк, а организационно и информационно? Есть много серверных JS-сред и у каждой свое название, хотя некоторые так же используют, например commonJS-модули, но название у каждой свое, хотя они тоже могли назваться node-something. Очевидно, что это внесет путаницу.
Так вот, если смотреть с точки зрения разработчика, я выступаю за разнообразие и за конкуренцию, но я совершенно не хочу конкуренции внутри моего кода. Опыт подсказывает, что в сложных системах лучше подчеркнуть различия, чем пытаться их замаскировать. Примеры я уже привел, но могу продолжить: Harmony переименовали в es2015, только чтобы избежать путаницы.
В данном случае есть два варианта – объединение и объединение через тестирование, второй более рациональный. Но почему MS не применяет его? Более того у MS есть полный технологический стек, который они могут подключить не задействовав ни строчки стороннего кода, скопировать интерфейсы, назвать это MS Node.NET® и жить припеваючи. Все просто – потому что отдельный проект не даст возможности перетянуть аудиторию. Они хотят получить не просто имя, но и аудиторию разработчиков, так что вместо запуска отдельного проекта они мимикрируют под существующий. Сколько продлится эта мимикрия и не окажется ли паразитной для сообщества предсказать невозможно. Но, если исходить из управления рисками, то пока что MS не сделала для опенсорс сообщества чего-то такого, чтобы получать привилегии первоклассного мейнтейнера и вмешиваться в стратегическое управление. За последние 15 лет, они могли изменить стратегию, но делают это почему-то именно сейчас, когда на горизонте появился WASM, который не то что изменит правила игры, а вероятнее всего в корне перевернет рынок разработки: мы получим быстрый как Си, исполняемый в браузере и на десктопе код. Если помните, то нода с этого и выстрелила – она заманивала разработчиков тем, что язык один и тот же. Так что для меня это выглядит попыткой недружественного вмешательства, без оглядки на последствия. Для начала Майкрософт должна доказать свою лояльность годами сотрудничества, как это делал, например, Гугл, а уже потом лезть со своим уставом.
Так вот, если смотреть с точки зрения разработчика, я выступаю за разнообразие и за конкуренцию, но я совершенно не хочу конкуренции внутри моего кода. Опыт подсказывает, что в сложных системах лучше подчеркнуть различия, чем пытаться их замаскировать. Примеры я уже привел, но могу продолжить: Harmony переименовали в es2015, только чтобы избежать путаницы.
В данном случае есть два варианта – объединение и объединение через тестирование, второй более рациональный. Но почему MS не применяет его? Более того у MS есть полный технологический стек, который они могут подключить не задействовав ни строчки стороннего кода, скопировать интерфейсы, назвать это MS Node.NET® и жить припеваючи. Все просто – потому что отдельный проект не даст возможности перетянуть аудиторию. Они хотят получить не просто имя, но и аудиторию разработчиков, так что вместо запуска отдельного проекта они мимикрируют под существующий. Сколько продлится эта мимикрия и не окажется ли паразитной для сообщества предсказать невозможно. Но, если исходить из управления рисками, то пока что MS не сделала для опенсорс сообщества чего-то такого, чтобы получать привилегии первоклассного мейнтейнера и вмешиваться в стратегическое управление. За последние 15 лет, они могли изменить стратегию, но делают это почему-то именно сейчас, когда на горизонте появился WASM, который не то что изменит правила игры, а вероятнее всего в корне перевернет рынок разработки: мы получим быстрый как Си, исполняемый в браузере и на десктопе код. Если помните, то нода с этого и выстрелила – она заманивала разработчиков тем, что язык один и тот же. Так что для меня это выглядит попыткой недружественного вмешательства, без оглядки на последствия. Для начала Майкрософт должна доказать свою лояльность годами сотрудничества, как это делал, например, Гугл, а уже потом лезть со своим уставом.
назвать это MS Node.NET® и жить припеваючи
Уже, проходили с J# вместо Java. Не стоит так делать, ничего хорошего все равно не получится, уж лучше развивать разные движки в рамках одного проекта, чем пытаться пилить свою nod'у c блекджеком и поэтессами. Та же фрагментация Linux платформ одна из главных проблем Linux'a как альтернативной ОС.
Ну, вы сами себе противоречите. Ок J# умер, доказав, что не особо-то был и нужен. При этом он не засорил собой код Java, а просто тихо ушел. Если у MS проблемы с запуском продуктов зачем пускать его в ядро проекта. Фрагментация Linux – не причина, а результат его гибкости. В linux не заложен механизм мерджа изменений происходящих между дистрибутивами, для устранения фрагментации. Но это другая история.
Движок MS уже поддерживает async/await, v8 – нет. Вот вам готовая фрагментация.
Повторюсь, если MS не может запустить свой проект, то это проблема MS. Если их продукт так полезен и нужен – пусть делают форк с полной поддержкой совместимости, механизм форк/мердж был отработан на iojs. Но MS опять действует в своем стиле, что заставляет задуматься о намерениях и последствиях.
Движок MS уже поддерживает async/await, v8 – нет. Вот вам готовая фрагментация.
Повторюсь, если MS не может запустить свой проект, то это проблема MS. Если их продукт так полезен и нужен – пусть делают форк с полной поддержкой совместимости, механизм форк/мердж был отработан на iojs. Но MS опять действует в своем стиле, что заставляет задуматься о намерениях и последствиях.
Ок 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% гарантировано вымрет, то есть вы предлагаете просто выкинуть весь этот код и оставить полную зависимость от решений гугла.
Я не против конкуренции, а против конкуренции внутри ядра.
J# нужен был не сообществу, а MS для популяризации платформы .NET. При этом они допустили грубейшую ошибку, реализовав «почти одинаковое» поведение. Если бы они сделали один-в-один, тогда можно было бы говорить о пользе сообществу.
Вы говорите что фрагментация – зло. При этом предлагаете поместить источник фрагментирования прямо в ядро. Не понимаю вашей логики.
Опять же MS пытается влезть в ядро именно для получения аудитории. Если бы она заботилась о сообществе, то для этого есть более дружественный способ – это форк.
Или это означает, что он не нужен. Это даже не выглядит улучшением: работать оно будет только на MS и при этом должно работать на 100% одинаково, это означает что мы не получим никакой существенной выгоды, но зато получим сумму недостатков. При этом node.js в данный момент не испытывает существенных трудностей в работе в Windows. Т.е. пока что это улучшение ради улучшения.
При этом я прекрасно понимаю потребности .NET-разработчиков. И, уверен, если бы я был одним из них, я бы хотел получить возможность запускать node.js из кода например на C# без накладных расходов и с максимальной интеграцией в .NET с подробной отладкой. Но для этого незачем внедряться в ядро node.js для этого достаточно сделать форк с полной совместимостью. Еще раз повторю io.js уже так делал, это 100% работает.
Но, даже, если это решение такое полезное и MS так заботится о разработчиках, то давайте MS внедрит свой ChakraShim в .NET для поддержания полной совместимости с v8, а уже потом начнет предлагать его сторонним проектам.
Он был нужен, только вместо 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, а уже потом начнет предлагать его сторонним проектам.
Зачем запускать ноду из C# кода? 0_о :) Я думаю весь смысл поддержки ноды — больше опций для хостинга на WinServer и дополнительные разработчики для всяких XBox и IoT.
Нода — это не только сервер, но и куча программ на js для сборки веб-проектов. А ASP.NET-разработчики хотят насладиться возможностями ES6, SASS или LESS ничуть не меньше node.js-разработчиков.
Как в ASP.NET Core я еще не смотрел, но в старом была такая фишка, что изменение .cshtml или .aspx-файла подхватывалось сразу же, без билда проекта. Если захочется сделать такое для скриптов на последней версии js — то без запуска ноды из C# не обойтись.
Как в ASP.NET Core я еще не смотрел, но в старом была такая фишка, что изменение .cshtml или .aspx-файла подхватывалось сразу же, без билда проекта. Если захочется сделать такое для скриптов на последней версии js — то без запуска ноды из C# не обойтись.
Ну а зачем в коде то это дергать? Сейчас и так все отлично работает. Совершенно нормально нода на билд машине крутится. Причем Core для этого не надо. При билде обновляются скрипты, есть встроенный таск раннер который детектит галп таски.
Зачем это делать напрямую из C# то? :)
Зачем это делать напрямую из C# то? :)
Я же написал: чтобы билд проекта при простых изменениях был не нужен. Это значительно сокращает время итераций «изменить файл — посмотреть результат в браузере»
А зачем его билдить? Я просто не понимаю проблемы. Весь фронт — собирается и вотчится через gulp. Вьюхи серверные тут непричем. Билд бэка и фронта совершенно не зависят друг от друга.
А кто этот самый gulp запустит? Это мне надо, открывая проект, запускать gulp в отдельном консольном окне, которое потом будет мешаться?
А работая над 12ю проектами, надо запускать 12 гулпов? Или запускать их при открытии проекта, и потом закрывать обратно?
Каждому C#-программисту, пришедшему в проект, надо объяснять что такое gulp и что его надо запустить чтобы проект заработал?
Ну и самый веселый вопрос. Как включить выходные файлы гулпа в проект студии — чтобы и в интерфейсе все нормально отображалось, и в выходной пакет при сборке они попали?
А работая над 12ю проектами, надо запускать 12 гулпов? Или запускать их при открытии проекта, и потом закрывать обратно?
Каждому C#-программисту, пришедшему в проект, надо объяснять что такое gulp и что его надо запустить чтобы проект заработал?
Ну и самый веселый вопрос. Как включить выходные файлы гулпа в проект студии — чтобы и в интерфейсе все нормально отображалось, и в выходной пакет при сборке они попали?
http://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.
Вы серьезно? Вы знаете как сейчас 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.
Разумеется, я не в курсе что там меня ожидает. Я об этом прямо написал:
Но независимо от того что там — есть куча старых проектов, которые еще пилить и пилить, и новые возможности добавить к ним было бы неплохо.
PS Что вы хотели сказать ссылкой на Process.Start?
Как в ASP.NET Core я еще не смотрел
Но независимо от того что там — есть куча старых проектов, которые еще пилить и пилить, и новые возможности добавить к ним было бы неплохо.
PS Что вы хотели сказать ссылкой на Process.Start?
Если вам надо запустить ноду — то для этого есть Process.Start. Вы так и не объяснили на кой фиг в C# и .Net поддержка ноды.
Если вам надо запустить ноду — то для этого есть Process.StartТо есть вы все-таки согласны, что запускать ноду из C# нужно?
Вы так и не объяснили на кой фиг в C# и .Net поддержка ноды.Я про поддержку ноды в C# и .Net ничего и не говорил.
Вы издеваетесь? :)
Вы можете запустить все что угодно через Process.Start. Вам не нужна никакая специальная «интеграция».
Нода участвует только в билд процессе и тут хоть батником ее запускайте, хоть из PowerShell, хоть билд процесс на ней нарисуйте и дергайте MSBuild как gulp task.
rumkin Как мне кажется имел ввиду реализацию движка JS для ноды на CLR. В этом ключе это нафиг не нужно, так как как раз есть Chakra.
Вы можете запустить все что угодно через Process.Start. Вам не нужна никакая специальная «интеграция».
Нода участвует только в билд процессе и тут хоть батником ее запускайте, хоть из PowerShell, хоть билд процесс на ней нарисуйте и дергайте MSBuild как gulp task.
rumkin Как мне кажется имел ввиду реализацию движка JS для ноды на CLR. В этом ключе это нафиг не нужно, так как как раз есть Chakra.
Ну, например, для создания приложений наподобие atom на .NET платформе.
А зачем? MS спокойно пилит на электроне свой редактор и не жужжит. Я имхо вижу единственный смысл поддержки ноды — привлечение разработчиков на pure MS платформы для развития экосистемы. Так как на сервере самому MSу Нода профита никакого не несет. И опять же поддержка Чакры никак не связана с .Net вообще.
Что значит зачем? А зачем они тогда пилят Чакру, когда есть v8 и SpiderMonkey? Зачем они .Net пилят, когда есть Qt? Может для упрощения, ускорения и удешевления разработки? А еще для того чтобы предоставить потребителям полный технологический стек? Или для того чтобы получить общую платформу для любых задач в ОС?
1. Они уже отказались от идеи сделать все самим.
2. Chakra конкурент V8 и SpiderMonkey. QT не является прямым конкурентом или заменой .Net. Это сравнение теплого с мягким. .Net это рантайм + набор библиотек и он конкурирует с JVM/Java.
3. Разработку они решили удешевлять за счет использования OpenSource :)
4. Еще раз повторюсь, нода нужна для поддержки и расширения экосистемы XBox, IoT и где-то WinServer. Ну и билды, разработка фронтэнда и тд. Больше каких-то применений на Win платформе не вижу. Еще бы VB дропнули и все силы на тюнинг CLR, новые фичи C# и кроссплатформенность.
2. Chakra конкурент V8 и SpiderMonkey. QT не является прямым конкурентом или заменой .Net. Это сравнение теплого с мягким. .Net это рантайм + набор библиотек и он конкурирует с JVM/Java.
3. Разработку они решили удешевлять за счет использования OpenSource :)
4. Еще раз повторюсь, нода нужна для поддержки и расширения экосистемы XBox, IoT и где-то WinServer. Ну и билды, разработка фронтэнда и тд. Больше каких-то применений на Win платформе не вижу. Еще бы VB дропнули и все силы на тюнинг CLR, новые фичи C# и кроссплатформенность.
UFO just landed and posted this here
В статье же написано: Microsoft предоставил ChakraShim, который по сути конвертит вызовы API V8 в вызовы Cackra. Ну и да, с учетом событий с переходом на node4 абстракция не повредит.
А что с переходом на node4? Там какие-то проблемы с нативными аддонами? Поделитесь новостями, пожалуйста.
Были проблемы. Не зря NAN появился. Бинарные модули, использовавшие api v8 напрямую (в версиях 0.10 и 0.12), были непригодны для компиляции с новой nodejs, когда она появилась. Своими руками портировал node-rsvg, например, после перевода его на NAN отпали проблемы с компиляцией на всех существующих версиях node/io.
Корпорация Microsoft признала, что Node+ChakraCore работает более эффективно, чем NOde+V8.
А до этого усердно отрицала?
Гуманитарные новости на хабре. Pull request, оказывается, «запрос на аппрув реализации» или «официальный запрос». Золотое правило в технических статьях — не знаешь термин, не переводи. Понятнее будет.
Я так понял они сделали очередной ИЕ6, в котором есть все плюшки из последнего JS и даже больше. Но, на это раз, все сделали правильно и отдали на опенсорс. Ну что сказать, молодцы, растут!
>сделали очередной ИЕ6
>в котором есть все плюшки из последнего JS
Как-то не стыкуется.
>в котором есть все плюшки из последнего JS
Как-то не стыкуется.
Судя по всему все минусующие, и вы в том числе, несколько моложе чем запуск ИЕ6 :) И просто не понимают насколько прорывным был тот браузер на момент запуска. И что на самом деле у него просто не было конкурентов. И уже спустя несколько лет он стал он стал отстой и тяжелым интерпрайзом жестко привязанным к версии ОС. перестал развиваться и блокировал переходы на новую версию. Конечно если не менять продукт несколько лет и террорить пользователей он станет для всех страшилкой, но так было далеко не всегда.
Судя по всему, вы достаточно стары чтобы не понимать концепцию опен сорса. Если популярный опен сорс проект начинает стагнировать, его можно форкнуть и делать свой. Пример — MySQL. Так что сравнение неуместно в этом случае.
Еще напомню, что на момент выхода ИЕ6 не было не Лисы не Оперы, точнее Опера-то была, но еще не престо, а поделка с отключаемой за деньги рекламой, как и Нетскайп, который кстати и умер из-за того что (внимание!) ИЕ был бесплатным.
Но у Нетскейпа была клёвая анимация при поиске))
У ИЕ тоже буква e с земным шаром анимировались :)
Не так круто) Netscape Navigator Browser Search Animation
Ну это уже сугубо личное :) www.youtube.com/watch?v=May-uFVTOO8
Sign up to leave a comment.
Microsoft отправила запрос на аппрув реализации поддержки ChakraCore в Node.js наряду с движком V8