а можешь чуть больше рассказать про «эту штуку»? на неделе возможности самому поизучать, потыкать нет, хотелось бы вкратце услышать в чем ее плюсы и минусы
Electric clojure. Пишешь одну единственную программу, в рамках которой объявляешь что вот этот код будет выполняться на клиенте, а вот этот на сервере. Переменные с сервера можно получить на клиенте напрямую. Вот ты объявил переменную в блоке сервера, затем с клиента на нее ссылаешься, и работает. А ещё если значение изменилось на сервере, то клиент автоматически подхватывает их, через очень мелкий diff значения, который автоматически генерируется при изменении. Это позволяет полностью реактивные фронтенды писать, не написав единой строчки запроса на бэк, не трогая вообще никак вебсокеты и прочие штуки. Пишешь код, говоришь что вот это клиент делает, а вот эти данные берешь с функции db/get-users, и electric все решает для тебя. Фреймворки по типу React, с другой стороны, просто дают тебе рычаги чтобы легче было делать вручную запросы, легче было стримить данные вручную в коде, легче было вручную обновлять DOM и т.д. Любой JS фреймворк, следовательно, проигрывает в производительности этой штуке.
Цель electric — сжать до нуля затраты на создание веб-приложений. И пока-что сжато 90% ручного перекладывания json. Но Electric, как и Rama (которая то же самое делает с бэкенд-разработкой, упрощая ее в 100 раз) ещё на ранней стадии своей зрелости. Реальные мощные результаты, которые превосходят предыдущую парадигму уже есть, но всяких плюшек для удобства и открытых исходников ещё нет, просто сыроват продукт, несмотря на то, что им уже можно пользоваться и наслаждаться результатами. Я жду их дальнейшего развития и мониторю