Комментарии 26
> В заключение, я не думаю что у текущего поколения JavaScript MVC фреймворков есть много перспектив в будущем.
А LISP скоро покорит мир!
А LISP скоро покорит мир!
Om клевый. Но он еще сильно альфа, из документации только исходники, мало примеров, и пока не очень понятно как вообще правильно строить приложения на нем, да и API меняется довольно часто. Но все равно он чертовски многообещающий, и обязательно стоит на него посмотреть и поиграться.
В видео про React автор ругает Dirty Check за то что он может быть медленным, но при этом сам диффает Virtual DOM который уж точно не меньше модели по объему (а скорее больше), что как-то не вяжется, возможно я что-то не понял. И в связи с этим все тотже вопрос — как эффективно в парадигме React эффективно реализвовать «бесконечный» список из сложных объектов (диффать их представление точно дороже чем их модель, а даже этого делать не хочется).
Похоже я недостаточно внимательно читал: shouldComponentUpdate может спасти от дорогого dirty-check, но не от расходов на генерацию виртуального дерева. А подход с неизменяемыми объектами интересен.
Виртуальное дерево на то и виртуальное что не содержится в DOM, а значит не отрисовывается, нет никаких reflow/repaint и тд. Здесь известный джаваскриптер Стефанов немного работает с этой библиотекой www.phpied.com/category/react/
По
RequestAnimationFrame на хабре есть перевод.Еще нераскрытый вопрос: как это все сожительствует с уже существующей инфраструтурой: например если у меня внутри элемента гугловый график — как такое реализовать. Или даже просто мой собственный график на canvas — Virtual DOM меня не спасет.
Сейчас JavaScript движки дошли до такого уровня, когда производительность коллекций стала в 2,5 раза выше, чем в JVМ.Доказательства можно?
т.е. om быстр за счёт быстрого отслеживания изменений и обновления dom-элементов во время requestAnimationFrame?
разве нельзя так же сделать в backbone.js? модели есть, при установке значения можно выставлять флаг isChanged ну или как-то так и… всё?
Я чисто из любопытства спрашиваю: есть ли в om ещё какие-то киллер-фичи? (кроме той, что это ClojureScript ;-))
разве нельзя так же сделать в backbone.js? модели есть, при установке значения можно выставлять флаг isChanged ну или как-то так и… всё?
Я чисто из любопытства спрашиваю: есть ли в om ещё какие-то киллер-фичи? (кроме той, что это ClojureScript ;-))
Первый абзац переведен неправильно, «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 медленнее», а не быстрее как вы перевели]
Исправил, спасибо.
в пределах 2.5X от JVM
Это все еще в 2.5 раза быстрее, а должно быть 0.4x от JVM, если вы хотите оставить именно такую языковую конструкцию.
В оригинале используется именно такая конструкция «within 2.5X of the Java Virtual Machine», что переводится с сохранением смысла «в пределах 2.5X от JVM».
Как в оригинале, так и в переводе есть неоднозначность: непонятно, что понимается под мерой «performance» («производительность» — это ведь не «скорость») и как эта мера сравнивается «больше = лучше» (скорость) или «меньше = лучше» (время). Я написал Дэвиду DM в Twitter, попросил его уточнить, что понимается под этой фразой и «где бенчмарки». Посмотрим, что он ответит, когда проснётся.
Есть у меня вот такая ссылка www.50ply.com/cljs-bench/, на основе которой я могу сделать предположение, что «performance» — это «время».
Как в оригинале, так и в переводе есть неоднозначность: непонятно, что понимается под мерой «performance» («производительность» — это ведь не «скорость») и как эта мера сравнивается «больше = лучше» (скорость) или «меньше = лучше» (время). Я написал Дэвиду DM в Twitter, попросил его уточнить, что понимается под этой фразой и «где бенчмарки». Посмотрим, что он ответит, когда проснётся.
Есть у меня вот такая ссылка www.50ply.com/cljs-bench/, на основе которой я могу сделать предположение, что «performance» — это «время».
мы часто наблюдаем замедление не превышающее 2.5X по сравнению с JVM
Вот теперь верится.
Я никак не пойму, а почему сами браузеры не реализуют внутри себя такой же механизм обновления DOM'а?
НЛО прилетело и опубликовало эту надпись здесь
Статья маркетинговая, на самом деле никакого чуда в таком подходе нет. Ребята взяли не оптимизированное к подобному тесту Бэкбон приложение и наделали шумихи. Для интереса, я сравнил с фреймворком который используем Atma — разница лишь в ~50мс при создании, а всё остальное (удаление и изменения состояния) моментально. И то, этот 50мс `оверхэд` из за множества биндингов, а не из-за ДОМ рэндеринга. К тому же, если в ОМ добавлять `таски` до >2000 то лаги становятся довольно ощутимые.
del
ractivejs.org/ реализует нечто подобное — параллельный DOM, перерисовки по событиям RAF и всякую экзотику типа Promise в датабиндингах.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Будущее JavaScript MVC фреймворков