natureofcode.com/book/ — Processing с основами физики, как первый заход вряд ли подойдёт, но заинтересовать однозначно можно. Все примеры тут же реализовываются в контексте главы
Сильнейшие диктуют условия и с этим приходиться как-то жить и подстраиваться. Сейчас все начали болеть статической типизацией и es6, количество языков и их генераторов растет каждый день, все хотят привнести что-то новое в js и это здорово. Тот же Typescript стал популярен из-за своей легковесности и прозрачной кодогенерации, все соскучились по типам, Хейлсберг и его команда делает правильные вещи. Но все же есть сакральные проблемы: язык отделяется от платформы, время трансформации в «обычный» js растет, отладка кода кастрированная (привет source maps), количество подходов и норм увеличивается и с этим надо считаться. Все забыли что комфорт не только в языке, но и в скорости, и в тулчейне, и в отладке.
Я вспоминаю свои первые дни в вебе с GWT. Уж до чего тяжелая и сложная платформа, которая работала на ура, с нормальной отладкой и ide, быстрой подменой кода кроссбраузерностью. Сейчас, на мой взгляд, этим требованиям удовлетворяют только Clojurescript и Elm.
Проблема большого выбора и разроненности сильно бьёт по удобству и комфортности разработки. Я ставлю на монолитные решения поверх js, за ними сила.
Попробовал, не впечатлило. Действительно есть заход в сгенерированный модуль, но как дальше быть с этим самостоятельным островком кода, который ничего не знает о контексте, не понятно. Единственный вариант работы с библиотекой — это придерживаться чистоты функций путем прокидывания в них контекста и прочих параметров, а это уже каноническое ФП и прощайте замыкания. Тот же require придется прокидывать внутрь окружения f_context.
Для прозрачности и четкого понимания следования выполнения кода. Не вылажу из дебагера, поэтому не понимаю как работать с «невидимым» кодом при пошаговой отладке. Про производительность выше уже подметили.
Как сгенерированный налету код можно увидеть в отладчике без прописывания debugger? По факту это дополнительный постпроцессинг в в браузере после сборки coffee кода, производительность не измерялась?
А как? На выходе это просто символьная карта, которая при отладке ведет себя непредсказуемо, не связывая цепочку выполнения с оригинальным кодом. Тот же coffeescript не отладить, потому что в половине случаев я просто не могу поставить брейк поинт в нужное мне место. Плюс ко всему dev tools подвисает секунд на 30 при разбивке кода по этим самым source maps.
Вот вам еще паттерн матчинг для Coffeescript с чуть более приятным конструкциями: github.com/CRogers/pun
Автозаменяемый на лету код очень сложно дебажить и предсказать его поведение. Если уж хочется функциональщины, то есть множество вариантов вроде Clojurescript, Elm и тд — можно использовать на ура, принеся в жертву незаменимый дебаггер. И не говорите про source maps, их предельный максимум — чтение кода, вменяемую отладку на них никогда не построить.
Горячую замену React/jsx компонентов не поддерживаете? Для webpack есть react-hot-loader, позволяющий налету заменять компоненты без перезагрузки страницы:
Столько всякой всячины уже сделано для Haxe, а нормальной UI библиотеки до сих пор нету. Кросплатформенные игры писать круто, но не на столько круто, как интерфейс
Не совсем въехал в этот CRDT, расширяющий сознание туториал жизненно необходим. Интересно, возможно ли натянуть модели из Swarm на иммутабельные структуры данных, загнать состояние в одну точку и затем шарить его части по компонентам? Эту технику привнес Om, она удобна и идет в массы. Ключевой фактор — состояние не размазывается по приложению.
Самое веселое с require.js начинается в тот момент, когда хочется выйти за рамки возможного и написать свой «супер крутой плагин», который реализует в себе загрузку модулей как прослойка. В этот момент вы со сборщиком r.js один на один, потому что он не знает какие зависимости будет грузить плагин. Для этого приходится собственноручно прописывать в include все необходимые модули, что в обычном приложении можно опустить. Поэтому приходится описывать свой процесс сборки (плагины это позволяют), и вот тут начинается деление на dev/production окружение, которые живут своей жизнью и которые надо поддерживать отдельно. Browserify исключает двухфазность проекта ценой монолитной сборки, и этим можно пожертвовать ради однообразия вашего окружения, что сэкономит время и нервы при сборке. В следующих проектах никакого require.js, это для себя решил.
Кстати, есть еще Webpack как аналог для CommonJs модулей в браузере.
Вложенность элементов управления и навигации — худшее, что могло произойти с дизайном и юзабилити веб страниц. Я уже не говорю про ужасные длинные тени. Интересно то, что затеял все это гугл. Нельзя же так бездумно все копировать:
Ну, я не нашел ни одной библиотеки с такой функциональностью год назад. Может, вы нашли?
Не встречал таких.
Загрузка css лишь малый пример того, что скрыто. Скрыта сама суть независимого модуля, который тянет за собой стили, картинки, шаблоны, мета данные и т. д. Поэтому и говорю, что тот обрубок на гитхабе не интересен для использования в своих проектах. Кроме того, модули еще надо как-то собирать и компоновать с учетом дерева зависимостей для использования на продуктивной системе, и тут опять — тишь да гладь, ничего не предоставлено. Если бы выкатили все до конца, был бы успех, потому что кроме Component я не могу назвать примера библиотеки с инкапсуляцией зависимостей.
Я вспоминаю свои первые дни в вебе с GWT. Уж до чего тяжелая и сложная платформа, которая работала на ура, с нормальной отладкой и ide, быстрой подменой кода кроссбраузерностью. Сейчас, на мой взгляд, этим требованиям удовлетворяют только Clojurescript и Elm.
Проблема большого выбора и разроненности сильно бьёт по удобству и комфортности разработки. Я ставлю на монолитные решения поверх js, за ними сила.
Автозаменяемый на лету код очень сложно дебажить и предсказать его поведение. Если уж хочется функциональщины, то есть множество вариантов вроде Clojurescript, Elm и тд — можно использовать на ура, принеся в жертву незаменимый дебаггер. И не говорите про source maps, их предельный максимум — чтение кода, вменяемую отладку на них никогда не построить.
В документации есть отсылка к связке History и Binding, но без примера все равно не тяжко.
Кстати, есть еще Webpack как аналог для CommonJs модулей в браузере.
Не встречал таких.
Загрузка css лишь малый пример того, что скрыто. Скрыта сама суть независимого модуля, который тянет за собой стили, картинки, шаблоны, мета данные и т. д. Поэтому и говорю, что тот обрубок на гитхабе не интересен для использования в своих проектах. Кроме того, модули еще надо как-то собирать и компоновать с учетом дерева зависимостей для использования на продуктивной системе, и тут опять — тишь да гладь, ничего не предоставлено. Если бы выкатили все до конца, был бы успех, потому что кроме Component я не могу назвать примера библиотеки с инкапсуляцией зависимостей.