В тему об альтернативах нативной мобильной разработке. Flutter выглядит довольно интересно https://flutter.io/
Dart 2 тоже неплохой. Особенно порадовал тулинг для Flutter в IntelliJ IDEA, ничем не уступает React Native. Есть визуальный дебаггер UI и отлично работает hot-reload.
Интересно, что Flutter использует для рендеринга Skia https://skia.org/, графический движек из Chrome. Выходит, что весь UI на Flutter полностью платформонезависим и, в отличии от React Native, нету моста между JS и нативной частью (JS там вообще нету).
Система компонентов в чем-то напонимает React (классы, метод render и локальное состояние компонента). Вместо FlexBox для лейаутов дают набор примитивных компонентов с разными свойствами поведения блоков (https://flutter.io/docs/development/ui/layout#flutters-approach-to-layout).
Экосистема компонентов конечно далека от, того, что есть в React Native, но в целом Flutter выглядит как хорошая, более надежная альтернатива для тех, кому не страшно изучать еще один язык.
Dart 2 тоже неплохой. Особенно порадовал тулинг для Flutter в IntelliJ IDEA, ничем не уступает React Native. Есть визуальный дебаггер UI и отлично работает hot-reload.
Интересно, что Flutter использует для рендеринга Skia https://skia.org/, графический движек из Chrome. Выходит, что весь UI на Flutter полностью платформонезависим и, в отличии от React Native, нету моста между JS и нативной частью (JS там вообще нету).
Система компонентов в чем-то напонимает React (классы, метод render и локальное состояние компонента). Вместо FlexBox для лейаутов дают набор примитивных компонентов с разными свойствами поведения блоков (https://flutter.io/docs/development/ui/layout#flutters-approach-to-layout).
Экосистема компонентов конечно далека от, того, что есть в React Native, но в целом Flutter выглядит как хорошая, более надежная альтернатива для тех, кому не страшно изучать еще один язык.
На днях заморочился со стектрейсами исключений в скомпилированном ClojureScript. Когда в рантайме вылетает ошибка, обычно по стектрейсу и сообщению можно практически сразу понять, что произошло. Но в случае с компилируемыми языками все не так просто.
Дело в том, что браузеры, в данном случае Chrome, даже при наличии карт кода (source maps) все равно показывают скомпилированный JS код во фреймах стектрейса. По привычке конечно это можно разобрать, но в целом не очень приятно смотреть на неизвестную простыню, которую вместо тебя писал компилятор.
Если разобраться, то становиться понятно, почему браузеры не показывают оригинальный код в стектрейсе. Любой язык не из семьи суперсетов JS скорее всего будет сильно отличаться от JavaScript, и конструкциями и семантически. Карты кода не всегда могут досконально описать соответствия между оригиналом и скомпилированным JS из-за такой разницы между языками.
Но было бы удобно показать хотя бы строку в оригинальном коде, на которую ссылается скомпилированный код через карту кода.
Дело в том, что браузеры, в данном случае Chrome, даже при наличии карт кода (source maps) все равно показывают скомпилированный JS код во фреймах стектрейса. По привычке конечно это можно разобрать, но в целом не очень приятно смотреть на неизвестную простыню, которую вместо тебя писал компилятор.
Если разобраться, то становиться понятно, почему браузеры не показывают оригинальный код в стектрейсе. Любой язык не из семьи суперсетов JS скорее всего будет сильно отличаться от JavaScript, и конструкциями и семантически. Карты кода не всегда могут досконально описать соответствия между оригиналом и скомпилированным JS из-за такой разницы между языками.
Но было бы удобно показать хотя бы строку в оригинальном коде, на которую ссылается скомпилированный код через карту кода.
За пару вечеров вышло собрать такую штуку, да еще и подключить к Figwheel.
https://github.com/roman01la/cljs-source-mapped-stack-traces
https://github.com/roman01la/cljs-source-mapped-stack-traces
Kevin Lynagh (https://twitter.com/lynaghk) написал хороший пост о том, как с помощью type inference в ClojureScript получить максимум гибкости и производительности в использовании Hiccup в компонентах на React.
Существует несколько подходов к транслированию Hiccup в React:
Интерпретация (Reagent). Дает максимальную гибкость в рантайме в ущерб производительности.
Компиляция (Hicada). Максимальная производительность в ущерб гибкости.
Компиляция + Интерпретация (Sablono). Best of both worlds. Компилирует статическую часть Hiccup в React, а остальное откладывает на интерпретацию в рантайме.
Проблема с последним подходом в том, что компилирующий макрос не настолько хорош, чтобы точно рзобрать формы на статические и динамические. Но с улучшенным type inference в последних версиях ClojureScript это распределение может быть более точным.
Это продемонстрировано в статье: https://kevinlynagh.com/notes/fast-cljs-react-templates/
Существует несколько подходов к транслированию Hiccup в React:
Интерпретация (Reagent). Дает максимальную гибкость в рантайме в ущерб производительности.
Компиляция (Hicada). Максимальная производительность в ущерб гибкости.
Компиляция + Интерпретация (Sablono). Best of both worlds. Компилирует статическую часть Hiccup в React, а остальное откладывает на интерпретацию в рантайме.
Проблема с последним подходом в том, что компилирующий макрос не настолько хорош, чтобы точно рзобрать формы на статические и динамические. Но с улучшенным type inference в последних версиях ClojureScript это распределение может быть более точным.
Это продемонстрировано в статье: https://kevinlynagh.com/notes/fast-cljs-react-templates/
Давно хотел запилить игру про слепого человека, что бы как-то передать опыт зрячим.
Трюк в том, что на экране ничего не нужно рисовать 😀. Но взаимодействие с игроком должно происходить через звук и тактильные ощущения.
Примитивные тактильные взаимодействия можно передать через паттерны вибрации телефона + звук.
Со звуком окружения интереснее. Игроку в наушниках необходимо на слух определить источник звука в пространстве. Проще говоря, нужно проигрывать звуковые эффекты в 3D. А это означает обработка звука в реальном времени.
К счастью команда Chrome сделали модуль рендеринга аудио в пространстве поверх Web Audio API https://googlechrome.github.io/omnitone/. Изменение положения игрока в пространстве можно снимать с телефона с помощью Device Orientation API и таким образом «вращать» звуковое пространство вокруг игрока.
Можно даже задействовать Device Motion API для интерпретации резких движений как взаимодействий с объектами (дверь и т.д.).
В общем обработать звук на телефоне нормально и быстро конечно не вышло 😞, но и поднимать сервер для этого тоже не хотелось.
Зато получилось подключить десктопный браузер к мобильному через WebRTC, чтобы обрабатывать все на десктопе и стримить в телефон.
Вышел такой себе «клиенсткий-бекенд», к которому могут подключаться несколько клиентов и теоретически бродить в слепую в одном мире, ориентируясь по звуку.
Трюк в том, что на экране ничего не нужно рисовать 😀. Но взаимодействие с игроком должно происходить через звук и тактильные ощущения.
Примитивные тактильные взаимодействия можно передать через паттерны вибрации телефона + звук.
Со звуком окружения интереснее. Игроку в наушниках необходимо на слух определить источник звука в пространстве. Проще говоря, нужно проигрывать звуковые эффекты в 3D. А это означает обработка звука в реальном времени.
К счастью команда Chrome сделали модуль рендеринга аудио в пространстве поверх Web Audio API https://googlechrome.github.io/omnitone/. Изменение положения игрока в пространстве можно снимать с телефона с помощью Device Orientation API и таким образом «вращать» звуковое пространство вокруг игрока.
Можно даже задействовать Device Motion API для интерпретации резких движений как взаимодействий с объектами (дверь и т.д.).
В общем обработать звук на телефоне нормально и быстро конечно не вышло 😞, но и поднимать сервер для этого тоже не хотелось.
Зато получилось подключить десктопный браузер к мобильному через WebRTC, чтобы обрабатывать все на десктопе и стримить в телефон.
Вышел такой себе «клиенсткий-бекенд», к которому могут подключаться несколько клиентов и теоретически бродить в слепую в одном мире, ориентируясь по звуку.
Модульная сборка JRE, которая появилась в JDK 9 (https://dzone.com/articles/jlink-in-java-9), дает интересные результаты.
Например запакованный uberjar с веб-сервером на кложе + минимальный JRE (только модуль java.base) весит всего 20Мб. Есть и плагин для Leiningen, который автоматизирует сборку кастомного JRE через jlink https://github.com/sunng87/lein-jlink
А при желании можно скомпилить все в нативный бинарник через GraalVM AOT для джавы http://www.graalvm.org/docs/reference-manual/aot-compilation/, но пока что он не поддерживает весь динамизм кложи, хотя уже есть удачные попытки сборки небольших проектов.
Например запакованный uberjar с веб-сервером на кложе + минимальный JRE (только модуль java.base) весит всего 20Мб. Есть и плагин для Leiningen, который автоматизирует сборку кастомного JRE через jlink https://github.com/sunng87/lein-jlink
А при желании можно скомпилить все в нативный бинарник через GraalVM AOT для джавы http://www.graalvm.org/docs/reference-manual/aot-compilation/, но пока что он не поддерживает весь динамизм кложи, хотя уже есть удачные попытки сборки небольших проектов.
DZone
Jlink in Java 9
Jlink is Java 9's new command line tool. See how you can use it to create your own lightweight, customized JRE for a module-based Java application.
Слышали про новый браузер Next? https://next.atlas.engineer/
Браузер для лисперов, даже кейбиндинги Emacs-style 😀
Полностью расширяем, встроенный REPL, все как в Emacs. Кор на Common Lisp + pluggable рендеринг (webkit, gecko и т.д.)
На macOS работает только под Mojave. Автор не знает, как собрать приложение под несколько платформ в xcode 😂
Браузер для лисперов, даже кейбиндинги Emacs-style 😀
Полностью расширяем, встроенный REPL, все как в Emacs. Кор на Common Lisp + pluggable рендеринг (webkit, gecko и т.д.)
На macOS работает только под Mojave. Автор не знает, как собрать приложение под несколько платформ в xcode 😂
Время от времени я посматриваю на возможные альтернативы Electron для разработки десктопных приложений с веб-технологиями. Как бы плохо не звучала идея встраивать браузер в десктопное приложение, все же простота и скорость разработки вместе с кроссплатформенностью побеждают.
Среди всех возможных портов WebKit выделяется WPE WebKit для embedded систем https://wpewebkit.org/ (обзорный доклад https://www.youtube.com/watch?v=klfE6m1oCkg)
Если коротко, то это WebKit из которого выбросили все лишнее, а остальное перевели на более производительные альтернативы.
Звучит интересно, но вроде бы у авторов нет цели ввести поддержку macOS и Windows. Из десктопов поддерживается только Ubuntu.
Среди всех возможных портов WebKit выделяется WPE WebKit для embedded систем https://wpewebkit.org/ (обзорный доклад https://www.youtube.com/watch?v=klfE6m1oCkg)
Если коротко, то это WebKit из которого выбросили все лишнее, а остальное перевели на более производительные альтернативы.
Звучит интересно, но вроде бы у авторов нет цели ввести поддержку macOS и Windows. Из десктопов поддерживается только Ubuntu.
В свободное время пытаюсь разобраться в разработке Android приложений на Kotlin. Сейчас делаю Android версию ClojureScript REPL Replete https://replete.surge.sh/
В целом неплохо. В чем-то тулинг лучше, чем в React Native. Но возможности интерактивной разработки, конечно, не хватает.
В приложении ClojureScript выполняется в V8, для него есть Java обертка J2V8 https://github.com/eclipsesource/J2V8/. Время старта приемлимое, учитывая, что там около 9Мб скомпилированного JS, но могло бы быть и лучше.
В V8 есть возможность сделать дамп хипа и использовать его для почти мнгновенного старта https://v8.dev/blog/custom-startup-snapshots По факту это такой себе AOT для JS. Это успешно использует Node.js ClojureScript REPL Lumo https://anmonteiro.com/2016/11/the-fastest-clojure-repl-in-the-world/
J2V8 собирает V8 без возможности сериализировать хип, поэтому движок нужно собирать самому под все версии архитектуры arm. Это та еще боль 😕
В целом неплохо. В чем-то тулинг лучше, чем в React Native. Но возможности интерактивной разработки, конечно, не хватает.
В приложении ClojureScript выполняется в V8, для него есть Java обертка J2V8 https://github.com/eclipsesource/J2V8/. Время старта приемлимое, учитывая, что там около 9Мб скомпилированного JS, но могло бы быть и лучше.
В V8 есть возможность сделать дамп хипа и использовать его для почти мнгновенного старта https://v8.dev/blog/custom-startup-snapshots По факту это такой себе AOT для JS. Это успешно использует Node.js ClojureScript REPL Lumo https://anmonteiro.com/2016/11/the-fastest-clojure-repl-in-the-world/
J2V8 собирает V8 без возможности сериализировать хип, поэтому движок нужно собирать самому под все версии архитектуры arm. Это та еще боль 😕
Заметка про Kotlin. Мне, как разработчику, который почти не работал с Java, Kotlin вполне зашел (мнение после двух недель, ага). Совсем не страшно после JS (особенно если немного смотрел на TypeScript), но после кложуры некоторые вещи приходиться делать скрипя зубами.
Кажется, что язык позиционирует себя как более «функциональная» альтернатива Java, но наследние джавы вылазит на каждом шаге. Корутины пока пригодились так же, как и core.async в кложуре (не нужен).
Самая приятная фича: если вставить код на джаве в файл с котлин, то IDE на ходу транспайлит в котлин :D
Кажется, что язык позиционирует себя как более «функциональная» альтернатива Java, но наследние джавы вылазит на каждом шаге. Корутины пока пригодились так же, как и core.async в кложуре (не нужен).
Самая приятная фича: если вставить код на джаве в файл с котлин, то IDE на ходу транспайлит в котлин :D
Вчера попробовал стримить разбор Kotlin + JS, вышло написать что-то с React. Запись вот здесь (местами проседает звук) https://www.youtube.com/watch?v=_VeFnJHrmaI&t=313s
Собрал гайд по интеграции ClojureScript/Reagent в JS/React проекты. Пока что это единственный известный мне более-менее нормальный способ внедрить cljs в кодовую базу на js. По крайней мере уже не нужно писать руками экстерны т.к. компилятор научился выводить их в 90% случаев https://github.com/roman01la/reagent-react-integration
Как оказалось есть альтернатива — shadow-cljs. Сборщик сделан специально под интеграцию с NPM, все делает сам с минимальным конфигом https://github.com/thheller/reagent-react-integration/tree/shadow-cljs
GitHub
GitHub - thheller/reagent-react-integration at shadow-cljs
Contribute to thheller/reagent-react-integration development by creating an account on GitHub.
Стрим разработка под Android на Kotlin. Доделываю cljs REPL https://youtu.be/vHXLRgbAOjQ
Пару дней назад запустили открытую бету ClojureScript REPL Replete 2.0 https://twitter.com/mfikes/status/1086743669825261569
Помимо первого релиза для Android добавили неймспейсы для работы с файловой системой (
Помимо первого релиза для Android добавили неймспейсы для работы с файловой системой (
replete.io) и сетью (replete.http).Недавно дошли руки попробовать построить нативный UI по принципу Flutter (без нативных контролов, все сделать с нуля на OpenGL).
Первая мысль была взять простую библиотеку типа NanoVG, но такие простенькие решения не предусматривают батчинг обращений к GPU, часто не умеют размечать текст и в целом не делают многих оптимизаций, которые нужны для «богатого» UI.
В общем попробовал подключить Skia (рендерер в Chrome и Flutter). Если коротко, то C++ — боль. Особенно писать к нему биндинги.
Для лайаута взял Yoga (сабсет flex box, испольузется в React Native) и в целом вышшло неплохо, примеры можно посмотреть вот здесь https://romanliutikov.com/native-ui-part-1.html
Интересная альтернатива — новый рендерер в Firefox WebRender. Пишут, что почти все идет через GPU и вроде бы как выдает заоблачный FPS. Плюс, что написан на Rust. Минус — все еще в разработке. Но уже есть пару примеров использования в продакшн в качестве бекенда для GUI библиотек.
Другой вопрос — какой выбрать скриптовый язык? Сначала подумал про лиспы (SBCL, ECL или Carp), потом вспомнил про Lua. Но в и тоге думаю забиндить рендерер под V8/Node.js, написать кастомный reconciler для React и использовать кложуру и экосистему реакта для написания UI.
Если подумать, то производительность скриптового языка не играет роли. Изменения в UI не происходят с частотой обновления экрана, нормальные анимаци никогда не контролируються из UI потока. Узкое горлышко — это рендерер и иногда биндинги. Например Chrome многие вещи делает на CPU, а React Native гоняет сериализированные данные между JS и Native. Отсюда и хреновая производительность.
В общем интересный эксперимент, посмотрим насколько у меня хватит мотивации, может сделаю пару стримов.
Первая мысль была взять простую библиотеку типа NanoVG, но такие простенькие решения не предусматривают батчинг обращений к GPU, часто не умеют размечать текст и в целом не делают многих оптимизаций, которые нужны для «богатого» UI.
В общем попробовал подключить Skia (рендерер в Chrome и Flutter). Если коротко, то C++ — боль. Особенно писать к нему биндинги.
Для лайаута взял Yoga (сабсет flex box, испольузется в React Native) и в целом вышшло неплохо, примеры можно посмотреть вот здесь https://romanliutikov.com/native-ui-part-1.html
Интересная альтернатива — новый рендерер в Firefox WebRender. Пишут, что почти все идет через GPU и вроде бы как выдает заоблачный FPS. Плюс, что написан на Rust. Минус — все еще в разработке. Но уже есть пару примеров использования в продакшн в качестве бекенда для GUI библиотек.
Другой вопрос — какой выбрать скриптовый язык? Сначала подумал про лиспы (SBCL, ECL или Carp), потом вспомнил про Lua. Но в и тоге думаю забиндить рендерер под V8/Node.js, написать кастомный reconciler для React и использовать кложуру и экосистему реакта для написания UI.
Если подумать, то производительность скриптового языка не играет роли. Изменения в UI не происходят с частотой обновления экрана, нормальные анимаци никогда не контролируються из UI потока. Узкое горлышко — это рендерер и иногда биндинги. Например Chrome многие вещи делает на CPU, а React Native гоняет сериализированные данные между JS и Native. Отсюда и хреновая производительность.
В общем интересный эксперимент, посмотрим насколько у меня хватит мотивации, может сделаю пару стримов.
Неплохая книга (free!) о дизайне интерпретаторов от создателя Dart. Описывает весь путь от текстовой программы до виртуальной машины http://www.craftinginterpreters.com
Кстати автор UglifyJS лиспер и в его блоге есть серия статей о создании интерпретатора на JS, сжато и очень доступно http://lisperator.net/pltut/
Кстати автор UglifyJS лиспер и в его блоге есть серия статей о создании интерпретатора на JS, сжато и очень доступно http://lisperator.net/pltut/
Начали публиковать доклады с недавней ClojureD. Отличный доклад интро в triple store бд (datomic, datanoscript, etc.) https://www.youtube.com/watch?v=tbVwmFBnfo4