Забыл сказать. Для того, чтоб убедиться самостоятельно, работает ли Матрешка в том или ином браузере, открой в нем эту страницу: coding.farm/matreshka/test/SpecRunner.html
Если всё зеленое, значит, работает. Если красное — дайт мне знать :)
Скоро будет на сайте с пояснениями, а список протестированных браузеров будет расширяться (например, Android 4.0 и 4.1). Вивальди и Яндекс сделаны, как и Хромиум, на движке Blink, не виду смысла их добавлять, как и дюжину других локальных форков.
Со сломанным тестом это действительно косяк (скорее мой, так как я не запуллил изменения перед пулл-риквестом, а человек каким-то хитрым способом поменял генератор данных), но как показывает практика:
1. Никого не интересует, как сделан тест, кроме очень любопытных (их единицы).
2. Под «авторитетом» я не имею в виду качество кода разработчика или внимательность к деталям. Я имею в виду упоминаемость. В данном случае, чувак собрал все фреймворки, а ссылкой на тесты пользуется море людей. Кто эти тесты на самом деле написал, никого не интересует.
Так же если посмотреть на реализацию эмбера, там они тупо сами генерируют и модифицируют данные тем способом, которым принято в эмбере, а не то что в файле ENV.js.
Если мы работаем с кастомным API, то тест вполне себе верный.
всё равно легко проверить что происходит если у кого-то внезапно какой-то невероятно крутой результат.
Для того, чтоб кто-то принял всерьез тест, разработчик теста должен обладать авторитетом или популярностью. Если «Вася Пупкин» сделает тест и разместит его у себя на сайте, я даже заглядывать в код не буду.
И всё же, все реализации должны использовать те способы модификации данных, которые приняты в тестируемой библиотеке, а не то что в ENV.js.
Если я не ошибаюсь, если рендеринг происходит после оповещения о рендеринге, то на следующей итерации скорость рендеринга предыдущей итерации будет учтена, так как DOM — штука синхронная.
Ну я, в любом случае, принимаю любую критику. Ваш коммент заставил повысить в приоритете эту фичу, позволяющую обогнать Vue в DBMON тесте (и Матрешка и Vue без track-by работают медленно, хотя первая — чуть быстрее).
Чем вам не угодил JSPerf? Почему мы можем тестировать, скажем, скорость сортировки массива, но не можем тестировать скорость библиотек, использующих DOM API, объекты которого являются, по сути, теми же JS объектами?
По поводу вашего теста: я не понимаю, что вы тестируете. Хотя бы описание добавили.
Могу ли я попросить вас сделать, по-вашему, правильный тест и скинуть мне в личку или ответом на этот комментарий? Внизу каждого бенчмарка есть ссылка «edit these tests or add even more tests to this page».
Прелесть пака в том, что вы вишете чистый CSS, хоть и не поддерживаемый браузерами сегодня. Когда эти штуки попадут в рекомендуемый стандарт, у вас уже будет набита рука.
Спасибо за пояснение. Но меня часто посещает ощущение, что стандарты пишут люди, не написавшие и 100 тысяч строк кода в области, которую они стандартизируют.
Если всё зеленое, значит, работает. Если красное — дайт мне знать :)
Скоро будет на сайте с пояснениями, а список протестированных браузеров будет расширяться (например, Android 4.0 и 4.1). Вивальди и Яндекс сделаны, как и Хромиум, на движке Blink, не виду смысла их добавлять, как и дюжину других локальных форков.
1. Никого не интересует, как сделан тест, кроме очень любопытных (их единицы).
2. Под «авторитетом» я не имею в виду качество кода разработчика или внимательность к деталям. Я имею в виду упоминаемость. В данном случае, чувак собрал все фреймворки, а ссылкой на тесты пользуется море людей. Кто эти тесты на самом деле написал, никого не интересует.
Для того, чтоб кто-то принял всерьез тест, разработчик теста должен обладать авторитетом или популярностью. Если «Вася Пупкин» сделает тест и разместит его у себя на сайте, я даже заглядывать в код не буду.По воводу тестов, согласен.
Ну можно и подождать. Мой риквест он почти сразу принял.
По поводу вашего теста: я не понимаю, что вы тестируете. Хотя бы описание добавили.