Toni MVVM is an architecture, not a technology. You can use any technology to implement it (there are even some that use swing).
If you want the whole ui rendered in HTML 5, you need something to parse html, CSS and JavaScript. Which, despite what you say, needs a browser like rendering engine. Which brings us back to running an ide in a browser. If there was no javafx, swing or awt what would dukescript use as the rendering engine? Netbeans already has good support for web technologies, and already has the ability to run those in the browser of your choice. I see no reason for other people to add more including your dukescript, the product is open source and there is no reason not to create a module if you want to promote your own project And lastly because Dukescript is a commercial product (if you want no ads, nag screen) i would say we should not even consider it as a potential risk long term alternative to swing. There are other free alternatives and these should be considered as and when there is actually a need to do. This conversation has gone on long enough, can we please re focus on netbeans. On 15 Mar 2018 14:59, <toni.ep...@eppleton.de> wrote: > These things can happen in parallel. I for my part cannot help much with > Python or Groovy features, but I can help with the POCs to improve NB UI > and make it future proof. If for example we manage to replace JavaFX > WebView with something better, contributors like Chris Lenz will be able to > use more HTML5 features for writing their plugins and the performance of > HTML-based plugins will improve. > > Maybe some of the Swing/JavaFX developers will also try it out and realize > that developing with modern ui patterns like MVVM can dramatically speed up > development, and lead to more testable and stable code while reducing the > LOC. This would have the immediate effect of better code that needs less > maintenance. > > But we can also offer them a way to still run their ( in my opinion > horribly archaic 😊 ) Swing code. > > As a side effect we could also replace the embedded Browser for debugging > web applications with a real browser and make Web Development in NB even > more attractive. Projects like the Oracle JET support in NetBeans, but also > EE projects could directly benefit from that. > > You're right these changes are driven by longer term goals, but they will > also create huge short term improvements. > > And since there's a lot of confusion here between "web technologies" and > "web applications": I for my part don't want to run NetBeans in a Browser. > I want NetBeans to remain a traditional Desktop application, which can use > modern HTML5 UIs and is prepared for the end of Swing. > > --Toni > > > > -----Ursprüngliche Nachricht----- > Von: Wade Chandler <wadechand...@apache.org> > Gesendet: Donnerstag, 15. März 2018 14:40 > An: dev@netbeans.incubator.apache.org > Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove > JavaFXfromOracle JDK > > > > On Mar 15, 2018, at 8:54 AM, Neil C Smith <neilcsm...@apache.org> wrote: > > > > Anyway, this whole thing is going a bit in circles. We need to look at > > improving the POCs in NetBeans to be able to show where (and where > > not) this approach is viable and useful. > > > > Agreed, but I think, so IMO, those just take us off the things that will > actually have direct and immediate impacts. We can work on NB just as it > is, and work to fix the index lock issues, add new Java parsing, add better > language and feature support for some things like Groovy and Python, and > generally move ahead, even while fixing some issues in Swing/AWT, or bog > down in all this talk of web UIs which starts to make a lot of work which > in the end didn’t really move the needle because we’ll still have a desktop > IDE, but a lot of time would have been spent to just get further behind. > > Wade > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
