Replies (24)

  • @neFormal, чем отличается "все тот же javascript" от "javascript"?
  • @cmortuorum, один человек не заметил JS в списке, поэтому дублирование и повторы голосов в двух пунктах
  • @neFormal, не унимаешься? :-)
  • @SannySanoff, голосовалка появилась в тот же день
  • @neFormal, прокомментируй тогда результаты в свете своих на эту тему соображений?
  • @SannySanoff, судя по списку голосовавших думаю, что половина из них с js работают эпизодически и не видит смысла менять.. остальные просто привыкли..
  • @neFormal, дык инерция, как и было показано. "Работает — не трогай. ". И даже инерция в мышлении, как видишь.
  • @neFormal, Erlang, Dart, Dylan, haXe
  • @OCTAGRAM, первый тут при чём?
  • @neFormal, Очень даже при чём! Все интересные штуки вовлекают в себя ожидание события, например, от XHR. И если для нативного событийного подхода требование раскрутить стек и вернуть управление кажется логичным, то от скриптового языка логично ожидать, что он скроет эту особенность реализации. А вместо этого мы имеем скриптовый язык, но всё так же должны раскручивать стек и возвращать управление.
  • @OCTAGRAM, просто эрланг — это по сути такой dsl для серверных приложений.. но я тебя понял, сферический чистый функциональный язык..
  • @neFormal, Дело не в функциональности. Дело в том, что стек раскручивать не надо, множественные микропотоки есть. Теоретически, можно написать транслятор JS->JS такой, что стек раскручивается, но изнутри не видно раскрутки стека. Всё работает на микропотоках, на сообщениях. DOM обновляется транзакционно.
  • @OCTAGRAM, имхо это уже ближе к lua
  • @OCTAGRAM, что такое дом обновляется транзакционно?
  • @SannySanoff, Сейчас, пока JavaScript работает, изменения происходят транзакционно, при возврате управления из JavaScript (а не вернуть управление он не может). Если в явном виде будут микропотоки, то и транзакции нужно будет как–то сделать явно, чтоб промежуточные результаты юзеру не отображать.
  • @OCTAGRAM, то есть еще один уровень транзакционности над жабоскриптом? но это же не позволит растянуть 1 транзакцию на 2 вызова жабоскрипта, тогда зачем?
  • @SannySanoff, Позволит. Просто нужно как–то оперировать ненастоящим DOM и только по окончании транзакции сохранять изменения. Возможно, FRP тут не помешал бы.

    Вот, кстати, и кандидаты добавляются: Flapjax, Elm, LunaScript, но они (кроме LunaScript) какие–то незрелые. Что в них не нравится, так это статичность связей.
  • @OCTAGRAM, ненастоящим домом??? так ДОМ это дофигища большая часть ээээ.... бровзера. Причем там есть бровзер-депендент штуке! Причем транзакционность эта между UI и DOM, а сам дом он синхронный, то есть ты элемент добавил, а у него уже есть куча пропертей, который бровзер туда всунул. Фантомный DOM — не бывает. Либо настолько покоцанный, шо не нужен. Как ты пришел к такому выводу что он может быть полезен? Какие юз-кейсы?
  • @SannySanoff, На уровне, на котором я работал, есть атрибуты, есть обработчики событий, дочерние узлы и всё. Ничего особо браузер–специфичного или такого, что нельзя сымитировать. Для некоторых свойств, может быть, потребуется завершить транзакцию.
  • @OCTAGRAM, вопрос был также "для чего это всё нужно вообще" ? Вот представляешь себе видеопамять и программы 90х, которые туда писали. Записал байт получил пиксель. Я воспринимаю UI таким же боком. Рисование UI (втч через ДОМ) — это всего лишь последняя стадия, отображение процессов которые происходят там, дальше, в глубине, в голове программы. Вводить в UI туда транзакции — это подобно деланию транзакций для вывода в видеопамять. Именно транзакций, а не offscreen rendering там, против которого я ничего не имею, и которое можно делать и с DOM. Для чего это надо? Дай ситуацие из жизни.
  • @SannySanoff, Не буду настаивать на своём варианте. Просто микропотоков несколько, каждый может быть занят своим делом, а другие при этом могут быть в середине своего процесса обновления.
  • @OCTAGRAM, что в javascript нельзя выполнять параллельно несколько потоков, это конечно, грустно. Но мы решили эту задачу 8) von-neumann-architecture.blogspot.com . Но для чего нужен транзакционный UI, не знаю. Доволен бровзером вполне.
  • @SannySanoff, Для того, чтобы разные части жили своей жизнью. Должен быть способ что–то фетчить, узнавать, что кто–то из другой транзакции поменял то, что было зафетчено и складировать будущие изменения. И эти изменения могут быть перекрёстными, не сконцентрированными в одном div
  • @OCTAGRAM, это ужасно. Это abuse инструмента, и мне кажется, это зря. Но каждому своё.