Как нету тестов? jsperf или например benchmark вам в помощь. Чего нет напишите сами.
К слову почему только браузер? Есть есть еще серверная сторона.
Если появился новый инструмент под требуемую задачу и он работает быстрей чем старый костыль то он именно без которого нельзя обойтись а не велосипед.
Это с чего бы по вашей прихоти снимается удобный и производительный инструмент? Как следствие для уймы задач он подходит.
Где для той же задачи (условно теперь получается костыльно) используется массив то вот вам и места применения в каждом втором коде.
Сложность работы с кодом разных форматов (ES5 и ES6).
Вы так говорите как будто это разные языки а не расширение существующего. И вы уверены что уже не используете не ведая о том некоторый ES6 плюшки? А если таки не используете то уверены ли что хорошо делаете?
Этот скомплированный код в дальнейшем исполняется внутри движка JavaScript. Вместо того, чтобы парсить исходный код, что все-таки часто занимает длительное время (особенно на мобильных устройствах), WebAssembly может быть декодирован значительно быстрее.
Разве это не то о чем мы говорим? Возможно я ошибаюсь. Нужно оригинал почитать будет.
Внимательней прочтите. Они не учат браузер работать с C/C++. Они делают формат который быстрей парсится и по пути делают трансляторы. Клиент так и останется на JS. Условно вам делают формат в который можно собирать проект. Не нужно будет использовать минификаторы и т.п.
Разве не уже пытается? NodeJS(iojs) и т.п. под сервер, NW.js под винду, Apache Cordova под мобилки. Увы WebAssembly лишь ускоряет парсинг и уменьшает вес.
Я так понимаю что разница между JS и WebAssembly лишь в скорости парсинга. Но не понимаю чего все так ликуют ведь по сути не так много изменится. т.е. будет аля TypeScript на С# с набором абстракций типа DOM'а который как и обычный нужно компилить для браузера и в конечно счете получить тот же JS просто в более компактном виде.
Это что за невиданный зверь и с чего он в этом примере появился? + ко всему ваш «addEventLictener» меня смущает.
С удалением тоже не равносильный пример. Считать игнорирование того что выборка путая не самый хороший вариант. Если вам в конкретном случае так удобней это не значит ничего (но в данном случае я лишь повторил что писали выше).
Это конечно всеми любимый довод, но если вы такой код пишите, то наверное с вами что то не так. =)
На многих конференциях на эту тему говорят что то вроде «не пишите подобный код» с чем трудно не согласиться.
Сами идеи сравнения строки с массивом или складывание объекта с массивом весьма сомнительны.
И тут я немного в выпал в осадок.
Хоть я и не являюсь фанатом Python и даже не пишу на нем, но не назову его «бесолезным».
С Rust ситуация еще интересней… Он же даже еще не зарелизился. Да и то что есть сейчас на бета релизе уже ну никак не назвать «бесолезным».
К слову почему только браузер? Есть есть еще серверная сторона.
Если появился новый инструмент под требуемую задачу и он работает быстрей чем старый костыль то он именно без которого нельзя обойтись а не велосипед.
Где для той же задачи (условно теперь получается костыльно) используется массив то вот вам и места применения в каждом втором коде.
Вы так говорите как будто это разные языки а не расширение существующего. И вы уверены что уже не используете не ведая о том некоторый ES6 плюшки? А если таки не используете то уверены ли что хорошо делаете?
А тут пожалуй кроется главная проблема.
В этом вы все таки не совсем правы. =)
Разве это не то о чем мы говорим? Возможно я ошибаюсь. Нужно оригинал почитать будет.
т.е. по факту не даст гораздо больше.
А слона то я и не заметил.
Если где то ошибся ткните носом. =)
К слову benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=yarv
Но в целом ничего не изменилось.
Плохая практика.
Это что за невиданный зверь и с чего он в этом примере появился? + ко всему ваш «addEventLictener» меня смущает.
С удалением тоже не равносильный пример. Считать игнорирование того что выборка путая не самый хороший вариант. Если вам в конкретном случае так удобней это не значит ничего (но в данном случае я лишь повторил что писали выше).
На многих конференциях на эту тему говорят что то вроде «не пишите подобный код» с чем трудно не согласиться.
Сами идеи сравнения строки с массивом или складывание объекта с массивом весьма сомнительны.
И тут я немного в выпал в осадок.
Хоть я и не являюсь фанатом Python и даже не пишу на нем, но не назову его «бесолезным».
С Rust ситуация еще интересней… Он же даже еще не зарелизился. Да и то что есть сейчас на бета релизе уже ну никак не назвать «бесолезным».