• Dart для всего веба
    +1
    Никак не связанна. Oilpan вообще особо никак не связан был с Dart (хотя и существовали некоторые теоретические предположения о том, что он может облегчить интеграцию Dart и Blink в вопросах GC).

    Dart не будут интегрировать в стандартной сборке, но другие варианты какие-нибудь останутся (за исключением Dartium)?


    Не совсем понятен вопрос. Существует всего один Chrome, поэтому не ясно о каких вариантах идет речь.

    Dartium останется, потому что пока это единственный способ гарантировать быстрый edit-refresh цикл разработки.
  • Очень быстрые классы на JavaScript с красивым синтаксисом
    +1
    Конкретное значение уже зависит от CPU и т.д.

    Вот после некоторых мучений нарисовал тест демонстрирующий проблему с полиморфизмом на FF

    jsperf.com/liquidlava-class-system-performance-ff

    FF не микробенчмарке действительно очень умело избегает этой полиморфной ловушки, но это срабатывает только если бенчмарк постоянно крутится с одним и тем же объектом.

  • Очень быстрые классы на JavaScript с красивым синтаксисом
    +1
    Это решает проблему с «отложенной» инициализацией полей и, как следствие, убирает проблему нестабильной формы объекта, копирование функций решает другую проблему — если у вас есть разные классы наследники, то функция сидящая на прототипе базового класса будет видеть их всех — и как следствие будет полиморфной, даже если каждый отдельный класс наследник будет производить объекты стабильной формы. Если каждый класс наследник пользуется своей копией «базовой» функции — то каждая такая копия мономорфна.
  • Очень быстрые классы на JavaScript с красивым синтаксисом
    +1
    Если взять открыть в чистой вкладке в Хроме и выполнить сначала «Lava method call», а потом «Lava method call (2)», то должна нарисоваться такая картина. Если их выполнить в каком-то другом порядке или допусти выполнить «Lava method call» еще раз после того как «Lava method call (2)» открутится, то «Lava method call» будет такой же медленный как и «Lava method call (2)», потому что type feedback стал полиморфный.

    С FF картина интересная, все что я говорю — оно только к V8 относится. Скорее всего в этом микробенчмарке, он (совершенно правильно) понимает что полиморфизма тут быть не может. Ох, если бы только было легко посмотреть в их сгенерированный код, без пересборки jsshell из исходников.
  • Очень быстрые классы на JavaScript с красивым синтаксисом
    +1
    Он влияет только если создать больше одного объекта и у обоих дернуть метод пару раз — иначе незаметно (связанно это с тем, что inline caches проходят через PREMONOMOPRHIC state и это скрывает полиморфизм, второй объект выявляет это — потому что PREMONOMOPRHIC уже пройден и мы находимся в MONOMORPHIC). Посмотрите на Lava method call (2) в моей версии.
  • Очень быстрые классы на JavaScript с красивым синтаксисом
    +1
    Посмотрел сообщения от RubaXa, вспомнил специфику. Там сравнивалось Base.prototype.method.call(this) и __.parent.call(this), где __ указывал на method в потомке, а __.parent на метод в базовом классе, т.е. Base.prototype.method. Причем все это было год назад, до того как V8 научился распознавать f.call. Из-за этого .call не проинлайнивался, и как следствие LICM не выносил LoadFunctionPrototype из цикла. Как следствие каждая лишняя инструкция была на счету и отражалась на результате микробенчмарка. (Плюс еще во втором случае на одно разыменование меньше, все складывается)
  • Очень быстрые классы на JavaScript с красивым синтаксисом
    +6
    В вашем бенчмарке была своя специфика (я правда уже не помню какая :)). В данном конкретном случае специфика немножко другая.

    Если вам кажется, что тут я считерил — то напишите свои тесты, быстрее все равно не будет.


    Легким движением руки

    - NativeParentClass.prototype.method.apply(this);
    + NativeParentClass.prototype.method.call(this);
    


    NativeInstance.method разгоняется на Хроме в 20 раз см jsperf.com/liquidlava-class-system-performance/9

    А все почему? Потому что f.apply(this) Crankshaft не распознает. Он всегда умел f.apply(this, arguments) распознавать и недавно его научили f.call(...). Если вызов метода родителя распознается — то все проинлайнивается и различные инварианты типа LoadFunctionPrototype выносятся LICMом за пределы самого горячего цикла и, как следствие, на результат бенчмарка влияют мало (см IR цикла, красная полоса — индикатор вложенности циклов).

    Кстати, LoadFunctionPrototype похудел, он все еще больше чем одинокий mov, но меньше, чем то чудовище, которое раньше генерировалось.

    Хочется еще отметить, что замеряемый код содержит в себе один печальный антипаттерн — начальное значение this.counter экземплярам потомков приходит из прототипа, из-за этого если создать два экземпляра и дергать у них по-очереди method, то в этом самом методе возникает нездоровый полиморфизм, который может скушать на этом микробенчмарке до 50% производительности.

    В целом, наследование в JS, особенно когда у базового «класса» много детей и часть методов ими всеми разделяется, в настоящее время это performance antipattern, потому что все разделяемые методы становятся мучительно полиморфными внутри. Поэтому в коде для которго действительно важна каждая инструкция наследования стоит избегать или насильно клонировать все методы с прототипа базового класса в прототип дочернего — причем не копировать по ссылке, а именно клонировать, например, с помощью компиляции клонов через Function-конструктор.
  • Пишем быстрый и экономный код на JavaScript
    +1
    Разумеется если массив у нас изначально состоит из чисел (для других случаев тип элементов не отслеживается), то null действительно переведёт его просто в массив «чего угодно»), в этом случае a[i] = null не подходит. Надо либо сдвигать элементы, либо писать специальный маркер в несуществующие позиции (например, a[i] = 0). Конкретный подход зависит от назначения конкретного массива и причин, по которым нужно из него удалять элементы.
  • Пишем быстрый и экономный код на JavaScript
    +1
    Это хак связанный с тем, что V8 старается держать прототипы объектов в fast mode. Получается, когда вы присваиваете медленный объект (dictionary/slow mode) в f.prototype он превращается в быстрый.

    Сей хак актуален, если вы знаете, что у вас есть объект находящийся по какой-то причине в словарном режиме и вам хочется его превратить в быстрый объект.
  • Пишем быстрый и экономный код на JavaScript
    0
    Лимит про 100000 для new Array(n) стал для V8 неактуальным после codereview.chromium.org/397593008, теперь преаллокация быстрее, потому что преалоцированный массив остается быстрым. До этой правки он превращался в словарь.
  • Все способы перебора массива в JavaScript
    +1
    Я не сказал, что он будет работать быстрее. Я скорее сказал: это иллюзия, что он будет работать медленнее «потому что length в цикле больше никто не читает» — как CPU положит, так и будет работать :) У меня есть машина (с Xeonом) там у меня получилось быстрее — я это исключительно для того в пост добавил, чтобы показать, что это все замеры погоды в северном полушарии.
  • Пишем быстрый и экономный код на JavaScript
    0
    Рекомендации про удаление относится к использованию оператора delete.

    Если у вас есть объект, который вы используете как словарь (а не как объект), то кроме удаления deleteом ничего не сделаешь.

    Если же у вас именно объект — то лучше просто сделать o.p = null.

    С массивом точно также — если массив уже разреженный с кучей дырок, т.е. словарь по сути дела — то пользуйтесь delete, в противном случае либо a[i] = null или двигайте элементы вниз (тем же splice или руками)

    Все эти рекомендации не следует применять в слепую — надо просто понимать потенциальные проблемы, профилировать и решать уже после профилировки как разбираться с hotspotами.
  • Пишем быстрый и экономный код на JavaScript
    0
    это jsperf.com'овые графики, он все выражает в операциях в секунду.
  • Harmony collections NOW
    +1
    Если не будет утекать в этих кейсах, будет утекать в других. Невозможно реализовать правильную семантику WeakMap в виде shim — из сильных ссылок, слабые не соорудить.
  • Harmony collections NOW
    +1
    Заметьте я говорю про shim описанный в статье. При нативной реализации WeakMap в JS VM, конечно же, ничего ни в первом, ни во втором случае не должно утечь (если утекает — то это баг в реализации :)).

    А в shim описанном в статье утечет, потому что мы при выполнении m.set(x, y) мы по сути дела прикрепляем y сильным образом к x, там к x прикрепляется специальная структурка. По сути дела у нас произошла перестановка из Map * Key → Value мы делаем Key * Map → Value и храним значения на ключах, индексируя их мапами. Такой shim не течет в том смысле, что если ключ «помер», то мап не будет без дела удерживать значения, но до настоящей семантики он не дотягивает. Потому что если ключ не помер, то нем эта вспомогательная структурка будет вечно висеть и содержать (и удерживать) мертвые куски относящиеся к умершим мапам.
  • 10 самых распространённых ошибок при программировании на JavaScript
    0
    7. Неправильное наследование через прототипы


    Вы рекомендуете в этом разделе паттерн, которые негативно скажется на производительности, если эти объекты используются в горячих методах, поскольку он приводит к полифорфизму формы («скрытого класса») объекта в зависимотси от того имеет ли свойство значение по умолчанию или нет.
  • Comment from a drafted post.
  • Comment from a drafted post.
  • Comment from a drafted post.
  • Сборщик мусора на С++
    0
    Оба подхода гораздо старее JVM и были для LISP разработаны.

    «утрамбовка» это чаще LISP2 опубликованный в 67м, а простое копирование — это Cheney, опубликованный в 70м, т.е. позже. Cheney — это частый выбор для сборки мусора в молодом поколении.
  • Почему typeof null === 'object'?
    0
    Помеченные указатели (tagged pointers) техника старая как мир. Основывается она на том, большинство распределителей памяти и так выделяют выровненную память и указатели оказываются кратными какой-нибудь степени двойки. Делается это по разным причинам, зависящим от конкретного аллокатора, от фундаментального желания гарантировать правильное выравнивание для данных, которое CPU удовлетворит, до желания уменьшить какие-то внутренние структуры данных. glibc например гарантирует выравнивание на 8 (или даже на 16 на 64-битной системе) для памяти, т.е. младшие 3 бита указателей возвращаемых mallocом всегда 0. (другое дело, что malloc для реализации кучи в VM лучше не использовать, но это другая история). Разумеется это привносит определенную фрагментацию в кучу, но практика показывает, что она не так уж и страшна.
  • Почему typeof null === 'object'?
    +2
    Зачем же у каждого символа? У указателя на строку младшими битами были 100. А символы в строке без изменений.
  • Dart 1.1 стал на 25% быстрее, сравнялся с идиоматическим JavaScript и теперь подходит для серверов
    0
    PyPy как-то живет с этим различием. Я не большой специалист по Python, но если нативные расширения и __del__ не использовать, то особо ничего ведь заметно не должно быть.

    Он, конечно, не обязательно будет сильно медленнее, но просто будет медленнее. Основное ограничение это, конечно, однопоточность, хорошему GC неплохо бы параллелить все что можно, а еще лучше быть concurrent. Далее если у нас двигающий сборщик мусора, то неплохо бы чтобы копирование (и инициализация памяти) было реализовано наиболее быстрым образом для машины, на которой мы исполняемся (а это значит где-то может даже через xmm регистры надо изголяться память копировать). В asm.js нету паттерна, который бы распознался как «копирование памяти», значит будет циклик. Ну в заключение в сборщиках еще часто есть всякая инфраструктура написанная руками на ассемблере (e.g. write/read barriers), но да это относится к тому же разряду, что и JIT код — просто так на asm.js не переводится.

    Самое главное мне просто непонятно, зачем воротить свой собственный GC, когда GC уже есть готовый :)
  • Dart 1.1 стал на 25% быстрее, сравнялся с идиоматическим JavaScript и теперь подходит для серверов
    +1
    это когда парадигмы уже нативно вшиты


    Ну вшиты не вшиты, но должны ощущаться как граждане первого класса, не должна абстракция протекать… А в JS только копни любую ОО реализацию, сразу прототипы видны.

    Я против Дарт как инициативы по замене JS.


    А я вам и не предлагаю в своей коробке инструментов заменять JS на Dart. Я все пытаюсь вам объяснить, что Dart — это предложение для тех, кто видит в нем пользу. Но вы мне не верите, я уж не знаю, что мне такое написать, чтобы вы мне поверили, что никто не может прийти и отобрать у вас JS. Это невозможно.
  • Dart 1.1 стал на 25% быстрее, сравнялся с идиоматическим JavaScript и теперь подходит для серверов
    0
    Ну в мире вообще говоря много языков программирования. Если экосистема языка достаточна богата, то задумываться о взаимодействии с другими языками нет необходимости, лишь бы сама эта экосистема была внутри согласованна. В случае когда у нас все программируют ОО в силу своих представлений о красоте согласованность как бы отсутствует.

    С другой стороны мне интересно развитие идей Web Component, когда вы можете свое приложение собрать из инкапсулированных кусочков (Custom Elements) и вам нет необходимости задумываться о том, как они реализованы, и на каком языке, потому что они черные ящики. Но даже здесь возникают проблемы, потому что не всегда понятно что означает extend в таком случае, семантика опять оказывается привязана к языку.
  • Dart 1.1 стал на 25% быстрее, сравнялся с идиоматическим JavaScript и теперь подходит для серверов
    –1
    Подсчет ссылок это разновидность GC строго говоря. Суть в том, что низлежащая VM обычно уже имеет свой собственный сборщик мусора и достаточно эффективный (потому что он имеет доступ к голому железу и параллелизму), и выстраивая свой собственный GC мы теряем в производительности.
  • Dart 1.1 стал на 25% быстрее, сравнялся с идиоматическим JavaScript и теперь подходит для серверов
    0
    Я как бы все еще до этого понял, см. второй абзац «Есть, конечно, экспериментаторы, которые берут и целую виртуальную машину...».

    Суть в том, что это не будет транслятор Python в asm.js. Это будет виртуальная машина языка Python транслированная в asm.js со всеми вытекающими.


    тьфу, Cython. это не CPython. Прошу прощения. Ну, конечно, если взять статически типизированный язык то все работает.
  • Dart 1.1 стал на 25% быстрее, сравнялся с идиоматическим JavaScript и теперь подходит для серверов
    +1
    Да я в курсе классов в ES6 и считаю, что очень хорошо, что их ввели, boilerplate у людей из кода станет постепенно исчезать. Проблема в том, что все остальные способы эмуляции классов остались, поэтому я бы ожидал, что особые любители так и продолжат делать свое собственное.

    Более того возникает интересная ситуация когда люди могут вроде писать код на JS, потому что class выглядит похоже на то, что они где-то видели, но при этом не понимаю что происходит на самом деле, потому что внутри этот class реализован на основе прототипов. Люди будут себе ноги и руки отстреливать время от времени.
  • Dart 1.1 стал на 25% быстрее, сравнялся с идиоматическим JavaScript и теперь подходит для серверов
    +2
    stalkerg скорее всего Lars Bak имеет ввиду, я не настолько известный разработчик V8 ушедший в Dart, чтобы меня цитировать, к тому же я не согласен со словами «нереально», я считаю что в V8 есть много чего, что весьма реально улучшить и что будет улучшено.
  • Dart 1.1 стал на 25% быстрее, сравнялся с идиоматическим JavaScript и теперь подходит для серверов
    0
    (а) это не «эмуляция», а мультипарадигменность


    Я бы это назвал эмуляцией мультипарадигменности. Разницу с настоящей мультипарадигменностью почувствовать легко: там все парадигмы являются частью языка, а не состоят из спичек и изоленты. Можно допустим себя спросить: «А вот если я хочу ключевое слово super для делегации к методам предка, то через какое место мне нужно этого добиваться?», и все становится ясно.

    Осталось показать, что 90% команд фиксируют одну и ту же модель.


    Да было бы интересно включить такой вопрос в JavaScript Developers Survey. У меня есть ощущение, что большинство все-таки использует constructor+prototype.

    используют совершенно разные подходы.


    И вы считаете, что это хорошо? Мне почему-то ситуация, когда у нас есть фреймворки с несовместимыми объектными моделями кажется странной и неудобной, и не привносящей никакой пользы.

    Ни одно правило не является догмой, и не надо применять никакие правила бездумно.


    Правильно. А теперь у меня вопрос, даже два.

    1. Фиксированная ли у вас в комманде объектная модель? Или каждый объекты делает как хочет? Мне почему-то кажется, что она фиксированная, и более того у вас есть библиотечка со всякими утилитными функциями, которая позволяет вам эмулировать выбранную парадигму ОО.

    2. Почему вы эту конвенцию не стремитесь применить к JavaScript в целом. Например, кто сказал, что JS должен быть единственным языком, к которому программисты должны иметь доступ?
  • Dart 1.1 стал на 25% быстрее, сравнялся с идиоматическим JavaScript и теперь подходит для серверов
    +1
    это как-то совсем не то же самое


    У меня осталось воспоминание, что в том топике мы с вами ходили по кругу, и мы опять ходим по кругу здесь с одинаковыми аргументами и контраргументами.

    Dart в Firefox не работает — это JavaScript работает в FF


    Странная логика, JS-то вы не руками написали, он прямым образом получился из Dart программы и выполняет не что-то там случайное, а что в Dart программе было написано… Пользуясь вашей логикой можно ведь сказать, что Dart вообще нигде не работает, потому что CPU его не понимает, и это x86 (ARM, MIPS, etc) assembly, который работает на CPU.

    Browser+JS это просто такая платформа, как CLR или там CPU+OS.

    Напишите ещё «Amazon EC2 поддерживает Dart», ага.


    Хорошо, коробка на официальная Herokuвская, но это не отменяет того факта, что вы можете там хостить свой server-side Dart без какой-либо привязки, которой вы так опасаетесь.

    Есть даже стартап, который хочет предложить Dart PaaS: www.dartvoid.com/

    Т.е. вы против разнообразия? Оооок.


    Я за выразительные возможности и я против зоопарка :-) Опять же нужно понять: чем оно это разнообразие эмуляции ООП так полезно? Где здесь прибыль в виде ускорения разработки? Если 90% команд фиксируют одну и ту же модель эмуляции ООП на уровне конвенций о стиле разработки, то нет никакой пользы от разнообразия, а иногда оно просто вредит переиспользованию стороннего кода, который совсем не обязательно нормально вписывается в конвенции, установленные в вашей команде.

    где в текущем треде вы увидели «негатив»


    Для меня негатив состоит в том, что вы очевидно видите некий злой умысел за Dart, предполагаете, что кто-то хочет вам Dart «навязывать» и «привязывать». Кто-то хочет взять отключить JavaScript одной темной ночью и т.д. Это явно не нейтральные и точно не позитивные эмоции по отношению к Dart.
  • Dart 1.1 стал на 25% быстрее, сравнялся с идиоматическим JavaScript и теперь подходит для серверов
    +2
    У Mozilla есть Rust, который аналог С++ — низкоуровневый язык системного программирования. Они на нем браузер переписывают (Servo).
  • Dart 1.1 стал на 25% быстрее, сравнялся с идиоматическим JavaScript и теперь подходит для серверов
    0
    Как вы себе представляете реализацию такого плана: сегодня JavaScript работает, а завтра перестал? Мне становится смешно, это же очевидно не работоспособная идея. Такое может случится, только если JavaScript будет использоваться на 0.0000000000000000001% сайтов, а я сомневаюсь что такая ситуация когда либо возникнет. В каком-то смысле web это универсальная демократия.

    Примите Dart за то, что он есть: еще один инструмент, который хочет быть полезным и который люди находят полезным.
  • Dart 1.1 стал на 25% быстрее, сравнялся с идиоматическим JavaScript и теперь подходит для серверов
    +4
    Вы не могли бы освежить мою память и напомнить, например, предыдущие три раза, когда вы пытались от меня добиться ответа на этот вопрос.


    Вы выше ссылку давали на свой топик, в котором вы объясняли почему лично вам Dart не нужен. Мы там с вами дискутировали навязывает ли вам кто-то что-то и привязывает ли вас кто-то к чему-то, но как-то так и не пришли к пониманию.

    Оно НЕ работает ни в Firefox, ни на Heroku (только через трансляцию в JS).


    Как-то я вас не понимаю, вы в одном предложении одновременно говорите «оно не работает, но оно работает». Трансляция Dart в JS это его встроенная фича, так сказать. Он проектировался, чтобы более менее нормально транслироваться в JS и исполнятся даже в браузерах, которые его нативно не поддерживают.

    А на Heroku Dart кстати из коробки работает blog.sethladd.com/2012/08/running-dart-in-cloud-with-heroku.html

    Dart LLVM


    LL лишнее. Dart VM это Dart Virtual Machine, а LLVM это из другой оперы вообще.

    Ок, опциональная статическая типизация — так лучше?


    Да.

    Прототипное ООП — такое же ООП, как и классовое.


    Моя претензия к JS состоит не в конкретной реализации ООП, а в том, что нету единообразия. Кто как хочет, так и рисует свои иерархии. Кто-то на конструкторах+прототипах (что часто называют «прототипным ООП», но что имеет весьма косвенное отношение к настоящему прототипному ООП из, скажем, Self), кто-то Object.create, кто-то клонирует (т.е. все-таки пытается прототипное ООП изобразить) и так далее. Точно такой же зоопарк в реализации делегации и в наследовании и в способах делать mixinы.

    Большие команды обычно ставят жестокие рамки на то, как код должен писаться и тем спасаются.

    А в Dart спасаться не нужно. Есть одно нормальное ООП и всё :-)

    Ну да я вам этот аргумент, уже приводил (см. опять же свой топик), но вы его отметаете и говорите, что преимущества «неназываемы». Ну да и ладно, если вам Dart не нужен, я убеждать вас не буду, для меня главнее, чтобы разработчики, которые видят преимущества Dart для себя, могли его комфортно использовать и чтобы сомневающиеся видели достоинства и недостатки, а не просто негатив от людей, которые видят в языке (по совершенно непонятным мне причинам) какой-то злой умысел, а не желание облегчтить web разработку.
  • Dart 1.1 стал на 25% быстрее, сравнялся с идиоматическим JavaScript и теперь подходит для серверов
    +9
    Я от вас много раз пытался добиться, что же такого в Dart привязанного «к гугловой платформе», но так как-то не получается. Если оно работает нормально в Firefox и скажем лежит на Heroku, а стандартизацией языка занимается комитет в ECMA (TC-52), то где здесь привязка к чему либо?

    Далее было бы очень прикольно, если бы Mozilla разработала свою собственную Dart VM. Потому что конкуренция порождает прогресс :-)

    Я вам также уже говорил, что Dart не статически типизированный, поэтому не может подаваться под соусом «статическая типизация вместо динамической».

    Что касается нормального ООП, то это чистая правда. ООП действительно в Dart нормальное, но что главнее всего оно уже есть в языке, а не эмулируется каждым программистом в меру потребностей этого программиста и в зависимости от его предпочтений.
  • Dart 1.1 стал на 25% быстрее, сравнялся с идиоматическим JavaScript и теперь подходит для серверов
    +2
    «Окружение», а точнее использованные библиотеки, включено в тот самый единственный js файл, который вы получили на выходе из dart2js. Причем dart2js старается выкинуть все, что не используется и оставить только те фрагменты библиотеки, которые реально использовались.

    Основной дополнительный размер обычно приходит из dart:html, потому что он уж слишком причесанный по сравнению с нормальным DOM (как пример вместо NodeList везде нормальные коллекции).
  • Dart 1.1 стал на 25% быстрее, сравнялся с идиоматическим JavaScript и теперь подходит для серверов
    +5
    Транслятор Python в asm.js сделать проблематично, потому что единственное, что в asm.js удобно компилировать, это низкоуровневые статически типизированные языки типа C/C++. Нету ни поддержки сборки мусора, ни возможности положится на адаптивные оптимизации предоставляемые низлежащей виртуальной машиной. Как следствие языки типа Python или даже Dart никакой пользы от asm.js в той форме, в которой его Mozilla специфицировала сейчас, не получают.

    Есть, конечно, экспериментаторы, которые берут и целую виртуальную машину (написанную на языке типа C) компилируют в asm.js, как результат у нас получается GC, реализованный на asm.js, исполняющийся на виртуальной машине, которая имеет свой собственный более эффективный GC. Замечательно. Особые умельцы при этом могут даже реализовать для скомпилированной виртуальной машины JIT-backend, который выдает asm.js вместо машинного кода… Пример pypy.js. Правда ирония заключается в том, что согласно его последним цифрам pypy.js быстрее работает на V8, которая не поддерживает asm.js специальным образом, а не на SpiderMonkey, которая для asm.js имеет AOT-компилятор: twitter.com/rfkelly/status/409787571703529472

  • Будущее JavaScript MVC фреймворков
    0
    В оригинале используется именно такая конструкция «within 2.5X of the Java Virtual Machine», что переводится с сохранением смысла «в пределах 2.5X от JVM».

    Как в оригинале, так и в переводе есть неоднозначность: непонятно, что понимается под мерой «performance» («производительность» — это ведь не «скорость») и как эта мера сравнивается «больше = лучше» (скорость) или «меньше = лучше» (время). Я написал Дэвиду DM в Twitter, попросил его уточнить, что понимается под этой фразой и «где бенчмарки». Посмотрим, что он ответит, когда проснётся.

    Есть у меня вот такая ссылка www.50ply.com/cljs-bench/, на основе которой я могу сделать предположение, что «performance» — это «время».

    мы часто наблюдаем замедление не превышающее 2.5X по сравнению с JVM
  • Будущее JavaScript MVC фреймворков
    0
    Первый абзац переведен неправильно, «this» относится к твиту.

    We've known this for some time over here in the ClojureScript corner of the world — all of our collections are immutable and modeled directly on the original Clojure versions written in Java. Modern JavaScript engines have now been tuned to the point that it's no longer uncommon to see collection performance within 2.5X of the Java Virtual Machine.


    Нам, в нашем ClojureScript-углу, это [т.е. факт, что производительность JS совсем не плоха] было известно уже давно — все наши структуры данным неизменяемы и основаны на оригинальных коллекциях из Clojure, написанных на Java. Современные JavaScript движки в настоящее время достаточно оптимизированы и мы часто наблюдаем производительность этих коллекций в пределах 2.5X от JVM [здесь, я думаю, 2.5X означает «2.5X медленнее», а не быстрее как вы перевели]
  • Клеточные автоматы на Dart
    +1
    На github можно же выложить (хотя бы gistом), а demo на GitHub Pages.