[DEPRECATED - PLEASE START NEW DISCUSSIONS INSTEAD] Your questions or comments about WebFX

[salmonb]

A question or comment about WebFX? DEPRECATED, PLEASE START NEW DISCUSSIONS INSTEAD

[evanvelikanov]

Pros

1. Seems fast
2. Seems flawless for the examples I tried. No bugs.
3. Several demo examples.

Cons

1. Incubation phase
2. No tutorial on how to get started.

General comments

1. Seems too good to be true. I expected Cheerpj would do it, but atleast somebody did it.
2. I actually tried the SpaceFX sample. It is a bit laggy, but I was able to play the game. My laptop is quiet ancient, and for this to work itself, flawlessly btw, and that also in what you call incubation phase shows a lot of potential.

I was wondering how can one get started? I guess the documentation is in progress?

[salmonb]

Thanks Ivan for your interest in the project and for your pros. I'm aware of the cons, but this is something that will be fixed over time.

Yes it seems to good to be true, but it's all real with no cheating, I promise 👼 All the credit goes to GWT which does such a good job when transpiling Java to JavaScript, I'm actually also amazed by the result. 😃

I feel also a great potential in this technology, so I will keep working on it, even if just on my free time for now, but I hope it will take off at some point and I will manage to opensource it successfully.

For now the technology is not yet really usable until I finish a tool that will help you building your WebFX app. If you look at the pom.xml of the gwt module of even the simplest demo, you will see a lot of dependencies that would be hard to write manually. This is because to achieve the smallest possible JS size, everything is split into small Java modules.

I'm currently working on the website which will be a WebFX app, so this will add another example at the same time. I will probably write another demo like a simple TODO app but linked to a Fauna database to demonstrate how you can also write serverless apps with WebFX.

Finally when all of the above will be finished, I will write a minimal getting started guide. Then I will look for beta testers for a first feedback. Maybe you would like to be part of them? 😉

If everything goes well, I will then try developing a community around the project, which is still part of the incubation phase of an open source project. So still a lot of work, but with a bit of luck it will work 🙏

[jarorosFork]

Count on me too

[salmonb]

Thanks Ivan, and I will follow your advise to not make more demos 👍

I think this project is a bit different from a startup. As you can imagine, I haven't written WebFX in one day and I don't think a few months more will make a huge difference. For example, the main reason why I actually wrote WebFX is to find a solution to the short-lived web technologies problem (a decision I made after having rewritten a front-end 2 times because of web technology obsolescence, and it was not a small app! And now the 3rd techno is deprecated again! This happens roughly every 4 years!). This instability of the web technologies is not a new problem, it still exists today, and unfortunately is not ready to disappear due to the high competition that takes place in the web ecosystem. I think WebFX can offer a much longer lifespan to web apps, because it's built on more sustainable technologies (JavaFX and GWT). In particular JavaFX (who celebrated its 12 years) and has a very stable API. So your JavaFX code should last and be relevant for a much longer time. In addition, Java offers an excellent refactoring support, another important aspect for the longevity of big applications.

But don't worry, my intention is still to publish the technology this year, and even probably in the next few months. The website and the build tool are the main remaining steps in this process, and that's currently my main focus (this takes most of my free time and explains the long delay of my replies, sorry about that...). I can't delegate the website to someone else because it's a WebFX app and the build tool is not yet ready...:neckbeard: But I think that the website will be great, with I would say a specific WebFX style, and that it will help a lot to promote the technology and attract contributors. Because yes, I now definitely count on the help of others to continue this project, that's one of the purposes of publishing it! :wink:

[salmonb]

Thanks @jarorosFork too. I will let you know all when WebFX will be ready for testing 👍

[evanvelikanov]

@salmonb I tweeted this to Johan Vos. I share this with you also.

When I chose #JavaFX, at first I thought I am investing on the language #Java, then I thought it is the ecosystem, but then I saw not much users of JavaFX, then only now I completely realize that my choice of JavaFX is an investment on the people who have brought it back to life.

If today I am planning a next decade with JavaFX, it is because of the commitment I see by you and other contributors of the ecosystem, many of whom I can mention by name and their work.

I feel this is the only solid ground which gives me the courage to invest in JavaFX, GWT and WebFx.

[orx0815]

I love this diagram on the web-technologies that passed by over the years:
https://github.com/mraible/history-of-web-frameworks-timeline/master/history-of-web-frameworks-timeline.png

[dukke]

Hey @salmonb this is amazing. I've run the demos and they seem to run fine.

I think this technology could be awesome, when it's fully developed.
Being able to compile/transpile your javafx app seamlessly to javascript and run it on the browser could be a game changer.
This is the missing piece to having JavaFX be completely and totally cross-platform (we already have mobile and embeded).

Awesome work!

[salmonb]

Thanks @dukke.

I totally agree, and also think this missing piece is preventing JavaFX to get more attraction. But if WebFX succeeds and comes to complete the amazing work done by Gluon, it may have a significant impact on the JavaFX adoption curve. Of course it will take time to cover all JavaFX features, but I think WebFX doesn't need to reach that point to be already an interesting option.

[timoreichen]

Hej @salmonb this is amazing. I've run the demos and they seem to run fine too

I totally agree with dukke.. very nice and i hope this project will evolve successfully.

Awesome work!

[salmonb]

Thanks @timoreichen.

And as you all, I would like to use it in my future professional projects too! So yes, let's hope WebFX will succeed! 🙏

[reportmill]

Congratulations on this work @salmonb - Very impressive! @ivan-velikanova sent me a pointer. I had no idea it was possible to write a library this way to support something as complex as JavaFX in the browser. I have worked a lot with TeaVM and CheerpJ myself. Your download sizes are very respectable (just 7 mb for Spacefx). I have gotten similar sizes with TeaVM (maybe a little smaller ;-)). I don't know much about http, but I was able to shrink my sizes by 4-5x by adding this to a .htaccess file in the folder above my download links:

# compress text, html, javascript, css, xml:
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

Keep up the good work!

jeff

[salmonb]

Thank you Jeff.

Yes JavaFX is complex, and WebFX is actually the result of several years of researches and experiments done in the background, in the context of a private project, with the idea to open source the technology later. And now this time has come!

Thanks for the trick regarding the network compression, but the WebFX demos (and the future website) reside in a serverless world (namely Netlify). So it's a CDN and not sure I can configure anything, but it should be already optimal. Actually I don't compress the files and just push the result of the GWT compilation (which is minified but not compressed). I don't know how good the compression is, but I assume Netlify does a good job.

[wswright]

Very much looking forward to any tutorial you can add.

[salmonb]

Once the website and then the build tool will both be finished, I will make a minimal tutorial, perhaps just a short video to start. May still take a couple of months. Will let you know!

[timoreichen]

My 50 cents to get some momentum is to release what you have and hope to get some participants
helping out. If your plans are to open source it anyway (do you??) - what could you loose? A couple of months working alone or with a few people makes a big impact.

[salmonb]

Is all of this really good advises or just the expression of your impatience?

Ivan you misunderstood what I said. I didn't say I need to continue building something so I can show it, as I have already reached that stage. I just meant I need now to better present the technology with a website.

Your 2 points (mistakes) are irrelevant. If I'm building the website and then the build tool, it's precisely because I'm focusing on the contributors (customers in your post) and not on the product, and it's the actual way out from the one-person team.

I don't share your opinion about the website, it will definitely be a major communication tool and bring more people. The website is a WebFX app and it has its own and unique style, nothing to do with the typical boring technical site built in 1h you are thinking of. I'm pretty sure you won't help yourself to share the link when it will go live. The contributors are a very small proportion of people so I need to reach much more people than now and the website is the key. And once it will be live, I'm confident this will happen quickly.

I can understand you don't care about the website because you have found the project yourself (despite my complete lack of public communication which was on purpose) and all what you want now is the build tool. But I'm sorry, the correct sequence is the website first and then the build tool. The reason for this is that releasing the build tool also means offering support, a stage the project hasn't reached yet (one of the reasons why I said the project is in incubation phase). The scale of interest for WebFX is huge and a consequent part of the Java community might be interested. I was perhaps crazy enough to write WebFX, but not crazy enough to open the support with just one-person team who just do this on his free time, and face this big world in these conditions. So while the number of people will increase thanks to the website, there will be some discussions with hopefully some important actors of the Java community about how to reorganise the project. The project now needs at least 1 full-time developer, which my current situation doesn't allow, but it shouldn't be that difficult to find someone happy to take this position. Because WebFX is just an amazing opportunity for a developer who wants to make a living from an open source project, especially with such a big potential.

[timoreichen]

Well, for my part i dont want anything. So, no, i don't want the build tool! Its a discussion you wanted - my thoughts. If you find a full-time developer this way, great. I really hope you succeed. For now there is nothing to investigate anymore. As only you can tell what maybe is possible or not. Good luck.

[evanvelikanov]

Yes @salmonb
We all, not just me alone, want to see you (and of course WebFX) succeed no doubts about that. And I support your decisions, I may differ in opinion of how it should be done, but as you rightly pointed I am not one of the contributors. I apologize for the way I say things and do not intend to neither distract you from the actual work you are doing and specially I do not intend to wear you down by having you to reply to non-contributing discussions like the previous one.

Few years ago if i had seen this I would have jumped to work on this and make this come out asap. However right now I have to count myself out of the people who can actually support this. But bottom line is this, I hope you get a good number of people working on this and contributing on this and give several hands.

Actually hours after commenting only I was thinking, what kind of website you are planning. Will the JavaFX text elements be mapped to html which can be indexed by search engines (or even svg) or would it be a canvas element. Then I thought since you are so keen about the website you might have already made plans to really make it a competitor to web-stacks like react and vue, which means it might produce html not just render into canvas. With this understanding it kind of explained the interest to make the website. At the same time, it is a big promise to make, so I were you, I might not want to advertise until it is done. All this is my reverse calculations which might not even be true. But I was curious to ask, how would the website do in terms of SEO?

[salmonb]

Maybe I was wrong thinking you were pushing me, typical misinterpretation from a text-based communication in that case, sorry...

But yes I'm interested by your thoughts. When you said for example I had enough demos and my plan to do another one was not the right thing, it was very helpful to have this feedback.

Also when the website will go live (hopefully next week if everything goes well, otherwise the week after), it would be helpful if you can review it and tell me what you think, so I can make the necessary corrections. Not sure yet about the advertising strategy (who to target first and when).

Yes Ivan, the website is mainly using the scene graph and WebFX maps this to html, but I use also a few canvas for some graphical elements when it's more convenient, and svg as well. I think the search engines will see it as a typical SPA (Single Page Application) and they can deal with that (including text in svg). Actually the Lighthouse Chrome developer tool gives it a high score (100) not only for Performance (on good machines + good internet connection), but also Accessibility, Best Practices and SEO. But Lighthouse is focusing on the first constant display only, and I don't know if the search engines will detect subsequent contents as they appear only if you click on some elements and these contents are not referenced by any html links (this will require some additional study cases to know). Actually the url doesn't change when you click (there is no UI router), but it's ok in this case because there is just a couple of "pages" and only the main one makes senses for SEO. For this website, SEO is very simple, the main thing is just the meta description and the page title, not really the actual content of the website. I think the only thing I can aim is that people can find it when they search "JavaFX transpiler".

Yes I have a plan for a WebFX stack. If I can reorganise the core project (WebFX itself) and hand over to another developer, I will start this as a secondary project. Whereas the core project will focus on JavaFX only, this second project will focus on the stack. Because JavaFX was not originally designed for the web platform, there is no UI router for example. Also an event bus to communicate with the server will be required. I will either create new libraries or gather existing ones and ensure they work in a WebFX app (make them GWT compatible if not already present in the GWT ecosystem, and integrate them with JavaFX when this makes sense, like for example a i18n library). So basically all pieces usually found in frameworks, but if possible as independent small libraries that integrate well in the WebFX stack. I'm not a big fan of big framework libraries that do everything, and I think the fact that JavaFX is "just" a UI toolkit and not a framework is a good point. If the WebFX website could reach the performance score 100, it's also because there is no heavy framework processing running in the background, and in the context of a simple website, all of this is not necessary, so "just" JavaFX is perfect. But otherwise, yes a WebFX ecosystem can be built, characterised by its compatibility and integration with both GWT and JavaFX. I think the WebFX stack project will be an important complementary project for the success of WebFX in general. From one point of view yes we can see it like a React, Vue, etc.. competitor, but that's actually not the goal. The goal is to offer an alternative (and sustainable!) client side web technology that integrates better in java-based environments. In other words, WebFX is for the Java world, and doesn't aim to compete the JS world.

[evanvelikanov]

Wow, this sounds just so pleasing to hear. I can visualize having custom JavaFX components which map directly to Html. I saw the DOM a bit, the scene-graph seems to map to DOM 1:1, only the final ui-component finally maps to canvas. So the whole app is not a single canvas, but many canvases. So it is my guess, that it is just a matter of rendering few components directly using html instead of canvas. Looks possible and you confirm that something along those lines will be there.

I can even visualize having things like small webfx apps (like vue apps) embedded in a larger html page. I don't know if you have plans for that, but it seems something that would be simply possible out of box, surely after you do the planned web stack.

I am extrapolating things in my head, which sound too good to be true. I feel this is a very mature product which is getting created, albeit one bit at a time each day progressing. Just like GraalVM which took like 7 years but took the Java ecosystem way-way ahead of anything else. Even today people are not realizing the potential of GraalVM. Not comparsing apples to oranges, but this step of bringing javafx so close to the browser in such an elegant fashion is something I see which will fundamentally change the way (java) developers think and develop.

The best part of your message was your mention that the website will be done in something like a 2 weeks timeline. I was thinking it might take months (I looked at it pessimistically, investing my hopes at the worst case scenario timeline). Earlier I was not interested in the website, but this discussion helps me see the work with a lot more respect and admiration.

I have my own small tools and simple ways for doing the entire web stack, top to bottom in java. I write html, css and javascript all three in java. I have an extremely simple html dsl library written in java which transpiles to js (using jsweet), I also have a css dsl. My plans were to make the required little bit adjustments, and moving it towards making it compatible not just with html, but also to generate React and Vuejs templates. It gives me the joy of static typing and at the end of the day everything is just pure java. I call these tools Luvml (Html and SVG DSL, for the matter any xml) and Luvs (CSS DSL).

(The screenshot shows the Luvml part, the Luvs(css) is still very nascent which is why the inline styles are written as plain strings instead of being in java code. I think soon I would like to write React or rather Vue in the same way, everything part of a single java application (with many modules) written in nothing other than java - no xml or json configuration files btw, and probably no annotations also, just simple java)

For me this fills the gap between writing a full fledged app versus just making a website that makes ends meet. Using Luvml, I was fortunate to be able to make super efficient websites, which got a 100% score in everything and create extremely light weight web pages - from 2KB to 30KB . Just like you mentioned earlier, I like to break things into smaller light weight modules, much different from what people usually do by default. I design my libraries with a assumption (or rather hope) that one day this will run in the browser like a js library so it cannot be heavy and bloated. All this is my pet projects which have not been so far written in a way that I can share with the world. Even the SVG DSL I was able to use as a replacement for Adobe Indesign and automate things in an extremely simple way which otherwise were far from being straight forward. I hope I will get time to make these things useful for everyone not just myself.

I fundamentally dislike webapps, they feel very limiting, I would always prefer javafx, because with javafx i have speed, power, a desktop app, and now a mobile app (thanks to gluon) and in near future a webapp (thanks to WebFX, credits due to JPro also although I am not a big fan of that approach). Web apps are indispensable as it is much easier for people to just open a web page than to expect them to install an app. WebFX gives me a lot of room to breath. I feel it is quiet cruel to expect a single developer team (or small team) to do apps in desktop, mobile, web as a bare minimum criteria to be eligible for being just visible in the market, let alone compete. The expectation that people have with apps (specially people who use only mobile and have no desktop kind of large screen devices) is too high. Sorry to say these people are almost illiterate. They are dead consumers who just know to tap their phone and expect some magic to happen. Nobody writes IDEs for mobile, the maximum you can expect is a web IDE. Mobile seems not a platform for developers/creators but rather a platform for pure consumers. In such a world (unlike 10-20 years ago) although there are a lot more people online, most of them are just consumers unlike how it was earlier when a bigger portion (%) of people were creators.
WebFX gives developers the possibility that they can write less, and run everywhere. Having to write for one less platform (web) and being able to recycle (some if not all) your native javafx app code for web, is surely going to make life easy.

Enough of discussion, back to work.

[JonathanVusich]

What is the performance delta between running a program like SpaceFX on desktop vs browser? I am curious.

[salmonb]

Good question.

There are 2 areas to distinguish: 1) the starting time and 2) the subsequent execution performance.

1. Regarding the starting time, a WebFX app has some chance to start faster than the JavaFX desktop version. The main reason is that the desktop version includes the JavaFX starting time which can be consequent, a bit like when you start your browser, it may take a while sometimes. But when you start a WebFX app, it's usually from your browser that is already started. So it's a bit like a warm start (faster) vs a cold start (longer).

Of course there are some other factors like loading the program itself, which is likely faster from the desktop (just accessing your drive) than from the browser (especially if you have a slow internet connection and/or meany resources to load). GWT lets you embed your resources in your JS code if you want, but I haven't done that for SpaceFX because the resources are quite big, so they are loaded after the application starts, and you may notice some images missing at the beginning of the game if your connection is too slow, which of course doesn't happen with the desktop version.

For the case of SpaceFX, I can observe comparable starting time between the browser and the desktop. But SpaceFX hasn't been especially designed for a quick start up.

Because the program itself is another important point to consider. Probably most of JavaFX programs don't pay too much attention to the starting time knowing that JavaFX already takes a few seconds to start anyway. But the starting time matters much more when it's a website or a web app, because people have much bigger expectations in this context. So really paying attention to what the program does before displaying the first content is important and may have a big impact. For example lazy initialisations instead of immediate initialisations can make a big difference. Thanks to such optimisations I made on the WebFX website I'm currently developing, I managed to measure a performance score of 100 with Lighthouse (with Chrome on a MacBook Pro 2019 and a good internet connection) which is the maximum score a website can get. Getting this perfect result is generally very difficult for a website, but yes you can get it with WebFX if you optimise your code! That's one of the thing I want to show with the website and one of the reason why I think the website will have an important role to promote the technology.

2. Regarding the subsequent execution performance, I haven't made precise tests but I'm pretty sure the JVM will always surpass the browser. Already on a single thread. And if the desktop app uses multi-threading then the advantage to the JVM is even more significant. You can do some multi-threading using web workers, but it's much inferior to a JVM thread in terms of starting time (a web worker is basically a separate application that you need to also load) and communication with your main application (you will have to use some asynchronous communication API and also serialise your data in json, whereas a JVM thread doesn't need any of this and can directly access your application context, so the difference in performance is just big).

But otherwise in many case it will be fine and probably the user will be happy with the performance, as most of applications don't require much power. In case of SpaceFX the browser version manages to honour the frame rate like the desktop version, so the user probably won't feel any difference between the 2 versions. Regarding the garbage collection, I don't know how good the browser is, I think there was much more research in that area on the JVM so I guess the JVM GC performs better. The JS GC might block a bit more the application sometimes on slow machines.

But regarding applications that require more power, the difference between the 2 versions will be much more significant. For example when I run the Mandelbrot demo for 1 minute on the first Mandelbrot place with 8 threads for the JVM version and 8 web workers for the browser version, the desktop version manage to compute 140 frames while the browser version only 32 (both on a quite slow computer but it doesn't matter). So a big difference even if the browser version uses WebAssembly for the computation. We can see that with such application it makes sense to have a desktop or native app instead of (or in addition to) a web app. However WebFX tries to get the best of the browser platform by supporting web workers and WebAssembly when this makes sense but be aware you will never get the same speed as the JVM. This is not something WebFX can solve, this is inherent to the web platform.

Another important aspect to consider is also the rendering engine. For some graphical operations the browser can perform better than OpenJFX or vice versa. For example the first basic demo is much more fluid with OpenJFX than with the browser, because it uses a blender mode that is apparently better implemented in OpenJFX than in the browser. But it's the opposite with the Particles demo which uses another blender mode (and in the canvas this time) which seems to be better implemented in the browser than in OpenJFX.

Like you see, there are many parameters to consider, but I think I listed the main ones.

[rnayabed]

Wow this is really awesome. Would love to port Stream-Pi to this. This is really next level :D

[salmonb]

Nice project!

You may be able to port your app in WebFX, depending on the JavaFX components and features that are required for your app (WebFX is providing a limited coverage at this stage).

But if it works, you will keep having all the benefits of the Gluon tool chain (including Raspberry Pi) plus the web platform.

Otherwise the alternative is JPro (much better JavaFX coverage) if you don't mind having a server part.

[Birdasaur]

I have multiple government funded JavaFX applications focused on custom data visualization that could take advantage of this. How can I become a beta user?
Side question: Does webfx have any support for JavaFX 3D? (I would guess not but I wanted to ask).

Thanks for the great work.

Sean

[salmonb]

I confirm your guess, WebFX has no 3D support at this stage.

My main job for now is to publish the result of my work with the website and later the build tool, and I think this will ring the end of my one-person team work. I hope I went far enough to give this project a future, as I think I discovered something really interesting with this improbable marriage between JavaFX & GWT. And if everything goes well, a full-time developer will take over the project. Only at this stage, the JavaFX features covered by WebFX will increase.

The website is almost ready and I think the build tool may take another couple of months to finish. Then the project will be able to start welcoming users, but as far as I will be alone on the project, the support will be very limited (unless the project will already be reorganised meanwhile). So I may propose an early access program with a limited number of users, and see how it goes. I will invite you if you wish.

[Birdasaur]

I may propose an early access program with a limited number of users, and see how it goes. I will invite you if you wish.

This would be an excellent thing to do as soon as possible. Let us help you move faster by testing early.
I would start today on multiple projects if it was available.

[wswright]

I'm also very interested in using JavaFX 3D w/ WebFX. :D

…

On Fri, Feb 26, 2021 at 11:18 AM Birdasaur ***@***.***> wrote: I have multiple government funded JavaFX applications focused on custom data visualization that could take advantage of this. How can I become a beta user? Side question: Does webfx have any support for JavaFX 3D? (I would guess not but I wanted to ask). Thanks for the great work. Sean — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABEFD7PGXIDB5JGEAOSOFLTA7CUPANCNFSM4USUA5GA> .

[Birdasaur]

only one of my current apps uses 3D so I could convert to a 2D projection I suppose. I am guessing that converting JavaFX 3D would be a tough given that it doesn't directly map to the underlying opengl calls. you would need yet another transpiler layer to go from the prism 3d calls to webgl?
I am a co-founder of FXyz3D so I can say we would be happy to help with that effort.

[salmonb]

I'm really not an expert in 3D (actually I never wrote a 3D program), but I think it will be possible to later support 3D with WebFX. 3D components are probably quite standard nodes in the scene graph (but with an additional Z dimension). So nothing really new regarding the GWT compilation (these 3D nodes can surely be patched to make them compatible with GWT). The node itself is just the model, and in WebFX you can register a peer for each node class, that is responsible for mapping the node to the underlying platform. Roughly a peer will listen to all the graphical properties of its node, and react by updating the underlying platform, typically a DOM element but it can be anything else, so WebGL or an underlying 3D JS library should work.

Thanks @Birdasaur for offering your help, sure we will invite you as a contributor as soon as the 3D support will start! (don't ask me when, I don't know!...)

[salmonb]

I promised the website for this week, and here it is! ✨ https://preview.webfx.dev ✨

It's just a preview for now, so please don't share this temporary link at this early stage (I think the actual go-live will happen within a couple of weeks).

I started a new discussion thread in the website repository to avoid polluting this thread, so you are very welcome to join webfx-project/webfx-website#1

Thanks!

[dukke]

Wow.. great Job!!!
I think this can be an amazing step forward for JavaFX.

[Pfiver]

Woooho!! Is this the dawn of a new age of WORA!?

I am hugely impressed. Unbelievable what you have created. This is truly amazing. Awesome! :-D

Am I right in concluding my first ride with: There might be some work ahead in "translating" all of JavaFX to WebFX?

e.g.

[INFO]          [ERROR] Line 29: No source code is available for type javafx.scene.chart.Chart; did you forget to inherit a required module?
[INFO]          [ERROR] Line 45: No source code is available for type javafx.scene.chart.NumberAxis; did you forget to inherit a required module?
[INFO]          [ERROR] Line 44: No source code is available for type javafx.scene.chart.CategoryAxis; did you forget to inherit a required module?
[INFO]          [ERROR] Line 46: No source code is available for type javafx.scene.chart.StackedBarChart<X,Y>; did you forget to inherit a required module?
[INFO]          [ERROR] Line 47: No source code is available for type javafx.scene.chart.XYChart.Series<X,Y>; did you forget to inherit a required module?

And may I - out of curiosity - politely ask, how much? :-) In other words: How big a percentage of the "most common" Controls, Skins, etc. are Done vs. ToDo?

[Pfiver]

Ok. So I would like to create a little Chart Page (App). And chart.js is just not what I want to do. Thus, in order to get some kind of feeling for how much of an effort it would be to get that to work with WebFX, I blindly started copy-pasting ~7 Chart related openjfx classes, dodging compilation errors by commenting out stuff and then just adding "webfx.kit.controls*" to the ColorfulCircles Demo and see how it goes.

Amazingly, I managed to make something that somehow at least resembles the "original" (openjfx):

But now I have actually no clue why and how this worked. :-) Looking at the DOM, I see that this <fx-stackedbarchart> with a bunch of children has been generated, seemingly, "magic". Actually, I had been working with JavaFX 8 for some time, but have never quite managed to understand how the framework does it's "magic".

Do you have any pointers to some good - and preferably easy to consume - "design documentation", "tutorials", or such, that explain the "inner workings" of the JavaFX framework? And could you explain if, how, where and why WebFX differs from it?

The big question for me is simply: "How do the objects of the scene graph get mapped on the screen?" / "How are their 'low-level' representations constructed?"

---

Anyways, generally speaking. It looks to me like there is "quiet a bit" of work left, until one doesn't "feel" a difference when creating a WebFX page vs. creating a JavaFX App. I wonder if it would ever be possible to run existing JavaFX Applications without substantial customizations. Not all of which would be due to missing JavaFX APIs. A lot, if not even more, would also be due to missing Java SE APIs in GWT. E.g. I had some trouble with DecimalFormat in NumberAxis, as it doesn't exist in GWT.

NB: I realized that the Scene is not resized when I resize the browser window. Is there an easy fix for that?

PS: I have translated some JavaFX CSS to Web CSS as well to get the above POC to work. It seems doable, but I am not so sure how to handle the files. <module> <html if-uses-java-class=...> in webfx-kit-javafxcontrols-peers-gwt/webfx.xml seems no to work as pretended.

[salmonb]

I'm glad you made some progress with your chart application. I'm currently working on a build tool that will allow you to build your own applications from scratch, but it's not ready yet, so ok for now to start from demos such as ColorfulCircles.

I'm also glad you're making these efforts, this let me think it's really possible people will contribute to WebFX. If it happens already now that people work on missing JavaFX components / features, it should even be better after the project will be officially open. 👍

Regarding your "big question", WebFX maps the scene graph to DOM, even with JavaFX nodes it doesn't know like those you created. And it gives them a tag name which is the node class name prefixed with "fx-". We can think there are 2 kinds of JavaFX node: low-level or high-level.

By low-level I mean nodes containing low-level graphical properties, like for example Circle. These nodes need a WebFX peer (ex: HtmlCirclePeer) whose job is to map the JavaFX node and all its graphical properties into a HTML node with equivalent properties (there is no direct equivalent to Circle in HTML but HtmlCirclePeer will apply a border radius that will make the html block always round).

By high-level, I mean nodes like controls with a skin. In that case, the new graphical properties it defines are high-level and don't need a specific new peer. WebFX will just associate this node with an existing peer (ex: HtmlRegionPeer if it's a region)
and therefore ignore all the new high-level properties. However, the skin should react to these new high-level properties and consequently translate them into low-level nodes (this is the job of a skin). These nodes created by the skin are standard children of the control and therefore will be mapped by WebFX into finally low level nodes with peers. This is what you finally see on the screen. And this is how the magic works (for both JavaFX and WebFX).

Regarding GWT, yes sometimes it takes a bit of time to translate a non GWT code into a GWT compatible code. Sorry for the DecimalFormat issue. Let me know if you manage to find a workaround.

Regarding the scene, I'm surprised it's not working. Can you install listeners on width and height properties to confirm?

Regarding CSS, you can look at the FX2048 demo. You can see how it loads a css sheet with the standard JavaFX API ie scene.getStylesheets().add() and by doing this there is no need to manually change the html file, it's done dynamically. But you need to replace the typical getClass().getResource("mystyle.css").toExternalForm() which doesn't work with GWT with ResourceService.toUrl("mystyle.css", getClass()). ResourceService is a cross-platform API provided by WebFX for loading resources. In the case of FX2048 I just mixed the JavaFX and Web CSS in the same file (which is not very clean). You can start doing the same and I will explain later how to cleanly declare 2 versions of mystyle.css (one for JavaFX & one for the web).

FYI all what is declared in the webfx.xml files are for the WebFX build tool which is not yet released. So nothing happens for you when you change these files (they are not considered by the Maven build). The WebFX build tool actually generates all files needed prior to the maven build from the information contained in webfx.xml files. Also the format is alpha (I'm currently making changes on it).

[Pfiver]

Thank you very much for all the info and those tremendously useful insights!

I have had some more fun with those charts and have been able to find solutions for all hurdles I've been facing, except... the resizing issue.
I have added obeservers to the scene with and height properties and they fire. However, I am binding them to the Chart's preferred with and height as the with and height of Chart itself are read-only. And for some reason, in webFX, the Chart is not re-sized when scene is resized. In JavaFX it works. I have looked at the sources trying to find some hint but not found any. Chart.prefWith(-1) is called only on page load, while in JavaFX it is called when the scene gets resized. (At least I believe strongly now that I observed this, by adding some debug log statements. But this is more than 24h ago now... :-)

Anyway ... the chart loads still. (Growing Bars) Animation on load works (but I believe I've commented it out for now... And the changes I made to webfx and the colorfulcircles demo are on my Github. If you find time to skim through and give some feedback, I'd be glad to work it into some "shippable" form.

For convenience, here are the Github "compare" links:

• main...Pfiver:pfiver
• webfx-demos/webfx-demo-colorfulcircles@main...Pfiver:pfiver

[salmonb]

Probably a WebFX bug as it behaves differently from JavaFX... Maybe because you embed the chart in a Group (I have a few issue with Groups). FYI nodes that have read-only width and height properties can still be resized using the resize() method. That's what layouts do. So try to embed your chart in a layout (ex: BorderPane, StackPane,...) instead of a group. You coud simply write something like:

    @Override
    public void start(Stage primaryStage) {
        primaryStage.setScene(new Scene(new BorderPane(createChart())));
        primaryStage.show();
    }

[Pfiver]

... works like a charm. Thank you! 👍🏻

[anprdev]

Hi,
I wondering if it is possible to convert a complex JavaFX Desktop app to JavaScript with WebFX.
Thanks for answering.

[salmonb]

Hi @anprdev,

Apologies for the long reply delay, the project has been paused for nearly a year... But it is now restarting! :)

Good news regarding your question: yes, it is possible to convert a complex JavaFX desktop application to a WebFX app (this is actually our real underlying motivation).

We are currently in the process of doing such a conversion with a quite complex enterprise application, and we will open source it as well (more news on this soon). The process may take a while (at least a year), but you will be able to follow our progress. We already have made a prototype. We will publish a video demo of it by September.

You can follow us on our blog where we will post regular news and updates on the progress made (on both WebFX itself and that WebFX enterprise application).

[salmonb]

hi guys, just to tell you, you can now follow us on Twitter.

[gnahraf]

Nice work! Very impressive. I'm new to both gwt and webfx.. learnt about this all the other day on Twitter. I think this is an ingenious approach. I have 2, maybe 3 questions.

File Chooser

I've played around with the example apps and understand it's presently limited to the [feature set] (https://javadoc.webfx.dev). I'd have several candidate apps, if I had a way to hook in a FileChooser. (I'm assuming there isn't a way to do this; if there is, apologies for the false premise of this post.. ;)

I found this article about [gwt_fileupload] (https://www.tutorialspoint.com/gwt/gwt_fileupload_widget.htm), but being new to this, I'm not sure it's apt, or whether this is a gwt issue, or a webfx one. (I don't want to upload the file: I want the app to read the file--as javascript can, inside the browser too.)

Feature Priorities

So this question kinda brings up a larger question.. The file chooser seems like a "platform" capability, whereas more UI features might be seen as "presentation polish". I'm wondering if there's a backlog of such "platform" nice-to-haves.

[salmonb]

hi @gnahraf,

Thanks for your interest and support :)

Regarding your questions, let's start with bad news: it's actually impossible by design to emulate javafx.stage.FileChooser in JavaScript for many reasons, such as its blocking API (ex: showOpenDialog() method), its usage of java.io.File (which is also not possible to emulate because of its blocking API), the fact that in JavaFX you can invoke the FileChooser programmatically while in JavaScript the one and only one possibility to invoke the FileChooser is through a user click in a DOM element...

But let's continue with good news: WebFX will provide its own cross-platform FileChooser as part of its WebFX Extras library. It will provide an asynchronous API and a compatible way to invoke it. There will be an OpenJFX and GWT implementation of it, but your application code will be the same (as it's a cross-platform API). We plan to finish the initial version of that API within a couple of weeks. We will let you know when it's available. We will probably also publish a demo and a post in our blog about it.

[gnahraf]

Thanks for your response and clear explanation for why the usual FileChooser abstraction is a poor (impossible) fit. Looking forward to this coming API / capability. I might be biased to my use cases.. but I think it'll be a game changer ;)

[salmonb]

hi @gnahraf,

I'm pleased to let you know that it's now implemented in WebFX!

I invite you to continue our exchange in this dedicated GitHub discussion.

[gnahraf]

Yay! Thanks for the invite

…

On Wed, Oct 19, 2022 at 5:49 AM Bruno Salmon ***@***.***> wrote: hi @gnahraf <https://github.com/gnahraf>, I'm pleased to let you know that it's now implemented in WebFX! I invite you to continue our exchange in this dedicated GitHub discussion <#14>. — Reply to this email directly, view it on GitHub <#4 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHUG6LAUMDUD3VJ2OXG6V3WD7N3NANCNFSM4USUA5GA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[gnahraf]

Is there an API for AJAX, callbacks, URLs and such?

[salmonb]

Here is what we have so far to communicate with servers: a cross-platform Web Socket API for the low level, and a cross-platform EventBus + JSON API for the high level (which is the preferred communication protocol for modern servers such as Vert.x or Spring Boot).

But I guess you just want to do a simple HTTP request? We don't presently have this API, but it shouldn't be that difficult to make. What type of data are you expecting for the result? Will you be happy with a API that just returns the result as a String? As I said, we have a cross-platform JSON API, so you can use it to parse the result if this is the format you expect. But we don't have a cross-platform XML API.

[salmonb]

hi @gnahraf, I invite you to continue in this separate discussion, because this one is too old and send emails to too many people who may not be interested anymore. No need to reply here, just use the new discussion instead. Thank you!

[anprdev]

Hi all. The app I'm busy with is completely written and there is no time to convert this to WebFX. So no mails needed anymore. Best regard Roland Op 20-10-2022 om 20:27 schreef Babak Farhang:

…

Is there an API for AJAX, callbacks, URLs and such? — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASHVFKHYPXPNV6CJ7BAMXW3WEGFIRANCNFSM4USUA5GA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[salmonb]

Sorry @anprdev, I put [DEPRECATED] in the title of this discussion, and hope this will stop new posts. I will invite the new poster to continue in a new discussion. This may generate another - but hopefully the last - email. Sorry for this inconvenience 🙏