Вместо тарантула я бы предложил рассмотреть Mnesia (или ETS для начала), которые являются частью (платформы) Erlang. Так вы получите прозрачное взаимодействие с возможностью хранения термов эрланга без дополнительных затрат на сериализацию/десериализацию.
Отличный подход! Похожий используется в книге «Быстрый английский для энергичных лентяев». Но здесь формат еще компактней) Как насчет еще одной статьи с описаниями ветвлений типа «если бы вы здесь про них написали, я бы не оставил этот комментарий» и «если вы опишите условные конструкции, думаю, многие будут благодарны»?)
Когда-то, уже много лет назад, я читал новость, что компания Palm проиграла то ли суд Microsoft, то ли не прошла проверку антимонопольной комиссии (опять же по инициативе Майкрософт) и была признана монополистом. Для устранения замечаний, компания должна была разделиться на Palm (железки под любую ОС) и PalmOne (мобильная ОС под любые железки) и «продолжить расцветать». Могу сейчас ошибаться в деталях, но если поискать, то в интернетах есть. Я тогда подумал, как красиво их «приговорили», ну и результаты в целом не заставили себя ждать. Компании перекрыли кислород и съели, а жаль в целом (как и Нокию).
Кстати, попробуйте обратить внимание на Crystal (crystal-lang.org) — компилируемый со статической типизаций и слоганом «fast as C, slick as Ruby», который подтверждается.
Мой основной язык Python, второй (был) Go. На обоих написано приличное количество работающего кода.
Я был в поиске, на что уйти для около-веб разработки (сервисы, боты, расчеты на лету) и выбрал Crystal — реально нравится. Я рассматривал и пробовал некоторые участки реализовать на Haskell, Erlang, Elixir, Scala, Kotlin, Julia, Nim, Rust, Typescript (для Node), даже Pharo смотрел.
Основная мотивация поиска языка: крайне желательная статическая типизация без боли, средние/низкие требования к ресурсам системы (собственно, поэтому не подошли по потреблению памяти и размерам JVM языки); желательно с REPL, хорошая производительность (уровня Java или лучше); желательно с поддержкой иммутабельности на уровне языка или за счет наличия удобных коллекций; конкуррентность обязательна, параллелизм не обязателен.
Могу сказать, что для меня Crystal — просто глоток свежего воздуха. Производительность разработки (код, рефакторинг, архитектурные изменения) на порядок выше чем в Go, соизмерима с Python. Когнитивная нагрузка — меньше. Язык исключительно лаконичный, он черпал вдохновение от Ruby и является полностью ОО с поддержкой нужных вещей из функционального программирования ((0..10).map{|i| puts i} — итерация по диапазону с передачей значения в блок) и очень близок (или даже ближе?) к изначальному замыслу ОО, реализованному в Smalltalk. Код компактный, типобезопасный и null-безопасный, размер бинарников без зависимостей после strip и upx для небольшого веб-сервиса 300-500КБ, для сравнения, телеграм-бот на Scala без зависимостей — 30MБ fatjar. На бенчмарках Techempower показал хорошие результаты. Есть пакетный менеджер. Изначально разрабатывался в компании, что, на мой взгляд, плюс: практическая направленность + ориентация на применение в бизнесе. Открытый и написан сам на себе. Это фронтенд для LLVM. В интернетах есть бенчмарки по сравнению производительности: все очень достойно (те же фибоначчи на уровне с C, существенно быстрее Go).
Из минусов для меня пока: версия 0.24 (типа не 1.x, но он вроде близок) и не очень сильная поддержка в IDE (есть плагин для vscode с не очень сильным автокомплитом, но это решаемо).
Попробуйте использовать PyPy вместо CPython, он с JIT компиляцией. На данный момент поддерживает Python до 3.5 включительно. (Легко) можно получить прирост в скорости до x10. Код переписывать не надо.
Я обновил (локально) TodoMVC для Mithril (ведь он на 0.2 для существующих бенчмарков) до 1.1.5 с применением описанного в статье подхода. Будет время, дооформлю и сделаю пулл реквест в основной репозиторий. Прогнал ваш тест у себя на ноуте. Вот цифры, получившиеся при создании и завершении 200 задач. Упорядочено по возрастанию (меньше — лучше):
Вариант Создание + Заврешение, мс
$mol 1151
Angular2+ 4451
TypeScript & React15 5257
Riot.js 6112
Mithril (1.1.5) 6847
Elm 7118
Vue.js 8833
AngularJS 9394
jQuery 23809
Пару нижних вариантов для сравнения оставил. Время холодного старта здесь не учитывается.
Господа, господа. Акцент основного посыла не на маленьком размере, а на компактом API и наличии в фреймоворке всего, требуемого для разработки хоть виджета, хоть SPA. То есть я говорю о целостности и простоте фреймворка. Ведь для Vue вы тоже должны подключить axios или что-нибудь другое для серверных запросов, для роутинга — официальный роутер… версии 1 или 2? А какие зависимости это ломает? То есть еще вопрос, что есть «микрофреймворк», если React без обвязок отвечает только слой представления, Vue тоже. И вот когда вы начинаете делать из этого ядра фреймворк, то неожиданно у вас (и ваших коллег) получается много фреймворков на базе, в частности, ядра React.
При этом я не призываю пересаживаться умеющих готовить React, это не за чем.
Но, к примеру, если у вас есть другие интересы кроме фронтенда и вы хотите делать современное приложение, потратив минимум времени на изучение и внедрение, да еще и с хорошим темпом разработки, то Mithril — это реально хороший инструмент.
При этом у вас получится расширяемое и поддерживаемое приложение при наличии минимальной способности декомпозировать код.
Конечно, есть риск, что при смене парадигмы придется переписывать. Но ведь переписывали с ванили на JQuery, с JQuery на Backbone, потом на Angular 1, потом, скорее всего, на React. Но на самом Реакте сколько раз вы переписывали c Реакта на Реакт? Можете не отвечать: несколько раз. Потому что FB делал рендерер ленты. И сделал его. А все остальное по ходу пьесы. Сначала Flux, потом Redux, потом новое решение — MobX. Не используйте ref. Используйте функциональные компоненты. И так далее.
Знаете, сколько раз в день я открываю документацию Mithril во время разработки? Ни разу. Столько же и StackOverflow. Потому что не за чем. Если вы понимаете JS, вы знаете Mithril. Потому что он построен на простых концепциях. У Angular 2/3/4/5 постоянно что-то не так с документацией, недавно тоже была статья о том, что люди лезут в исходники чтобы понять, что происходит и как надо делать. А это потеря времени и денег.
Кстати, Mithril тоже работает с Redux, но он работает и без него, при этом вы можете использовать те же подходы.
Я написал про Mithril, потому что верю, что такая вещь, как обработка пользовательского ввода, не должна занимать «бОльшую половину» мозга. Пусть останется место и время для чего-то большего. Peace, folks.
Вы правы, но не во всем.
С той же страницы:
«Mithril также может избежать автоматической перерисовки, если частота запрашиваемого рендеринга превышает один кадр анимации (обычно около 16 мс). Это означает, например, что при использовании быстрых событий, таких как onresize или onscroll, Mithril автоматически регулирует количество перерисовок, чтобы избежать лагов».
То есть, пусть считает когда надо, на скорость UI не повлият.
При желании вы можете отключить autoredraw c помощью
function clickHandler(e) {
// теперь redraw не запустится при вызове обработчика
e.redraw = false
}
Также он не пересчитывает VDOM для компонентов, которые в данный момент не отображаются на уровне роутера. В итоге, не так уж и много считать выходит.
Опять же, бенчмарки подтверждают скорострельность инструмента, а в Chrome Development Tools видно, что страницы не грузят процессор.
По сравнению с React, думаю, тут вопрос в том числе и в том, на что уходят циклы процессора при использовании различных дополнительных библиотек для управления состоянием.
Согласен про preact, но Mithril умеет все, что нужно «у целом», в отличие от того же preact, который копирует зону ответственности React, и будет требовать дополнительной обвязки.
Такой расклад.
А что с хранимыми процедурами? Есть возможность добавить и использовать? Не нашел ни в доке, ни в онлайн консоли
Отличный подход! Похожий используется в книге «Быстрый английский для энергичных лентяев». Но здесь формат еще компактней) Как насчет еще одной статьи с описаниями ветвлений типа «если бы вы здесь про них написали, я бы не оставил этот комментарий» и «если вы опишите условные конструкции, думаю, многие будут благодарны»?)
Кстати, попробуйте обратить внимание на Crystal (crystal-lang.org) — компилируемый со статической типизаций и слоганом «fast as C, slick as Ruby», который подтверждается.
Мой основной язык Python, второй (был) Go. На обоих написано приличное количество работающего кода.
Я был в поиске, на что уйти для около-веб разработки (сервисы, боты, расчеты на лету) и выбрал Crystal — реально нравится. Я рассматривал и пробовал некоторые участки реализовать на Haskell, Erlang, Elixir, Scala, Kotlin, Julia, Nim, Rust, Typescript (для Node), даже Pharo смотрел.
Основная мотивация поиска языка: крайне желательная статическая типизация без боли, средние/низкие требования к ресурсам системы (собственно, поэтому не подошли по потреблению памяти и размерам JVM языки); желательно с REPL, хорошая производительность (уровня Java или лучше); желательно с поддержкой иммутабельности на уровне языка или за счет наличия удобных коллекций; конкуррентность обязательна, параллелизм не обязателен.
Могу сказать, что для меня Crystal — просто глоток свежего воздуха. Производительность разработки (код, рефакторинг, архитектурные изменения) на порядок выше чем в Go, соизмерима с Python. Когнитивная нагрузка — меньше. Язык исключительно лаконичный, он черпал вдохновение от Ruby и является полностью ОО с поддержкой нужных вещей из функционального программирования ((0..10).map{|i| puts i} — итерация по диапазону с передачей значения в блок) и очень близок (или даже ближе?) к изначальному замыслу ОО, реализованному в Smalltalk. Код компактный, типобезопасный и null-безопасный, размер бинарников без зависимостей после strip и upx для небольшого веб-сервиса 300-500КБ, для сравнения, телеграм-бот на Scala без зависимостей — 30MБ fatjar. На бенчмарках Techempower показал хорошие результаты. Есть пакетный менеджер. Изначально разрабатывался в компании, что, на мой взгляд, плюс: практическая направленность + ориентация на применение в бизнесе. Открытый и написан сам на себе. Это фронтенд для LLVM. В интернетах есть бенчмарки по сравнению производительности: все очень достойно (те же фибоначчи на уровне с C, существенно быстрее Go).
Из минусов для меня пока: версия 0.24 (типа не 1.x, но он вроде близок) и не очень сильная поддержка в IDE (есть плагин для vscode с не очень сильным автокомплитом, но это решаемо).
Попробуйте, вам понравится)
А я Proto Raider ваш купил — отличная игра! Сначала даже решил, что это статья — это такая форма тизера к новой игре. Не планируете?
Попробуйте использовать PyPy вместо CPython, он с JIT компиляцией. На данный момент поддерживает Python до 3.5 включительно. (Легко) можно получить прирост в скорости до x10. Код переписывать не надо.
Я обновил (локально) TodoMVC для Mithril (ведь он на 0.2 для существующих бенчмарков) до 1.1.5 с применением описанного в статье подхода. Будет время, дооформлю и сделаю пулл реквест в основной репозиторий. Прогнал ваш тест у себя на ноуте. Вот цифры, получившиеся при создании и завершении 200 задач. Упорядочено по возрастанию (меньше — лучше):
Пару нижних вариантов для сравнения оставил. Время холодного старта здесь не учитывается.
При этом я не призываю пересаживаться умеющих готовить React, это не за чем.
Но, к примеру, если у вас есть другие интересы кроме фронтенда и вы хотите делать современное приложение, потратив минимум времени на изучение и внедрение, да еще и с хорошим темпом разработки, то Mithril — это реально хороший инструмент.
При этом у вас получится расширяемое и поддерживаемое приложение при наличии минимальной способности декомпозировать код.
Конечно, есть риск, что при смене парадигмы придется переписывать. Но ведь переписывали с ванили на JQuery, с JQuery на Backbone, потом на Angular 1, потом, скорее всего, на React. Но на самом Реакте сколько раз вы переписывали c Реакта на Реакт? Можете не отвечать: несколько раз. Потому что FB делал рендерер ленты. И сделал его. А все остальное по ходу пьесы. Сначала Flux, потом Redux, потом новое решение — MobX. Не используйте ref. Используйте функциональные компоненты. И так далее.
Знаете, сколько раз в день я открываю документацию Mithril во время разработки? Ни разу. Столько же и StackOverflow. Потому что не за чем. Если вы понимаете JS, вы знаете Mithril. Потому что он построен на простых концепциях. У Angular 2/3/4/5 постоянно что-то не так с документацией, недавно тоже была статья о том, что люди лезут в исходники чтобы понять, что происходит и как надо делать. А это потеря времени и денег.
Кстати, Mithril тоже работает с Redux, но он работает и без него, при этом вы можете использовать те же подходы.
Я написал про Mithril, потому что верю, что такая вещь, как обработка пользовательского ввода, не должна занимать «бОльшую половину» мозга. Пусть останется место и время для чего-то большего. Peace, folks.
С той же страницы:
«Mithril также может избежать автоматической перерисовки, если частота запрашиваемого рендеринга превышает один кадр анимации (обычно около 16 мс). Это означает, например, что при использовании быстрых событий, таких как onresize или onscroll, Mithril автоматически регулирует количество перерисовок, чтобы избежать лагов».
То есть, пусть считает когда надо, на скорость UI не повлият.
При желании вы можете отключить autoredraw c помощью
function clickHandler(e) {
// теперь redraw не запустится при вызове обработчика
e.redraw = false
}
Также он не пересчитывает VDOM для компонентов, которые в данный момент не отображаются на уровне роутера. В итоге, не так уж и много считать выходит.
Опять же, бенчмарки подтверждают скорострельность инструмента, а в Chrome Development Tools видно, что страницы не грузят процессор.
По сравнению с React, думаю, тут вопрос в том числе и в том, на что уходят циклы процессора при использовании различных дополнительных библиотек для управления состоянием.
Согласен про preact, но Mithril умеет все, что нужно «у целом», в отличие от того же preact, который копирует зону ответственности React, и будет требовать дополнительной обвязки.
Такой расклад.