Future of JavaScript UI

[tonsky]

Эпически клевый пост: http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/Read more... )

Comments

[ext_1405098]

Кстати, ClojureScript сегодня уже поддерживает source maps
Если я не ошибаюсь, то поддержка source maps в браузерах очень плохая. Вроде бы вебкит не дает возможности получить стектрейс в сорс языке (только в таргет js). Я сейчас программирую на coffeescript практически без использования информации из стектрейсов.

[tonsky]

Можно дебажить, паузить и ходить по call-stack-у, видя локальные биндинги например

[ext_1405098]

Не думал, что программисты на clojure отлаживают программы таким способом.

[ext_707972]

Никит, а есть ли выигрыш от использования Кложескрипта вообще?

Пост клевый, но вот захожу на https://github.com/swannodette/om и что я вижу? Интерфейс какой-то. Реакт вроде бы клевая библиотека(правда, у меня еще не было возможности попробовать). Но если для работы с любой браузерной либой мне требуется еще дополнительно к ней поддерживать интерфейс в этот язык, это накладывает дополнительную стоимость.

Опять же, тот же mr_aleph толкает ихний Dart. Дарт может быть и не лишен своих минусов, но он по крайней мере должен быть нативным. А Кложескрипт, надо полагать, нативным никогда не будет.

[maxim]

на N2O TodoMVC занимает в 2 раза меньше: https://github.com/b0oh/todon2o/blob/master/src/index.erl

[tonsky]

напомни, он на каждый клик на сервер ходит?

[ext_707972]

Это вроде Ваадина на Эрленге, выходит?

[maxim]

Как напишешь так и будет.
В данном примере что-то на клиенте, сами операции с сервером.

[ext_1405098]

Если я не ошибаюсь, то очень популярный фреймворк AngularJS умеет батчить апдейты через dirty checking. В статье утверждается, что Om выполняет dirty checking быстро за счет иммутабельности (проверка сводится к сравнению указателей), но неясно, насколько велик выигрыш по сравнению с ангуляром. Если я не ошибаюсь (знаком с ангуляром на уровне чтения презентаций), в нем ditry checking делается один раз на одно событие, что вряд ли может очень плохо повлиять на производительность.
Я не вижу, чем подход Ома хорош для типичных приложений. В начале статьи написано, что он взят из компьютерных игр. Но в компьютерных играх все время происходит экшен, даже если его нет, то все равно отыгрывается какая-то анимация, чтобы картинка выглядела живой. В веб приложениях пользователь жмет кнопку, получает статичный контент, рассматривает его, потом опять жмет кнопку, и т. д.

[murkt]

> (знаком с ангуляром на уровне чтения презентаций), в нем ditry checking делается один раз на одно событие, что вряд ли может очень плохо повлиять на производительность.

Влияет плохо, на десктопе незаметно, но на мобилках тормозит, а ещё иногда ломается.

[ext_707972]

Честно говоря, я не понимаю, почему все в последнее время так стремятся перенести веб в мобилки. Неужели написать нативное приложение настолько уж тяжело? На практике сделать приложение с одной codebase, которое будет нормально адаптироваться и под мобилки, и под десктоп все равно не выходит.

[murkt]

Перенос веба в мобилки - это совершенно параллельная дискуссия, а у Ангуляра стопицот проблем и без этого. И когда мы делаем действительно большое приложение, тормозить начнёт и на десктопе, кмк.

[sorhed]

Чтобы нормально писать на ClojureJS, надо сначала начать нормально писать на Clojure?

[theiced]

это тот же язык щемта

[tonsky]

Попробуй :) В принципе там почти одно и то же.

[voldmar]

Ещё помнить о том, что Clojure некоторые ошибки явно показывает из-за JVM, а в ClojureScript из-за JS иногда можно нечаянно начать складывать массив и число. Но source maps спасают.

[magicprinc]

ClojureScript молодой, пользователей условно мало, поэтому оттока разочарованных ещё меньше.

На примере недовольных GWT:
http://www.guynirpaz.com/2012/04/28/gwt-is-dead/
http://polygoncell.blogspot.ru/2013/07/gwt-for-new-project-no-thanks.html

можете прокомментировать?

Убедительно уверяют, что pure javaScript only - всё остальное от лукавого...

Сам-то я Vaadin использую (server side java framework с клиентом на GWT ;-) - поэтому просто интересуюсь мнением уважаемого человека

[magicprinc]

Т.е. много отзывов в стиле "мы взяли 2 пакета чистого JS, 5 упаковок лучших js библиотек, пол-солонки Node.js и целое множество html5 всех сортов и расцветок..."

PS: несмотря на похороны GWT держится http://www.gwtproject.org/:
становится полноценным opensource проектом,
поддерживается Google, Vaadin, Sencha
речь не о нем - речь о подходе "js - ассемблер"

[tonsky]

Ну дык, GWT был с идеей «давайте притворимся, что у нас тут Java». ClojureScript как бы задизайнен как hosted язык и нигде не скрывает что работает на платформе.

Представление о JS как целевой платформе, а не языке, дает ряд плюсов, которые недоступны чувакам, пишушим напрямую js, так же как пишушим на ассемблере недоступные многие высокоуровневые оптимизации. Все, что они могут - микрооптимизировать свои пути, как муравьи, локально.

http://stuartsierra.com/2012/06/16/why-im-using-clojurescript
http://blog.getprismatic.com/blog/2013/1/22/the-magic-of-macros-lighting-fast-templating-in-clojurescript

[ext_1405098]

А чем

(defn example [datum]
[:li [:a {:href (str "#show/" (:key datum))}
[:div.class1.class2 {:id (str "item" (:key datum))}
[:span.anchor (:name datum)]]]])

Лучше

"""

#{datum.name}

"""

с последующим innerHtml. Это, если я не ошибаюсь, даже быстрее будет.