Pull to refresh

Comments 5

https://lifeart.github.io/sierpinski-glimmer/ — сихронная версия подтормаживает
https://lifeart.github.io/demo-async-dom/glimmer-port/index.html — асинхронная версия даёт плавную анимацию, но так же и артефакты при первичном рендеринге и не очень шуструю реакцию на действия пользователя.

UFO just landed and posted this here

Мне кажется они в своем глиммере перемудрили с этим опкодом и уж тем более с бинарным кодом. Ради чего все это — для того чтобы уменьшить бандл? Или скорость парсинга? Мне кажется jsx версия <h1>Hello World</h1> которая скомпилируется в h('h1', null, 'Hello-world') не так уж и много занимает и парсить отдельно не нужно — скорость парсинга js достаточно быстрая в браузерах а браузеры и так ее пытаются постоянно улучшить. В общем экономия на спичках учитывая что сейчас модно использовать webpack со всяким code-splitting а не собирать все это в один большой бандл.
А если взглянуть что скрывается за этими опкодами и виртуальной машиной то там будет перестраиваемое дерево (или точнее связанный список) функций (шаблонных привязок) которые будут проверяться при перерендере шаблона, и в зависимости от значений отдельных привязок это дерево будет перестраиваться чтобы уменьшить количество проверок. Идея этой техники шаблонизации интересная потому что она явно быстрее чем virtual-dom реакта которому нужно проверять все статические части а не только выражения внутри шаблонных-привязок. Но вместо того чтобы просто реализовать эту технику шаблонизации ребята в глиммере решили намудрить и сделать не полноценные выражения (то есть нельзя в шаблоне <div>{{...}}</div> выполнить произвольное js-выражение как в реакте) и закодировать эти привязки как опкоды, то есть взять на себя роль движка js и выполнять выражения которые там доступны самостоятельно. А это естественно будет медленней потому что тот же v8 скомпилирует обращение к свойству "obj.someproperty" в один "mov [eax + 0x4343] ebx" а интерпретатору глиммера потребуется вытащить следующий опкод проверить тип и т.д — то есть выполнить в десятки если не в сотню раз больше операций.

Мне кажется jsx версия Hello World которая скомпилируется в h('h1', null, 'Hello-world') не так уж и много занимает и парсить отдельно не нужно

Почему отдельно парсить не нужно? После того как браузер скачает скомпилированный файл разве он не начнет его парсить?
Тут подразумевалось что после того как браузер распарсит javascript у нас будет только вызов функции, то есть парсить в самом фрейморке уже не нужно
Sign up to leave a comment.

Articles