Разработчики Chrome сообщили (http://blog.chromium.org/2016/04/es6-es7-in-browser.html) о реализации в свежих
экспериментальных сборках браузера, на базе которых будет сформирован релиз Chrome/Chromium 52, полной поддержки спецификаций ECMAScript 6 и 7. Проект V8 стал (http://v8project.blogspot.ru/2016/04/es6-es7-and-beyond.html) первым JavaScript-движком с полной поддержкой стандарта ECMAScript 6. Уровень охвата поддержки ECMAScript 6 в Firefox (https://developer.mozilla.org/es/docs/Web/JavaScript/Novedad...) оценивается (https://kangax.github.io/compat-table/es6/) в 93% , в Edge - 90%, в Safari/WebKit - 99%. Поддержка ECMAScript 7 уже реализована (https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_...) в Firefox.Спецификация ECMAScript 6 была утверждена (https://www.opennet.me/opennews/art.shtml?num=42450) в качестве стандарта летом прошлого года после шести лет разработки. C учётом интенсивности развития web-технологий решено значительно сократить время подготовки спецификаций и выпускать новый стандарт ECMAScript раз в год. Для развития ECMAScript теперь применяя метод непрерывной разработки master-спецификации, из которой раз в год выделяется обновление стандарта, включающего готовые для публикации возможности языка. В настоящее время ECMAScript 7 находится в стадии черновой спецификации, которую планируется утвердить летом нынешнего года.
<center><a href="https://3.bp.blogspot.com/-HVJ8K4-fLT8/VyMo2yICM9I/AAAAAAAAB... src="https://www.opennet.me/opennews/pics_base/0_1462125639.png&q... style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center>
В отличие от ECMAScript 6 спецификация ECMAScript 7 содержит относительно немного изменений, поэтому её удалось реализовать в браузере достаточно оперативно. Кроме устранения недоработок и внесения уточнений к прошлой версии стандарта, наиболее заметными новшествами ECMAScript 7 является оператор "** (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...)" для возведения в степень и метод Array.prototype.includes() (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...) для определения наличия элементов в массиве.
Применение непрерывной обновляемой спецификации ECMAScript упрощает реализацию поддержки стандарта в браузерах, по сути в V8 в настоящее время обеспечена поддержка master-спецификации ECMAScript, отражающей все тенденции развития стандарта, что важно с позиции доведения до пользователей исправлений, решающих определённые проблемы в утверждённых спецификациях. Например, в процессе реализации ECMAScript 6 было выявлено, что определённые в спецификации возможности RegExp расходятся с уже применяемой на практике семантикой, т.е. строгая реализация требований станарта нарушает работу большого числа уже существующих сайтов, включая все сайты использующие библиотеку XRegExp.
В соответствии с тем, что сохранение совместимости является фундаментальным принципом Web, утверждающий стандарт комитет согласился с проблемой и внёс изменения в спецификацию, но данное изменение появится только в будущей версии стандарта. Развитие стандарта синхронно с развитием возможностей в браузере позволит предотвратить возникновение таких ситуаций.
Из развиваемых перспективных технологий отмечается работа над поддержкой в Chrome (https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...), Safari (https://bugs.webkit.org/show_bug.cgi?id=148897) и <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1240072"&g... JavaScript-модулей (https://blog.whatwg.org/js-modules), определяемых тегом ‹script type="module"›.URL: http://blog.chromium.org/2016/04/es6-es7-in-browser.html
Новость: http://www.opennet.me/opennews/art.shtml?num=44355
Теперь можно писать в стиле ООП, с классами и на JS?
Типа да. Сам пока не пишу (перестраховываюсь), но надо будет вплотную попробовать.
А можно писать на typescript и компилировать это добро в js.
если использовать typescript с уже существующими библиотеками на js, то там начнут вылезать косяки с импортами, типизацией (нафига оно нужно, когда в половине случаев приходится ставить тип any?), и т.п. Единственный его плюс - это нормально сделанный intellisense, в остальном лучше babel
полностью поддерживаю
А ничего что мелкософт ?
js, он и с классами - js
да, можно, реализация классов точно такая же как и в мутулс, очень удобно.
Похоже Джава больше не нужна, раз в js классы появились и нормальное ООП
Эта дичь требует кривые браузеры!
Там давно уже нормальное ООП.
Даже более нормальное чем в других языках. (Очень радует область видимости)Да и вообще язык очень крутой. Есть:
Многопоточность (с ней даже перебор)
бд на стороне клиента (в браузере, на html5)Нет чего-то такого чего мне бы не хватало
> Да и вообще язык очень крутой. Есть:
> Многопоточность (с ней даже перебор)
> бд на стороне клиента (в браузере, на html5)И все это жутко тормозит, жрет раму как не в себе и уделывается по всем параметрам даже питоном, обмазанным кутями. А уж по количеству дыр браузеры вообще обгоняют все и вся:
https://www.cvedetails.com/top-50-products.php
1 Mac Os X Apple OS 1484
2 Firefox Mozilla Application 1364
3 Linux Kernel Linux OS 1361
4 Chrome Google Application 1251
Верным путем идете, товарищи! Так держать!
Ну всё верно же сказали выше, что Java теперь не нужна.
Прямо таки по всем параметрам?
Вот тут можно глянуть на производительность.
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
А как насчет кроссплаторменности? Мало того, что сам js кроссплатформенный, так он еще и обеспечивает кроссплатформенность огромного количества других языков и программ за счет использования в вебинтерфейсах.Зачем ты проводишь знак равенства между уязвимостями в реализациях ЯП и браузерами? Или ты не в курсе, что в браузерах хватает уязвимостей не связанных с js?
js гвозди-платформенный, если вы про nodejs то это другой сорт.
> Прямо таки по всем параметрам?
> Вот тут можно глянуть на производительность.
> http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...Правильно, зачем говорить о наличии pypy, о всяких сайтонах
http://www.cdotson.com/2014/08/nodejs-vs-python-vs-pypy-a-si.../
http://blog.kgriffs.com/2012/10/23/python-vs-node-vs-pypy.html
и том, что для числокрушилок можно и и си подключить, когда можно скромно умолчать и просто сравнить молодежный JIT с теплым ламповым интерпретером.
Хотя тот все равно умудряется в некоторых случаях уделывать ноду.> А как насчет кроссплаторменности? Мало того, что сам js кроссплатформенный, так он
> еще и обеспечивает кроссплатформенность огромного количества других языков и программ
> за счет использования в вебинтерфейсах.Кроссплатформеность в квадрате!1
А если обеспечить доступ к браузеру из кроссплатформенного гуя на кроссплатформенных qt и питоне, то вообще все будет зашибись и никто не уйдет обиженным!> Зачем ты проводишь знак равенства между уязвимостями в реализациях ЯП и браузерами?
> Или ты не в курсе, что в браузерах хватает уязвимостей не связанных с js?А никому не интересно, что там в теории можно.
На практике, реализация JS для конечного пользователя – это современный браузер.
А стоит глянуть на дыры повнимательнее, то замечаешь, что если не замешана непосредственно реализация JS, то как минимум существенно облегчает использование дыры.
Ну там heap spraying c помощью JS, да еще и попутно и совершенно бесплатно нейтрализуя современные техники защиты памяти (только совсем недавно в огнелисе появились подвижки в эту сторону)
> Правильно, зачем говорить о наличии pypy, о всяких сайтонах
> http://www.cdotson.com/2014/08/nodejs-vs-python-vs-pypy-a-si.../Уже здесь небольшое преимущество node.js над PyPy, в следующей статье, где скоректирован алгоритм, преимущество у нее уже ошеломляющее.
> http://blog.kgriffs.com/2012/10/23/python-vs-node-vs-pypy.htmlЗдесь примерно на равных с PyPy
> и том, что для числокрушилок можно и и си подключить, когда можно
> скромно умолчать и просто сравнить молодежный JIT с теплым ламповым
> интерпретером.Так это будет скорость С, а не скорость питона. Скажу по большому секрету, биндинги к Сишным либам возможны практически для всех языков.
> Хотя тот все равно умудряется в некоторых случаях уделывать ноду.
В специально подобраном бенче? Может быть, но интересна средняя производительность и она выше у V8.
> А если обеспечить доступ к браузеру из кроссплатформенного гуя на кроссплатформенных qt
> и питоне, то вообще все будет зашибись и никто не уйдет
> обиженным!Если мы говорим о практике, а не о сферических конях в вакууме, то вебинтерфейсы нынче везде, а вот QT сильно реже встречается. И это не говоря о том, что QT написан не на питоне. Настойчивое желание примазаться к достижениям С/С++ наводит на мысль о том, что питонисты сами осознают недостатки питона, но очень не хотят это признавать открыто.
> А никому не интересно, что там в теории можно.
> На практике, реализация JS для конечного пользователя – это современный браузер.node.js ты уже забыл.
> А стоит глянуть на дыры повнимательнее, то замечаешь, что если не замешана
> непосредственно реализация JS, то как минимум существенно облегчает использование дыры.ага, особенно на всяких там С/С++ либах, обрабатывающих картинки или xml. Точно, js виноват, что из картинки выполняется машинный код.
Интерпретатор python есть как под ARM, POWERPC, так и ещё на 10платформах, на которых nodejs ещё не запускали даже.
Море биндингов различных приложений именно под python.
Ну и что касается расширения, и написания модулей под питон на С, это хорошо описано, документировано.Половина тестов nodejs с Failed результатом, это показательно.. И сравнивается JIT движок с не JIT, где pypy?
Вообще, вот эти цифры более должны привлекать:
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...Уж точно, если менять платформу, то на что-то гораздо более производительное и с большими возможностями.
...то есть на плюсы :-) Во всяком случае, судя по ссылке можно и такой вывод сделать. А дальше - богатство готового кода, масса реализаций на куче архитектур, готовых специалистов и бОльшая мощь плюсов - против предположительных простоты/безопасности руста.P.S. Это я в основном к тому, что ссылочка не так однозначна, как вам кажется.
Конечно, здесь есть проблема "курицы и яйца", - не распространись он дальше, не будет кучи биндингов и новых библиотек. Но тут ребята из мозиллы работают пока неплохо и пиарят в том числе. По платформам руст пока может опираться на LLVM, а так планы на low-level, avr (вроде уже есть поддержка от энтузиастов)
Мало по малу уже есть биндинги ко всем крупным проектам, ffmpeg, opencv,...разработчики GTK помимо биндингов, помогают в написании приложений на юзер-форуме Rust..Главное что бы не превратился ещё в одни ++
>Интерпретатор python есть как под ARM, POWERPC, так и ещё на 10платформах, на которых nodejs ещё не запускали даже.В то время как JSC из WebKit работает на любой плафторме, где есть поддержка С++11
производительность замерялась, когда в браузере открыта только одна вкладка? Ахахахах
У меня в системе запущено пол сотни скомпилированных приложений и запуская пятьдесят первое, оно летает и у него не лагает интерфейс, чего не скажешь о js-скриптике в браузере с запущенной пол сотней таких же страничек.
Какой язык крутой?
RUST и Swift.
Swift если планируется разработка под мобильные приложения, MacOS.
RUST если необходимо серверное приложение, low-level приложение под IoT, и везде где ранее планировалось использовать C++:http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
>Многопоточность (с ней даже перебор)не многопоточность, а асинхронность
строго говоря, все эти "class ... extends ..." - не более чем синтаксический сахар над прототипами, и многие старые проблемы никуда не делись. Например, контекст при вызове функций теряется все так же легко. Но в целом стало лучше, да.
не "контекст теряется", а ты сам его теряешь. this следует рассматривать как неявный аргумент наряду с прочими arguments, передача/фиксация которого происходит либо синтаксически (object.method(), object::method(), ::object.method), либо средствами Reflect (method.call(object), method.apply(object), method.bind(object), Reflect API &c.)
ну это все очевидно. Непонятно другое - почему методы класса не приравняли к стрелочным функциям, и вместо этого начали городить костыли в ES7
1) Потому что явное лучше неявного. А неявен в твоем примере "автоматический" .bind(this) 2) Да и как бы ты вызвал метод для другого контекста, если он уже "забинжен" к "оригиналу"?function getThis () { return this; }
var unwantedContext = {};
var wantedContext = {};
getThis = getThis.bind(unwantedContext);
getThis() === unwantedContext; // true
getThis.apply(wantedContext) === wantedContext; // false
>>C учётом интенсивности развития web-технологий решено значительно сократить время подготовки спецификаций и выпускать новый стандарт ECMAScript раз в год.Куда мир катится???
Сколько по времени пишется нормальный крупный проект? А зная приколы гугла, о поддержке старых технологий (ненужных гуглу) можно забыть. И что, теперь раз 1-2 года все переписывать?
Я не пойму - инженеров всех повыгоняли из отрасли?
> инженеров всех повыгоняли из отрасли?Инженер экономически невыгоден по сравнению со студентом, который только 2 месяца назад начал изучать программирование и поэтому в курсе современных технологий. Через пару лет его знания безнадёжно устареют, конечно, но он к тому времени станет руководителем и писать код перестанет, а писать код будут очередные студенты, которых он наберёт.
Но ещё
> Через пару лет егопридётся уволить, т.к. на его место придут уже остепеневшие студенты. И что дальше? Он станет руководителем руководителей? Пенсионный возраст для ITшников надо бы уменьшать, а его сейчас для всех увеличивают.
Чепуха. У любого студента уходит год-два на овладение современной технологией, только после этого код начинает хотя бы работать. Поэтому получается, что как только он овладел и начал писать продукт - выкатили следующую технологию и уже поздно писать:)Благо что ничего нового не появляется уже лет 20, поэтому любой инженер бывший в отрасли, даже не веб технологий, а обычного десктопного или серверного программирования лет 10 назад может выйти из криокамеры и довольно быстро освоиться в этих ваших вебстандартах. Добавление новых методов к стандартным объектам, добавление огрызков к ООП и чуть чуть сахара, всё это делается в куда более гигантских объёмах в той же яве каждый релиз.
Новость положительная. Тем кто радуется или переживает сверх меры - просто используйте Babel
+100. К памяти, метров. Щ(название русского блюда)таю, что Хром должен иметь в движке возможность запускать Хром ОС, а дальше ну вы поняли...
Просто отключить чертов js в браузерах.
А все смеются, когда фонд СПО и проект GNU требуют, чтобы сайт был работоспособен без js.
Хром в очередной раз доказал, что является флагманом среди браузеров. Пока firefox будет возиться с servo и rust стандарт JS уйдёт далеко вперёд. И разработчикам ничего не останется кроме как перейти на движок хрома.
Это был план с самого начала.
> Хром в очередной раз доказал, что является флагманом среди браузеров. Пока firefox
> будет возиться с servo и rust стандарт JS уйдёт далеко вперёд.
> И разработчикам ничего не останется кроме как перейти на движок хрома.Анон такой забавный, вы хоть посмотрите как мало изменений у 6 по отношению к 4й версии. Там реализовывать то особо нечего. Чуть чуть добавлю тут, чуть чуть добавили там. Для разработчиком движка это полная чепуха. Если бы было иначе, проектов вроде duktape не существовало бы. Куда сложнее поспевать за wep api, и по больше будет. Но пока фокс вполне себе поспевает.
Писи-каки и спать!
>степень совместимости Chrome оценивается в 98%, Firefox в 93% , в Edge - 90%, в Safari/WebKit - 99%. Результат 98%Все поддерживают в почти полном объёме. О чём разговор? Даже виндовый браузер по умолчанию поддерживает. А это уже клиника.
Ну вы ещё новость напишите что линкс подружился с семибитными раскладками. А это будет новостью...
Клавиатура уже отображать 10битное видео?
> Все поддерживают в почти полном объёме. О чём разговор?Что с WebRTC технологиями? Хромой с лисой все еще кросплатформенно и техноглюкично несовместимы?
А с виндовым МС вообще окстилась и довольно неплохо его пилит, времена эксплорера, кажется, закончились.
