Hey Jaroslav and all others, thx for your explanation. I think you didn’t get everything wrong, maybe more promotion but this is PR part 😉. There are big players out there. And why I love electron? Because it is fucking HTML, CSS and JS AND for the Backend too. This eco system was build for fullstack developers, who wants to create desktop applications with HTML/CSS/JS still in the background.
You know my example NbScratchFile, this is I think one of the best solution to promote a plugin for NetBeans, which was written in HTML, SCSS/CSS, TS/JS with a Framework called Knockout, a buildsystem with webpack and a communication with Java in the backend. Why I’ve chosen it? Because I wanted to write a plugin for NetBeans but w/o swing. The Mantisse editor is cool but far away from perfect, I created a ticket for a big problem to align checkboxes with labels pixel perfect, inside the Editor: https://netbeans.org/bugzilla/show_bug.cgi?id=257519 Why I’m not writing the controls in Java? Sry but no, we have Qt, we have WPF (C# with XAML) and we have WYSIWYG editors to create UIs quick and fast and sometimes dirty. In HTML I don’t need such editor. It is my daily business, I have chrome with the powerful and best DevTools ever to see my progress immediately and I’m fast w/o having an editor. So I decided to give DukeScript and the archetype a try, but there are some problems with the project type: 1. It is still not fast while bootstrapping the UI when you call your UI inside a component, we talked about that, that there Needs an improvement that this bootstrapping has to be done while IDE start or wherever. As soon as possible. Of course my plugin has the same problem and I have to change it and it is not the problem of DukeScript but there needs to be done sooner. Sometimes it seems that the DukeScript stuff was a prototype to say: hey look this can be done with HTML AND Java, but it feels unfinished. 2. The Project is so coupled with each other, I can’t use the HTML5 project features of NetBeans for that. It is still maven or Java with a piece of HTML inside. I can’t use the tasks for a HTML5 project, because it is not a HTML5 project. I can’t install npm, I can’t use scss etc from the IDE. This is why I created it by my own. You can see everything here: https://github.com/Chris2011/NbScratchFile/tree/master/src/main. I created a HTML5 project and copied the dist folder (Built with webpack, the outcome) over to the maven project to open the project again separately to build my UI, indepedent from the maven stuff. This should be a possible template to creating a HTML UI with the backend Java to creating a NetBeans plugin. Because everything is decoupled. It has the build process within the plugin for the UI and build process for the Java backend. 3. The WebView, which renders the UI, is, AFAIK not WebKit. Why WebKit? Because of the DevTools of Chrome. That tools are the best I’ve ever seen and yes, I can say I have seen a lot in my career. I started with IE, they were good, in the first 2000s. I worked with FF with the beloved Firebug, I switched to Chrome, because the DevTools are awesome. Sure the FF tools are also great, I tested them too, but I missed a lot of features there. Anyway, for that WebView, that HTML4J uses, I can only add firebug lite, which is pretty old, obsoleted, dead, etc. So for this, we need a better solution. 4. I had some trouble with the magic generated code, that HTML4J creates in the background for i.e. knockout (I don’t have any control about that). I split some classes to decouple my logic and the build breaks because of the magic that happens in the background. Sure I had to create tickets for that, but I was frustrated, that I tried to create my own UI with WebView from the JavaFX to call it and bind the ViewModel from JS to Java and vice versa, as you already know, maybe Jaroslav. 5. Again, I’m still a frontend developer, fullstack now, because I have to use Spring and Java, but anyway. I love JS and TS, I don’t know which limitations other means, but don’t compare GWT or Vaading with JS or TS. Yes, you have limitations with GWT (I also worked with that), but those limitations are coming from GWT and you can extend that, but that has nothing todo with JS. So my eco system is JS/TS, HTML/SCSS/CSS for the FrontEnd and JS/TS + Node in the BackEnd. And again I want to write as less as possible Java code for the plugin. Only that pieces what is needed. Your PR, which I merged into my plugin, has coupled JS within Java, which I don’t want but yes I know this is needed. Before I used your PR, you saw how I realized that, because I don’t wanted to coupled it. 6. I couldn’t resized the window when I was working with DukeScript, I didn’t have a lot of control to change the stuff to my needs. (setSize, noResizable, etc.) I simple couldn’t find that. So again, I hope it is a bit clearer how an eco system for a pure frontend guy looks like AND should look like. I’m willing to use Java, or whatever we need for NetBeans in the backend for sure, to create nice plugins. But sry, I’m not willing todo Java coupled with js for the frontend. But as less as possible, is ok. So my ecosystem: HTML project where I can create my UI or whole application with HTML, SCSS/CSS, JS/TS with my own build system (Grunt, Gulp, Webpack, etc.) Maven or Java project to create a plugin and copy/load my UI into that project with build process to build the UI within the project and the project itself. A possibility to communicate with Java/js w/o having much coupled JS/Java code etc. pp. So here you can see I have a working HTML Project, which I still can use in the browser. W/o having the Java project. And, when I want it, I can use the UI in the backend for the Plugin, which I wanted to use. HTML4J should also fits my needs as a FrontEnd guy, but atm it fits it only for 50% maybe. Or it is because of the archetype or the missing resource, to start with as a FrontEnd guy, not as a BackEnd Java guy. The next step is to create a new plugin with a HTML/SCSS/Vue/TS based UI -> build with Webpack HTML which loads the JS file, which includes the transpiled JS and the transpiled CSS. Sry for the bad english and maybe mistakes, I’m a bit in hurry. If everything is unclear, please let me know that. I’m really willing to work with HTML4j, because this is the only best solution to create scalable UIs with webtechnologies for NetBeans. I don’t have any other approach to work with HTML4J as for NetBeans. For the rest I use Electron or pure WebApp stuff. My famous last words. Cheers Von: Jaroslav Tulach Gesendet: Dienstag, 13. März 2018 09:26 An: Apache NetBeans Betreff: Think Java, not Electron! was: Apache HTML/Java UI instead of Thanks a lot for your opinions! I am going to react to one recurring theme in this email... 2018-03-12 16:59 GMT+01:00 Jaroslav Tulach <[email protected]>: > > Forget about AWT, Swing and JavaFX - the future is HTML. In case you still > care about Java, then your future should be Apache HTML/Java API! > > First of all I have to admit it drives me mad, how incapable I am in communicating these ideas. How could I be the initial architect of NetBeans, when I am not able to explain what HTML/Java API is beneficial for? Or was I just the architect and there had to be others to handle the public relations? Or was the success of NetBeans (Platform) just an unrepeatable luck? Anyway, there have been few references to Electron framework in your reactions to my email: > There is nothing better than creating UIs with HTML and use them everywhere, like in the Electron Framework. > ... look into electron apps ... like VS Code and I think this is a big Player and you can see, that it performs very well and it is performant as hell. OK, I can see people are looking (or at least googling) for alternatives to current UIs. Yes, I agree HTML is one of (the best) options there - especially if you want real WORA - e.g. also target plain browser. However I have to say the following sentence is just increasing my internal suffering... > heavyweight, ...(but)... the open source nature ... of Electron make it potentially an attractive option for mixed Java/HTML applications We - the NetBeans (incubating) project - have such technology, it is HTML/Java API. It has been intentionally designed to support mixed Java/HTML applications. We are the community of the project! But instead of improving what we have and making it work for our NetBeans IDE purposes (which is certainly simpler than trying to use Electron designed for something different; more on that later), we are looking at other project and admiring their "open source nature"! Am I really doing so poor job that people aren't willing to dedicate 10 minutes of their personal time to try HTML/Java API in action? Rather they are looking... > I was looking at an example project using Vaadin running inside Electron recently. Have you tried this approach with HTML/Java? ...and trying Electron samples! C'mon do you have recent version of NetBeans 9.0? Then just select "New Project", "JavaFX", "Java HTML5 Application" click through the wizard and choose Run/Debug on the generated project! How much did it take? 30s of activity[1]? > I keep trying to find some time to experiment with Apache HTML/Java and wondered at the feasibility of reworking that Electron example with it? If you give the NetBeans 9.0 support for HTML/Java UI a try, you see (when using for example the Visual archetype) that rewriting visually rich Electron application like https://github.com/electron/simple-samples/tree/master/activity-monitor should be a piece of cake. I consider it patriotic to try NetBeans own solution first. Am I completely off? > Demo app showing all kind of features a given system allows me to use. Like a toolbox, which I run and say - hey that's the component I need. Is there something like this for the HTML+JAVA api? The visual archetype offers canvas sample, line charts and pie charts sample and interactive GeoBase application. Isn't that enough? Then there is another CRUD like archetype, as well as simple MVVM sample. All of them are just few clicks from your reach ("New Project", "JavaFX", "Java HTML5 Application"), is that enough to get started? I hope it is. Guys, please, instead of drinking your morning coffee, click though the wizard and see Apache HTML/Java API in action yourself. I'll be thankful for comments. As confessed, I am depressed by my inability to communicate what our HTML/Java project can do for you. It may not be 100% perfect fit, but it is so close to what you guys need.... Shame on me for not being able to explain that! Thanks. -js PS: Now let's look at what Electron isn't and why HTML/Java shall be a better choice: > I am sure electron is good, but my personal preference is to not use a web ide. I share your feelings. However we are not talking about Web IDE. We are talking about reusing rendering pipeline that is behind HTML. Sure, this pipeline is used in browsers, but that doesn't mean browser == the rendering pipeline. Browser is much more and we don't need all of that. > Think about ... what Electron actually *is* ... Electron is the rendering pipeline, plus a bunch of libraries for dealing with the surrounding operating system, plus JavaScript specific build system. But, when writing Java application, why would you need those libraries? Java has pretty rich operating system API (think of java.nio, missing in JavaScript) and there are plenty of libraries to deal with other aspects of OS integration. Why would you need npm build system? Java has other, well established build systems as well. Conclusion? The only thing you'd want from Electron is the rendering pipeline. But then: What is the HTML/Java project goal? To be a portable abstraction over such pipeline! I would conclude that you don't want to look at Electron to begin with! Again, I am ashamed of not being able to get my message thru... > Funfact: Without JavaFX you don't have a HTML5 renderer The truth is that we already have our existing Swing/JavaFX applications and if we want to move towards HTML, we need an incremental way to migrate, rather than big bang rewrite of everything. That is not at all what Electron can give you! On the other hand that is something HTML/Java API shines at. Because of using the JavaFX renderer (behind the scene), we can easily mix the Swing and HTML UI in NetBeans IDE[2]. In any case having the Swing/HTML UI interop is real benefit for us. We can mix both types of the UI right now. By having the renderer as an implementation detail, we can replace it with better one in the future. PPS: Have any of the above (or below) convinced you to give HTML/Java API a try or did I failed again to explain its benefits? [1] Plus few minutes of Maven plugins initial download time... [2] Have you noticed that the wizard ("New Project", "JavaFX", "Java HTML5 Application") is written in HTML UI? I hope the transition from the Swing to the HTML UI was smooth enough to not be really noticeable.
