Сейчас я программирую на Golang, хотя с большим удовольствием делал бы это на Perl.
Чуть не заплакал же.
Берем Perl и регулярками генерим гошные иф-еррор-ы. Так им гадам.
Perl работал и работает, он достиг точки равновесия, когда в нем почти всё есть, а чего нету -- добавить сложно. Perl 6 слишком долго витал в мире грёз, пока корпы пиарили свои поделки.
Если бы выбирал сейчас, я бы вот Котлин попробовал: - нет словоблудия го/явы - настраиваемая степень ФП/ООП-шности - официальный язык самой популярной ОС
Да ради бога. Добавить всё можно. Каждый из нас описывает то, что видит вокруг. Вот у меня товарищ сетки обучает. Я инфраструктуру частенько автоматизирую.
Может и не навязывает. Только все примеры, которые я видел, написаны в стиле диалога: - Клиентский код шлет запрос на изменение и вставляет ответ, в определенное место. - Серверный обработчик запроса делает изменение и генерирует ответ с хтмл.
Люди учатся по таким примерам...
Вот пример:
Вот пользователь нажал кнопку, у него появился ряд в таблице. А когда этот ряд появится у его друга, который смотрит на ту же таблицу?
Значит нужен механизм подписки, по которому таблица обновляется. Желательно абстрактный механизм, чтобы после выхода какого-нибудь хттп/4 не нужно было всё переписывать.
А если механизм подписки у нас есть, то клиентский код, который шлет запрос на изменение, не должен получать ничего, кроме ОК.
Вот об этом я и написал. ФП -- коротко и безопасно. Но узкие места всё равно оптимизируем на императивном компилируемом языке.
---- Браузер -- замечательная штука. Только авторы стандартов и браузеров делают вид, что они в ДОМ-ике, прикручивают 100500-ю фичу к CSS. А о том, что браузер стал платформой для приложений не видят
ФП подходит, чтобы коротко и безопасно описывать правила в большой системе. А большая система состоит на 90% из таких правил. И да, на другие 10% из оптимизированного императивного кода.
В чистые ФП системы при этом я тоже не особо верю.
Парадигма html/css/js удобна для обычного сайта. А при создании веб приложения в этом разделении становится меньше смысла.
Раньше я делал сайты. Сейчас делаю приложения. Браузер тот же, а взгляд другой.
В центре приложения данные, а html-css -- просто инструмент.
Есть еще React Native, который вообще не про html.
... html, им на самом деле не является... что значит "на самом деле"? И то и другое просто способы записи, которые как-то чем-то потом интерпретируются и далее, вплоть до битов и электронов.
Кроме react-а есть куча альтернатив; preact <5K gzip-ed.
По htmx я смотрел их туториал. Мне не понравилось. Чем? Мне предложили описывать систему, как "диалог" -- действие, и в ответ на действие хтмл на подмену.
Чем сложнее система, тем больше глюков я наловлю с таким подходом, смешивающим изменения данных с отображением данных.
Если система маленькая, то сделать ее можно как угодно.
Но в какой-то момент могут возникнуть проблемы масштабирования:
система не влезает в одну железку
система не влезает в одну голову И решения у них разные.
Я скажу про вариант (2).
Итак:
Система большая, много ролей и бизнес правил, много разработчиков.
Количество пользователей системы ограничено физическими размерами бизнеса заказчика.
Система должна показывать пользователям актуальные данные в реальном времени.
Пользователь жмет кнопку, меняя в системе нечто, поэтому пересчитывается еще что-то, и это что-то сразу отображается другому пользователю в совсем другой "странице". Страниц много, кнопок еще больше, а часть авторов страниц недоступна.
Какое надежное, но совсем не оптималное решение напрашивается? А давайте рефрешить всем пользователям все по кругу.
Как рефрешить менее страшным способом? Например так:
берем данные на сервере
сравниваем с прошлым разом -- находим разницу
если есть разница шлем ее по сокету на клиента
патчим разницей данные на клиенте
меняем хтмл соответственно разнице в данных
А теперь по ролям:
Системный фулстек программист Сергей реализует схему обмена обобщенно для любых данных.
Фронтенд программист и верстальщик Саша описывает, как из данных получить хтмл, который нормально отображается.
Прикладной программист и бизнес аналитик Дима описывает как какие данные брать.
При этом: Дима, Саша и Сергей работают вместе. Дима знает 1000 бизнес правил (а Сергей и Саша -- нет). Саша знает, что в сафари нужно делать не так. Сергей знает, как сокет пинговать, какую структуру данных использовать, и чем отличается новый рантайм и кластер. Еще Саша и Сергей работают с Вовой, который знает другие 500 бизнес правил.
Почитал я про htmx...( Пост возвращает куски html-я. И прямо в описании действия мы явным образом указываем, куда его вставить. Отображения прибиты к действиям. Получается какой-то гипер-диалоговый стиль.
POST-redirect-GET был замечательным (ясным) подходом, где действие отделено от отображения. Но генерить и слать веsx HTML заново не всегда оптимально. И вот мы начали вставлять маленькие кусочки js, a потом большие. И получили неуправляемую кашу из обработчиков мутирующих dom где попало. ...Критическую массу каши)
React появился и показал, как эту js-кашу структурировать: render -- это аналог GET -- представление. Получилось оптимальней, чем полный GET страницы.
Наличие виртуального дома -- детали реализации... Vue, Solid и т. п. -- кажется примерно как React, может где-то и лучше, но не настолько, чтобы перепрыгивать...
Живу в Эстонии, с ID картой. Но считывателем карты дома пользуюсь реже раза в год. Картой пользуюсь в магазине для скидок, считыватель на кассе. Гос услуги и банки доступны со смартфоном. Софт для карты последний раз ставил на Ubuntu.
Еще можно rsync использовать, особенно при долгоживущем поде и инкрементальной сборке. Иногда удобно rsync через kubectl, хотя нагрузка на апи-сервер заметно растет.
Я взял Реакт именно потому, что он делает своё дело и ничего не навязывает. Если бы навязывал, я бы взял что-то другое.
лямбда-функций удобных нет? -- зато comperhensions есть.
... хотя на перле всё равно короче)
Типы нужны для больших приложений.
Вот вчера стартануло >30К компонент в рантайме.
На перле я бы не смог такое рефакторить совсем
Чуть не заплакал же.
Берем Perl и регулярками генерим гошные иф-еррор-ы.
Так им гадам.
Perl работал и работает, он достиг точки равновесия, когда в нем почти всё есть, а чего нету -- добавить сложно.
Perl 6 слишком долго витал в мире грёз, пока корпы пиарили свои поделки.
Если бы выбирал сейчас, я бы вот Котлин попробовал:
- нет словоблудия го/явы
- настраиваемая степень ФП/ООП-шности
- официальный язык самой популярной ОС
Да ради бога. Добавить всё можно. Каждый из нас описывает то, что видит вокруг. Вот у меня товарищ сетки обучает. Я инфраструктуру частенько автоматизирую.
Может и не навязывает. Только все примеры, которые я видел, написаны в стиле диалога:
- Клиентский код шлет запрос на изменение и вставляет ответ, в определенное место.
- Серверный обработчик запроса делает изменение и генерирует ответ с хтмл.
Люди учатся по таким примерам...
Вот пример:
Вот пользователь нажал кнопку, у него появился ряд в таблице.
А когда этот ряд появится у его друга, который смотрит на ту же таблицу?
Значит нужен механизм подписки, по которому таблица обновляется.
Желательно абстрактный механизм, чтобы после выхода какого-нибудь хттп/4
не нужно было всё переписывать.
А если механизм подписки у нас есть, то клиентский код, который шлет запрос на изменение, не должен получать ничего, кроме ОК.
Ejabberd написан на erlang, только вот либы для него, от тех же авторов на С
https://github.com/processone/ejabberd/blob/master/rebar.config
--> https://github.com/processone/mqtree
Вот об этом я и написал. ФП -- коротко и безопасно. Но узкие места всё равно оптимизируем на императивном компилируемом языке.
----
Браузер -- замечательная штука.
Только авторы стандартов и браузеров делают вид, что они в ДОМ-ике, прикручивают 100500-ю фичу к CSS. А о том, что браузер стал платформой для приложений не видят
ФП подходит, чтобы коротко и безопасно описывать правила в большой системе. А большая система состоит на 90% из таких правил. И да, на другие 10% из оптимизированного императивного кода.
В чистые ФП системы при этом я тоже не особо верю.
Парадигма html/css/js удобна для обычного сайта. А при создании веб приложения в этом разделении становится меньше смысла.
Раньше я делал сайты. Сейчас делаю приложения. Браузер тот же, а взгляд другой.
В центре приложения данные, а html-css -- просто инструмент.
Есть еще React Native, который вообще не про html.
... html, им на самом деле не является...
что значит "на самом деле"? И то и другое просто способы записи, которые как-то чем-то потом интерпретируются и далее, вплоть до битов и электронов.
Кроме react-а есть куча альтернатив; preact <5K gzip-ed.
По htmx я смотрел их туториал. Мне не понравилось. Чем?
Мне предложили описывать систему, как "диалог" -- действие, и в ответ на действие хтмл на подмену.
Чем сложнее система, тем больше глюков я наловлю с таким подходом, смешивающим изменения данных с отображением данных.
ПХП -- это только серврная часть несложных веб систем. А питон -- много чего, включаая ИИ. По мне, широкий старт лучше.
ну в некоторых скриптовых словари и масивы в совмещены
Есть объективные причины хвалить? или просто скучно на реакте стало
Попробую пофантазировать чуть с другой строны.
Если система маленькая, то сделать ее можно как угодно.
Но в какой-то момент могут возникнуть проблемы масштабирования:
система не влезает в одну железку
система не влезает в одну голову И решения у них разные.
Я скажу про вариант (2).
Итак:
Система большая, много ролей и бизнес правил, много разработчиков.
Количество пользователей системы ограничено физическими размерами бизнеса заказчика.
Система должна показывать пользователям актуальные данные в реальном времени.
Пользователь жмет кнопку, меняя в системе нечто, поэтому пересчитывается еще что-то, и это что-то сразу отображается другому пользователю в совсем другой "странице".
Страниц много, кнопок еще больше, а часть авторов страниц недоступна.
Какое надежное, но совсем не оптималное решение напрашивается?
А давайте рефрешить всем пользователям все по кругу.
Как рефрешить менее страшным способом?
Например так:
берем данные на сервере
сравниваем с прошлым разом -- находим разницу
если есть разница шлем ее по сокету на клиента
патчим разницей данные на клиенте
меняем хтмл соответственно разнице в данных
А теперь по ролям:
Системный фулстек программист Сергей реализует схему обмена обобщенно для любых данных.
Фронтенд программист и верстальщик Саша описывает, как из данных получить хтмл, который нормально отображается.
Прикладной программист и бизнес аналитик Дима описывает как какие данные брать.
При этом: Дима, Саша и Сергей работают вместе. Дима знает 1000 бизнес правил (а Сергей и Саша -- нет). Саша знает, что в сафари нужно делать не так. Сергей знает, как сокет пинговать, какую структуру данных использовать, и чем отличается новый рантайм и кластер. Еще Саша и Сергей работают с Вовой, который знает другие 500 бизнес правил.
Почитал я про htmx...(
Пост возвращает куски html-я. И прямо в описании действия мы явным образом указываем, куда его вставить. Отображения прибиты к действиям. Получается какой-то гипер-диалоговый стиль.
POST-redirect-GET был замечательным (ясным) подходом, где действие отделено от отображения.
Но генерить и слать веsx HTML заново не всегда оптимально.
И вот мы начали вставлять маленькие кусочки js, a потом большие.
И получили неуправляемую кашу из обработчиков мутирующих dom где попало.
...Критическую массу каши)
React появился и показал, как эту js-кашу структурировать:
render -- это аналог GET -- представление.
Получилось оптимальней, чем полный GET страницы.
Наличие виртуального дома -- детали реализации...
Vue, Solid и т. п. -- кажется примерно как React, может где-то и лучше, но не настолько, чтобы перепрыгивать...
Живу в Эстонии, с ID картой.
Но считывателем карты дома пользуюсь реже раза в год.
Картой пользуюсь в магазине для скидок, считыватель на кассе.
Гос услуги и банки доступны со смартфоном.
Софт для карты последний раз ставил на Ubuntu.
Еще можно rsync использовать, особенно при долгоживущем поде и инкрементальной сборке.
Иногда удобно rsync через kubectl, хотя нагрузка на апи-сервер заметно растет.
Купил бы.