В чем преимущества ScalaFX помимо добавления синтаксического сахара для привязок?

Я пытаюсь реализовать простой организатор заметок с некоторыми функциями отображения разума с использованием JavaFX и Scala.

Я пытаюсь решить, следует ли мне вызывать код JavaFX непосредственно из Scala или через ScalaFX? Я не знаю, стоит ли изучать ScalaFX и не проще ли просто вызвать JavaFX из кода Scala?

Официальный сайт ScalaFX упоминает 4 преимущества ScalaFX:

1) Признаки привязки естественного языка

-Это приятно, но я на самом деле не планирую использовать привязки (я намерен использовать EventBus для событий меж-gui-component и несколько привязок для событий внутри gui-component).

2) Синтаксис адаптированной анимации

-Я не планирую использовать анимации в своем проекте.

3) Полнотекстовые API-интерфейсы

Это может показаться незначительным моментом... Тип безопасности - это что-то что разработчики Java всегда (и часто воспринимают как должное), и разработчики на других языках сценариев живут без (и неосознанно в результате возникают ошибки времени выполнения). Однако это критический если вы разрабатываете приложения, которые не могут иметь неожиданных ошибки времени выполнения и ошибки после развертывания.

Хороший компилятор сможет забрать многие распространенные ошибки кодирования через сравнение ожидаемых и актуальных типов и отличный компилятор (например, Scala) автоматически выведет типы для вас, чтобы у вас не было чтобы повторить их во всем коде.

ScalaFX получает лучшее из обоих миров с синтаксисом DSL, подобным сценарию где вам редко приходится явно вводить объекты, с сильным тип-безопасности компилятора Scala, который выдает и проверяет типы каждого выражения и вызова API. Это означает, что требуется меньше времени на отладку странные ошибки кода и орфографические ошибки, а также более качественный код прямо из ворота!

-Это кажется интересным! Но мой вопрос: я подозреваю, что вызов JavaFX напрямую от Scala дает мне гарантии безопасности того же типа, что и вызов JavaFX через ScalaFX, или нет? Я не знаю.

4) Полная совместимость с JavaFX/ScalaFX:

-Если я вызываю JavaFX непосредственно из Scala, тогда мне больше не нужно больше беспокоиться о проблемах взаимодействия, чем при вызове JavaFX через ScalaFX.

Вкратце:

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

Почему лучше использовать JavaFX через ScalaFX, чем непосредственно из Scala в отношении безопасности типов? Какие дополнительные преимущества в плане безопасности мы получаем, если мы используем ScalaFX вместо прямого доступа из Scala? Я спрашиваю об этом, потому что я не могу себе представить, какая дополнительная безопасность ScalaFX может дать?

Итак, другими словами, я понимаю, что ScalaFX - хороший синтаксический сахар для привязок, но он предлагает больше, чем? Должен ли я действительно использовать его, если я могу жить без (очень приятного) синтаксического сахара, который он дает?

Есть ли что-то еще, чем сахар, который бы стоил использовать этот оберточный слой (ScalaFX), который вводит дополнительную сложность (и источник ошибок)?

Обратите внимание, что я очень ценю работу создателей ScalaFX! Я только задаю эти вопросы, чтобы иметь возможность принять более обоснованное решение.

Ответ 1

ScalaFX - это DSL для работы с JavaFX. Предлагая, что вы называете "синтаксическим сахаром", это главная цель DSL.

(DSL традиционно также ограничивает область действия языка хоста целевым доменом, но обычно это нежелательно для Scala DSL.)

Теперь, как и когда это полезно, это дебаты сами по себе, но это essentailly all, которые он предлагает. Лично я всегда предпочитаю API, который позволяет мне более четко сообщать о своих намерениях моим сверстникам и моему будущему "я", но это то, что каждая команда и проект должны решать сами. Синтаксис привязки ScalaFX замечателен, потому что свойства и привязки находят свой путь во все большем количестве бэкэндов (даже без графического интерфейса JavaFX).

Причина того, что ScalaFX является безопасностью типа рекламы, я думаю, не потому, что это особая особенность самого ScalaFX, а потому, что примечательно, что с использованием такого конкретизирования, script -подобный язык, такой как ScalaFX, и использование мощность платформы Scala, по-прежнему даст вам безопасность типов (что может быть непротиворечивым для новичков и людей, незнакомых с Scala).

Я бы рекомендовал использовать ScalaFX в вашем случае, так как кажется, что вы работаете над небольшим проектом , который в основном ориентирован на пользовательский интерфейс, предоставляемый через графический интерфейс JavaFx (я полагаю, учитывая ваше описание). ScalaFX позволит вам быстро выполнять итерацию по графическому интерфейсу.

Не беспокойтесь о начальных затратах в начале, ваш прецедент вряд ли будет требовательным к производительности приложения. Если вам нужно беспокоиться о производительности, почему вы используете Scala;)?

Самый большой недостаток для ScalaFX заключается в том, что каждый тип JavaFX должен быть завернут с SFXDelegate, который является громоздким, если какой-либо тип вам не нужен, или в будущем что-то добавляется в JavaFX, и вам нужно дождаться, пока ScalaFX его обернет, прежде чем вы сможете его использовать (оба из них не являются реальными блокировщиками, хотя как, во-первых, тривиально обернуть тип JavaFX (посмотреть ScalaFX Wiki), а во-вторых, цикл выпуска JavaFX значительно медленнее, чем у ScalaFX.

Ответ 2

Говоря с чисто практической точки зрения, он гораздо более лаконичен и легко читается.

Я бы посоветовал вам убедиться в этом сами, сравнив код в Java и Scla. Это два замечательных примера:

Выдержки из книги Pro JavaFX, которые доступны как на родной Java, так и в scalaFX на github (там является ссылкой на код javafx на этой странице).
Кроме того, вы можете сравнить код JavaFX-ансамбль с параметром ScalaFX-ensemble. Опять же, вы увидите, что он менее загроможден и легче читается.

Как отметил @OJKrylow, не все JavaFX были перенесены, поэтому у него есть некоторые слабые области. Это видно в scalafx-ансамбле, где не все было перенесено на scala. Если вы планируете создавать свои собственные элементы управления, вам лучше писать их на Java, а затем создавать объект-оболочку для ScalaFX.

Но если вы пишете небольшую программу, как в вашем случае, это должно снизить сложность в теории. Однако отсутствие стандартного вводного текста означает, что вы в основном вступаете в два вышеупомянутых ресурса JavaFX и смотрите, как они переходят на ScalaFX (т.е. Вы, к сожалению, не можете по-настоящему изучить его самостоятельно). Я надеюсь, что это изменится в будущем.