Ну а во-вторых, оно удобно, когда биндинги к тому же CSS есть. А то иначе придётся все CSS-классы и т.п. ручками в виде строк прописывать, без автокомплита

В JB весь html пилят на своих kotlin-dsl (и бекенд и фронтенд). Да и опять таки Elm хороший пример ui в коде.

JSX слышал про такое?

Слышал, но не разбирался. Вообще, я всё ещё совсем нуб в плане веба

А еще Razer есть, да и любой template движок - по сути UI с кодом. Надо просто “по умоному” их разделять (что бы вьюшка была тупая), но это не значит что для этого нужен XML.

А еще Razer есть, да и любой template движок - по сути UI с кодом. Надо просто “по умоному” их разделять (что бы вьюшка была тупая), но это не значит что для этого нужен XML.

Ну в случае Razor там тот же автокомплит, как в родном HTML

Ну в случае Razor там тот же автокомплит, как в родном HTML

И ты представляешь какой болью это далось разработчиками из MS? А как страдают JB с их Rider или VSCode (там есть вообще поддержка?)

А был бы C# норм языком для DSL (как хотя бы котлин) - всем бы жилось легче.

И ты представляешь какой болью это далось разработчиками из MS? А как страдают JB с их Rider или VSCode (там есть вообще поддержка?)

Признаться, не думал об этом ранее?

Привет.

Привет

Да, но видно, конечно что он это уже писал не первый и не второй и не третий раз

Ну, второй раз выступает.

Первый был на LambdaDays, но там плохое качество видео. :(

Признаться, не думал об этом ранее?

Посмотри таки видео, заценишь автокомплит из коробки. :)

Я часть посмотрел уже. Да, вот так круто. Но для этого ведь нужно описать структуру CSS-фреймворка на F#. На самом деле, благодаря системе типов F# такая обёртка может получиться очень удобной, намного лучше, чем чистая CSS-версия, но само написание этой обёртки — нормальный кусок работы. Фиг успеешь для всех используемых библиотек обёртки писать

Мне и самому, в начале очень пришлась по душе возможность описания интерфейса в F#-коде. В частности, понравился пример про Eto.Forms из Expert F#

Да. Ребята постарались, сделали обертку над Bulma.

Но в опенсорсе так все и работает, да? ;)

Это нормально

Это жс ,детка

Там же dotnet все грузит, сам жс немножко потребляет

Почему Js, там вон dotnet жрет

Dotnet watch?

неа

Alex Попробуй потюнить настройки Ionide.

Кстати у тебя ionide на mono или core работает?

на Core

А на mono/.net (у тебя же windows) пробовал ?

Сейчас попробую переключиться

У меня на неткоре памяти кушает больше.

И еще я отключил все линтеры и анализаторы.

Даже кодлинзы. :)

Вы же FSAC Runtime имеете ввиду?

Да.

Переключил - все хорошо стало, но это после reload window. Какое то время так посижу, посмотрим, может опять будет нагружать

Ну, у меня на net потребление памяти более-менее стабильное.

Небольшой солюшн с F# и C# проектами.

Представляю себе как бы кушало, если на работе проекты были бы написаны на F# (от 30 до ~110 в одном солюшене)

В последнее время активно начали заниматься производительностью и потреблением памяти.

Представляю себе как бы кушало, если на работе проекты были бы написаны на F# (от 30 до ~110 в одном солюшене)

Пора переходить на микросервисы ?

И так микросервисы ( Там из этого количества много инфраструктурных и общих библиотек которые сабмодулями подключаются

Кстати, вот вам фоточка про ныряние в компилятор

Тогда не только фоточка, но и видосик. https://skillsmatter.com/skillscasts/11629-a-journey-into-the-f-sharp-compiler

У него высокий порог вхождения

+. Есть такое

Я часть посмотрел уже. Да, вот так круто. Но для этого ведь нужно описать структуру CSS-фреймворка на F#. На самом деле, благодаря системе типов F# такая обёртка может получиться очень удобной, намного лучше, чем чистая CSS-версия, но само написание этой обёртки — нормальный кусок работы. Фиг успеешь для всех используемых библиотек обёртки писать

Да, так и есть, все круто пока всего хватает) Но в реальности это абстракция над реактом и бульмой, так что надо их хорошо знать, если чего-то не хватит, надо писать самому биндинги, контролы и баги репортить или самому фиксить, на что большую часть времени и уйдет. С другой стороны типизированный фронтенд - это для энтерпрайзов очень заманчиво

Да, так и есть, все круто пока всего хватает) Но в реальности это абстракция над реактом и бульмой, так что надо их хорошо знать, если чего-то не хватит, надо писать самому биндинги, контролы и баги репортить или самому фиксить, на что большую часть времени и уйдет. С другой стороны типизированный фронтенд - это для энтерпрайзов очень заманчиво

Ну, в принципе, когда уже известен перечень используемых технологий, и также известно, что они будут использоваться долго, то написание биндингов может окупиться

Коллеги, а кто-нибудь исследовал динамические операторы типа ?<- ?

Коллеги, а кто-нибудь исследовал динамические операторы типа ?<- ?

В каком смысле?

Ну в смысле есть интересный кейс, которого хочется добиться в билдере

Чтобы сериализацию описывать структурой вида Type->string option , где 'Type - подмножество сериализуемых типов в виде DU

А дальше уже делаем или чтение

Или запись

Это как больше нравится

Что-то типа {Int32 "Name"} etc

И причем здесь (?<-)?

Ну чтобы можно было имена пропертей писать

Ну ок, переопределяешь, и всё.

Хотя это не будет ругаться на компайл тайме

А хочется, чтобы ругалось

Конечно, это же динамический оператор. ?

Сарказм в целом понятен :)

Кстати, а во что у нас компилятор разворачивает геттеры и сеттеры? там по умолчнию чего-нить похожего на op_Explicit нет, случайно?

Кстати, а во что у нас компилятор разворачивает геттеры и сеттеры? там по умолчнию чего-нить похожего на op_Explicit нет, случайно?

Какие "геттеры"?

Пропертей

Или там только рефлекшн?

Спека чет молчит по этому поводу

Шта?

Не хватает контекста. :)

А че контекста

Вот есть тип с пропертей

Проперти компилируются в проперти.

Так бы и сказал - в стандартные геттеры и сеттеры

Чего-то нстроение не очень тут. Давайте жить дружно

Да вроде не ссоримся