search

sialcasa / mvvmFX

an Application Framework for implementing the MVVM Pattern with JavaFX
Apache License 2.0
495 stars 104 forks source link

Are there any plans to implement mvvmFX on TypeScript? #586

Closed pavel-castornii closed 5 years ago

pavel-castornii commented 5 years ago

I am doing a simplified JavaFX for web, based on HTML elements on TypeScript (see script4j). I've already implemented properties/collections and now doing nodes. The idea is to use the same API both for web and JavaFX application. Are there any plans to implement mvvmFx on TypeScript?

manuel-mauky commented 5 years ago

I have no plans to reimplement mvvmFX for the Web. There are several libraries to do MVVM in the browser like knockout.js (I haven't worked with it so I can tell if its good). When I'm doing web development I prefer Redux over other patterns and therefore for me personally there is no need for an MVVM in the browser. It would be interesting to see how it works but I won't spend time on doing this. However, feel free to use and adopt the mvvmFX code if you like.

pavel-castornii commented 5 years ago

@lestard It is sad to hear. However, I want to underline that the main idea is not MVVM, but JavaFX API + MVVM.

JavaFX API is very mature from one side and from another side if JavaFX (+MVVM) is used for not web (desktop) applications it is very convenient to use the same API and the same design pattern. Just to have an idea what it will be like, take a look at this file.

The code works and you can test it in browser (how to build the code is here).

manuel-mauky commented 5 years ago

I hope I'm not offending you but in my oppinion, the JavaFX API is not that good. It's OK and you can build apps with it but there are definitely better options available (at least in the browser). I personally like the declarative API of React.js a lot more. When I develop web applications I prefer a functional/declarative API like the one of React over an imperative API like JavaFX.

Don't get me wrong: I'm actively using JavaFX (and mvvmFX) in actual customer projects and it works good. If JavaFX is set, I will always use mvvmFX as support library. But that doesn't mean that it's the best approach overall. It's the best approach when you have to use an API like the one from JavaFX (properties, bi-directional binding). But on the web there is a totally different situation. On the web we have a declarative API like react. Why would I use an imperative API like JavaFX then? For me personally, this would feel like a downgrade.

I don't claim to know the "real truth" and maybe I'm wrong. It's just my personal oppinion but I hope it clarifies why I won't spent my (free-)time on this. Anyway, I wish you good luck for your project as I'm always eager to be proven wrong.

pavel-castornii commented 5 years ago

@lestard Thank you for such detailed explanation. I understand you. I don`t agree, but I understand.

The main reason, why I don't agree are the extra problems when different API/libraries/patterns etc are used for building UI both for web and native applications. Developers should remember the difference, study different libraries, spend extra time for debugging, modify business services to support different GUI etc. I don't like such things.

There are three main GUI libraries for Java - AWT/Swing/JavaFX. JavaFX is todays choice if we develop native desktop application. And not only todays but also of the far future, taking into consideration how much time was spent on it and is spent on it. So, if we build GUI on Java, we use JavaFX, and it is really good to use the same API for web.

I close this issue for now, if someone is interested the links are above.