Preview & review of the website (before actual go-live)

[salmonb]

Link to the website preview: https://preview.webfx.dev

This link is temporary, so please don't share it (soon the website will go live to https://webfx.dev and this preview link won't work anymore). The purpose at this stage is to get your feedback, fix bugs and make the necessary corrections before actually going live.

As I said, the website is here to present and promote the technology, not to provide detailed technical information. I think it will be a good communication tool to share on social networks and get more people interested by the project.

First, do you like it?

It has probably a few bugs, as I tested it only on a very limited number of devices. So if you notice a bug, you can report it to me just by opening an issue (in this repository), and I will try to fix it. This can include responsive design issues.

Also, if you are an English native speaker, feel free to improve the website wordings, as I'm not (I'm French). You can open issues for this as well.

Last point, it's important that the website tells the truth, especially when comparing technologies. I sincerely think it tells the truth, but perhaps there are some features in other technologies I'm not aware of. For example, when I say JavaFX shall become the first major desktop toolkit that can be transpiled to the web, can you confirm it's true? Or do you know another desktop toolkit that can already be transpiled (with no running server part required)? Or in the responsive card, is all what I say about CSS true? Please let me know if you see something false.

Thank you!

[dukke]

Wow.. great Job!!!
Thanks for sharing this. I'd love to share this with others that would also be excited but if you don't want it to be shared I'll respect that obviously. 🙂
I think this can be an amazing step forward for JavaFX!

1 - My opinion on the CSS card that you ask. To be honest I'd have to say I don't agree with that card.
I work with both JavaFX and web, though much more with Javafx. I wouldn't say you can't achieve those layouts using web technologies (as I think is implied). CSS is quite evolved nowadays and for complex layouts you usually combine javascript with CSS. I'm not aware of anything that can't be achieved this way, and this is usually what developers use.
As a side-note: although I've been working professionally with JavaFX since its very first release and I prefer it to web technologies when developing complex apps, I still prefer web css when it comes to layout, ease of tweaking visuals..

2- Flutter runs on desktop,mobile and web: https://flutter.dev/ . It compiles Dart to Javascript. So to answer your question I don't think this is the first time for desktop, etc frameworks to be able to also run in a browser by compiling/transpiling code to javascript.

---

Question: Do custom skins work, I suppose yes? I have a JavaFX theme called JMetro https://github.com/JFXtras/jfxtras-styles and was wondering whether apps using it would be able to run with webfx..

---

Thanks again, great work!

[salmonb]

The website promotes WebFX but also JavaFX (and a bit GWT). These 2 points raised so far are more about promoting JavaFX than WebFX itself. So do you think this statement ("major desktop...") helps to promote JavaFX? If not, I can just remove it, especially if like Ivan said it may attract criticism. Can you tell me what you would personally do?

Regarding CSS, would you mind to help me going deeper into details? This will help me to understand what's true/false, pros/cons of the JavaFX layout system, and correct the different points of the card.

Perhaps can we start with one of the simplest point: the @media rule. Because I think most of people use it for their responsive design.

For example, I made this little WebFX demo https://responsivedesign.webfx.dev which is a JavaFX implementation of the Mostly fluid pattern described here: https://developers.google.com/web/fundamentals/design-and-ux/responsive/patterns

You can see the JavaFX implementation here: https://github.com/webfx-demos/webfx-demo-responsivedesign/blob/main/webfx-demo-responsivedesign-application/src/main/java/dev/webfx/demo/responsivedesign/ResponsiveDesignApplication.java

And their HTML/CSS implementation: https://googlesamples.github.io/web-fundamentals/fundamentals/design-and-ux/responsive/mostly-fluid.html

Can you confirm the later works only if the container is at the top level?
What would be the HTML/CSS equivalent of the WebFX demo?

[ivan-velikanov]

@salmonb I think the above question is for @dukke
But I have been thinking about this.
What I feel, the direct competition kind of image with anything _____ is going to attract criticism from that camp. People in the web world are already overloaded with new new things which makes them feel that they are missing the next cool thing. In such a scenario everyone wants to reject new tools as inferior or nothing special, because if not there is yet another thing which they need to master.

Regarding Flutter and JavaFX, I know a few developers who have extensively used both.
https://twitter.com/WhiteWoodCity/status/1248973564423712770

Probably better to leave the discussion of X vs Y to the end users and focus on the product. And as you interact with users you will get deeper understanding of their needs and why and how JavaFX/WebFX fits their use case, and according to their feedback to the marketing/persentation of the website.

[dukke]

@salmonb
Thanks for commenting and sharing your insights.

1 - I write my own layouts all the time in JavaFX and I still prefer web CSS layout and styling features. If anything I would be biased towards JavaFX since that's what I've been working on professionally since it came out, but I have to admit that when it comes to tweaking styles and layout the web is superior (much quicker tweak-reload cycles, better tools for this, etc).
It's very easy to do a 3 column layout in web CSS, just by using CSS FlexBox or CSS Grid. Those articles might be old or the devs might still be using CSS version 2 specification (floats and stuff were a headache). You can also use absolute position in CSS and combine relative and absolute. A lot of web pages combine absolute positioning and static positioning.
If you want to only say things that are 100% full proof on your website I would personally remove that card.

2 - I haven't worked professionally with Flutter either so I'm certainly not the best person to comment on this point. Seems that flutter is kind of similar to JavaFX in the way its cross platform toolkit but anyways not the best person to comment on that.

Anyways that's my opinion if you want to only say things that are 100% full proof. I agree with you and always try to say things I'm 100% certain in these situations. But I'm no marketing expert either, Apple for instance says a lot of crap (Apple's reality distortion field) and users still buy into it (not saying that what you said is crap, this was just an example).

---

Regarding the answer to my question:

1. Yeah JavaFX CSS is the biggest performance drainer so I can see why you're reluctant to include it.
2. But what happens if your JavaFX app relies heavily on JavaFX CSS and you want to run it on the browser using webfx?

I like that idea of being able to run javafx with css on the browser anyway and having an option to disable it if you want to increase performance. That way you'd still be able to run most of javafx apps (most use javafx css in some way).

[salmonb]

Ok! I followed your advises and removed both the statement about JavaFX and the responsive card.
The website should be still good enough, isn't it?

Yes that's definitely a big problem for integrating existing JavaFX applications, and therefore a priority feature to support in the future. But for now I publish WebFX as is, and we will see!

[dukke]

Yeah I think it's already great. I agree publishing right now is a good move.
I personally really like how some of the demos run really fast on my machine. E.g. spacefx, particles demo, 2048, etc

[dukke]

@salmonb Regarding your second comment:
There's a few ways to do that in web css. I would say either use CSS flexbox or CSS grid.
Here's an example using flexbox: https://css-tricks.com/adaptive-photo-layout-with-flexbox/
and another using css grid: https://www.freecodecamp.org/news/how-to-create-an-image-gallery-with-css-grid-e0f0fd666a5c/

[dukke]

Me, I enjoy the chance of being able to change things at runtime though CSS and using tools like firebug (or chrome developer tools or whatever) to tweak that instead of changing code, compile, run.. no that's not it.. close app, change code, recompile again, run again.. no that's not it again.. (repeat cycle)
I also enjoy the ease of tweaking and reading already written CSS vs looking and reading already written java code (example: looking at code of skin classes from the javafx library). For instance CSS Grid allows you to do complex layouts with just a few lines of code.
Besides that there's also the advantage that people who don't know programming (i.e. Designers) can write CSS and do all the layout and visuals of a site, etc..
Anyways lots to discuss here. I don't think we'll ever agree.. we could probably spend hours discussing this 😂😂
There's certainly pros and cons to each. I also know a bunch of developers that would share your preference, many don't even like CSS at all.

As a sidenote, I'd never use web tools to write complex applications. That's why I stick to using JavaFX professionally, though I also recognize a lot of pros in the web stack. I think the best tool depends on what exactly you are trying to build..

[salmonb]

Thanks for sharing this, and you're right, no technology is the best for everything. My lack of CSS appreciation probably comes from my lack of knowing it in all details, with the most recent versions and tools. I'm glad you can enjoy it.

But yeah, let's close this topic, especially since my removal of the responsive card, there is no need for more debate on this now 👍

[dukke]

No, I'm the one that has to thank you for sharing this wonderful technology webfx.
I've been eager to see something like this, i.e. running javafx on the browser. On the browser not on the server. I think on the browser (like webfx does) has more advantages.

[salmonb]

Yes I think so, and that's why, even though it's much less mature than JPro and the JavaFX coverage is much inferior for now, I think it has some chance to be seen as more attractive. And probably many people feel this is the missing piece in the JavaFX puzzle. If WebFX meets with success, I won't be surprised this will really boost JavaFX. Let's dream! Without forgetting lots of work needs to be done to achieve this...

FYI the private project I was working on when I started WebFX is a booking system, and for big events, several thousands of people could be present at the opening time. That's why JPro couldn't be an option. Several thousands of JavaFX application instances running on a server, doesn't look very scalable...

[dukke]

Yeah that's exactly what I was going to write. Running stuff on the server (and even more so the way JPro is doing it) isn't scalable. Plus you'd have to spend much money for the servers.

[salmonb]

So, after removing these 2 elements, do you see any other controversial content?
Does the sustainable card for example makes sense for you?
The frameworks graphics can always be a source of controversy, but the general idea is to illustrate that the Java Desktop ecosystem is more stable than the Web ecosystem, and I think nobody can deny that, right?

[salmonb]

Yes we both agree with the advantage of static Type, but I think you are not aware of the direct impact this has on refactoring support.

Let's illustrate this with a simple example in JS:

function myFunction (o) {
   return o.myMethod(); 
}

class A {
    myMethod() {
        return 1;
    }
}

class B {
   myMethod() {
        return 2;
   }
}

When I ask Netbeans to go to the declaration of myMethod (I just press Ctrl key and click on o.myMethod()), it goes to A.myMethod()! So due to the lack of type, it's just assuming the type of o is A, whereas there is absolutely no guarantee about that, I could use myFunction with B objects. My code will be broken in this is the case if I rename B.myMethod() to something else. Such problems will never happen with a statically typed language where you explicitly declare the type of o.

Yes, refactoring is a concept neutral to the language in theory. For example, any human being who understands a code should be able to refactor it whatever the language. If I'm the creator of the above code, I will know the implicit, for example if myFunction() is meant to be used with A or B objects (or both), and therefore I will be able to refactor it. But you can't ask a human being to manually refactor a big application, it's quickly too much work! This is where refactoring tools enter the scene. But as shown above, they can't do a reliable job with a non statically typed language, because they can't have the same implicit understanding as a human being. Therefore these tools are not 100% reliable with such languages. But they are with statically typed languages, because the implicit becomes explicit, so the necessary knowledge becomes accessible to them.

Regarding Martin Fowler book, its chapter 4 called "Building Tests" begins with:

Refactoring is a valuable tool, but it can’t come alone. To do refactoring properly, I need a solid suite of tests to spot my inevitable mistakes. Even with automated refactoring tools, many of my refactorings will still need checking via a test suite.

This is just a confession that refactoring in JS is not a reliable process. You need to write tests to check your code is not broken after refactoring!!! Then he continues by justifying this is a good practice anyway to write tests. True, but I'm sorry, Java refactoring is much more reliable than that. I can refactor a Java application that has no tests at all, because it's a 100% reliable process in Java. I did it many times.

Perhaps a way to conclude this debate would be to make a twitter survey? I saw that it's now possible to have up to 4 options that people can click. Perhaps something like:

How would you describe your JS refactoring vs Java refactoring experience?
1- JS refactoring offers the same level as Java refactoring
2- JS refactoring is much better than Java
3- Java refactoring is much better than JS

What do you think?

[salmonb]

Or perhaps something with shorter replies, like:

What language offers you the best refactoring experience between Java and JavaScript?
1- Java
2- JavaScript
3- Same experience

[dukke]

Yes we both agree with the advantage of static Type, but I think you are not aware of the direct impact this has on refactoring support.

Let's illustrate this with a simple example in JS:

function myFunction (o) {
   return o.myMethod(); 
}

class A {
    myMethod() {
        return 1;
    }
}

class B {
   myMethod() {
        return 2;
   }
}

When I ask Netbeans to go to the declaration of myMethod (I just press Ctrl key and click on o.myMethod()), it goes to A.myMethod()! So due to the lack of type, it's just assuming the type of o is A, whereas there is absolutely no guarantee about that, I could use myFunction with B objects. My code will be broken in this is the case if I rename B.myMethod() to something else. Such problems will never happen with a statically typed language where you explicitly declare the type of o.

Yes, refactoring is a concept neutral to the language in theory. For example, any human being who understands a code should be able to refactor it whatever the language. If I'm the creator of the above code, I will know the implicit, for example if myFunction() is meant to be used with A or B objects (or both), and therefore I will be able to refactor it. But you can't ask a human being to manually refactor a big application, it's quickly too much work! This is where refactoring tools enter the scene. But as shown above, they can't do a reliable job with a non statically typed language, because they can't have the same implicit understanding as a human being. Therefore these tools are not 100% reliable with such languages. But they are with statically typed languages, because the implicit becomes explicit, so the necessary knowledge becomes accessible to them.

Regarding Martin Fowler book, its chapter 4 called "Building Tests" begins with:

Refactoring is a valuable tool, but it can’t come alone. To do refactoring properly, I need a solid suite of tests to spot my inevitable mistakes. Even with automated refactoring tools, many of my refactorings will still need checking via a test suite.

This is just a confession that refactoring in JS is not a reliable process. You need to write tests to check your code is not broken after refactoring!!! Then he continues by justifying this is a good practice anyway to write tests. True, but I'm sorry, Java refactoring is much more reliable than that. I can refactor a Java application that has no tests at all, because it's a 100% reliable process in Java. I did it many times.

Perhaps a way to conclude this debate would be to make a twitter survey? I saw that it's now possible to have up to 4 options that people can click. Perhaps something like:

How would you describe your JS refactoring vs Java refactoring experience?
1- JS refactoring offers the same level as Java refactoring
2- JS refactoring is much better than Java
3- Java refactoring is much better than JS

What do you think?

I understand what your saying about javascript not being a type safe language and the impact that it will have on refactoring. Though I'm not sure the impact will be that big and you still need to consider that not many people use vanilla javascript nowadays. They probably use Typescript or whatever..

I'm not a javascript expert though so I can't say I'm also 100% I'm right about this (I've worked much more with Java).

I like the idea of concluding this debate. We might not be able to agree 😆
I like that idea of a survey though the problem is that, for instance, in my case my twitter followers are probably going to be 99% Java programmers. Besides being biased towards Java they're probably not going to be experts in javascript either.
Do you know anyone who is a javascript expert? I can ask some guys I know that work professionally in web, if you'd like?

Alternatively if you want to close down this "issue" because you have other priorities or something (I don't want to make you waste to much time if you think this is not that important) you can decide what you think is best 🙂.

[salmonb]

Yes of course, everybody is free to have different opinions, everybody do different things, in different ways, and have different experiences. The point is therefore if most of the audience will see the point about the advantage of Java refactoring (like me) or not (like you).

No problem if your followers are Java developers as this is our audience target, this is actually exactly what we need! It's not a global & neutral survey.

I suggest to do a first one with Java vs Javascript refactoring. If Java is not the winner from the survey, then I will have to remove the point from the website. If Java is the winner, then we can make a second survey Java vs TypeScript regarding the point you raised. What do you think?

[salmonb]

As discussed at the end of this thread, I suggest to split the discussion by topics (as suggested by Pedro).

So I invite you on this separate thread #3 to continue talking about the refactoring point.

[dukke]

I was just checking the website on mobile and it doesn’t seem to work very well there. It doesn’t scroll well. I was browsing on Safari on an IPhone 11

[ivan-velikanov]

Same with my computer, it's a Aspire E1-731, but I upgraded it with a SSD & 8GB RAM! 🤣

I have a similar story. My present laptop is worth ~$100, it is second hand. The previous one I used for 10 years. Electron apps are a pain to be honest. One of the single most compelling reasons I never want to even consider going along that route.

[dukke]

Regarding UX, I can either embed everything in a JavaFX scrollPane and do it differently by intercepting the scroll events, or just simply display the hint on mobiles for a very short time and fade it (the later is of course much easier to implement).

"Les cordonniers sont les plus mal chaussés" 😄 It's a French expression, English would say something like "shoemakers children are the worst shod".
My phone is not that old (2018) but it's not a powerful one. Here is its benchmark score: https://browser.geekbench.com/v5/cpu/5526437
Same with my computer, it's a Aspire E1-731, but I upgraded it with a SSD & 8GB RAM! 🤣
And usually I keep each of my device until death, and only then I buy a new one.
One advantage is that I can see much better when a program I write is slow. Perhaps that helped to make WebFX fast 😆

If you put everything as is will the browser add scrollbars automatically? That is, assuming the content will be bigger than the browser window..

Yeah we have a similar expression here "casa de ferreiro, espeto de pau" which can be translated to something like "In the home of blacksmith, tools are made of wood". 😆
Yeah I can relate to that, my personal business site sucked for a long time.. I've been trying to make it better recently but time is always short to do it.

[dukke]

Same with my computer, it's a Aspire E1-731, but I upgraded it with a SSD & 8GB RAM! 🤣

I have a similar story. My present laptop is worth ~$100, it is second hand. The previous one I used for 10 years. Electron apps are a pain to be honest. One of the single most compelling reasons I never want to even consider going along that route.

that's one of the advantages of javafx, better perfromance and less memory consumption, I think.

[salmonb]

If you put everything as is will the browser add scrollbars automatically? That is, assuming the content will be bigger than the browser window..

WebFX completely disables the standard browser scrollbars as this is not the standard JavaFX behaviour, so it just emulates the JavaFX scrollPane, whatever its location in the scene graph. However I personally don't like the standard JavaFX scrollbars because they reduce the viewport when they appear. I prefer when the scrollbars are semi transparent and just overlay the viewport without reducing its size (I find this approach more modern, and also with much less hassles for the developer, a shame JavaFX doesn't offer this mode in ScrollPane - perhaps I should submit an issue). That's why so far I mapped the ScrollBar to a JS library (https://github.com/mdbootstrap/perfect-scrollbar), even if it's a bit hacky and I shouldn't probably do that in the WebFX mind...

[salmonb]

I invite you to continue this discussion about the website scroll in this separate thread: #5

[dukke]

BTW, another great aspect I like about WebFX is that the site loads really fast.

[salmonb]

Yes, I was amazed when I got the that performance score 😄
And that's why I want to keep the lazy initialisation. Initialising the cards only when they become visible is not really perceptible on a computer, but it is on mobiles... One solution perhaps is to initialise all cards when running on mobiles (better to wait a bit longer the first display than having bad scrolls).

[dukke]

I was checking the card with the title “Magical”. Would it be better to start off that card by focusing on saying that webfx runs in the browser as opposed to other solutions and so is highly scalable (what we talked about yesterday)? As opposed to other solutions that are running on the server and so not scalable.

[dukke]

I can create a mockup of the site in photoshop at some point first.. I'm used to doing that when I do Design work. If you guys agree.
That is, before we actually code, since coding takes the most time and I think it's better to postpone that before we have everything well defined.

[dukke]

Yes, I am aware of the CAD application you made. To be honest, the entire Java (specially JavaFX) ecosystem feels like a village, you know each person by name or their work, you can count people on your fingers. It is just that programming in general became more like a hobby than a profession for me during the last decade, and lot of my work has been in a different field.

Yes I agree, I think that happens because desktop is a niche. Not the entire programming field. I've been working in desktop since before the IPhone came out and I can see a big change after that. Desktop became a niche. Though that doesn't mean it's a bad thing, desktop apps still have its place. Especially for productivity apps that require good performance, memory usage, etc..

And when I say it's a niche it still means a good thousands even potentially millions of developers, though a lesser number than web and mobile developers I think.

[ivan-velikanov]

@dukke

I can create a mockup of the site in photoshop at some point first.. I'm used to doing that when I do Design work. If you guys agree.

Yes that will be nice.

I am more concerned about the narrative - the content (text) and the story. If the words are right, the correct visuals will automatically come has been my experience. I feel - people don't remember product specification details - pros and cons, as much they remember stories.

And these are some facts which need to be documented. WebFX might be just a solid new beginning. But there are always news things coming out. Like the Jetbrains people give a nice DSL for writing html and react in kotlin, and then you can do kotlin to js also. Essentially what they are trying to do is replace js with kotlin. This has been something I have been trying of late with another hobby project - a html dsl in java, a css dsl in java, java to js using jsweet, and finally a java dsl for reactjs. Similary I know Jeff did amazing work in Snapkit. Then Jaroslav Tulach made bck2brwsr which got supreseded with TeaVM which we are using here. Chreepj brought swing to the browser, and I should also mention JHipster. etc. etc. So there are many who have tried various things, everyone shared a common story. They liked java and did not like the popular tools, and wanted to use java to get their work out in the web - be it like a webapp or even a webpage. It is a small community a bunch of people we can count in fingers. I feel that entire javafx community would come together, and standardize and organize all these efforts. Because everyone needs it and wants it. They are either developing their own solutions or searching for it.

Yes I agree,I think that happens because desktop is a niche. Not the entire programming field. I've been working in desktop since before the IPhone came out and I can see a big change after that. Desktop became a niche. Though that doesn't mean it's a bad thing, desktop apps still have its place. Especially for productivity apps that require good performance, memory usage, etc..

I agree 100%.

[dukke]

..And if you look at number of downloads of javafx or scene builder they are on the good thousands so still a big number.

And of course Java is, on many sites, considered the most used programming language which means there are millions of Java developers out there. So I wouldn't say the entire Java ecosystem is a village and that you can count the number of people with your fingers. There's probably going to be millions of Java developers out there. A big audience that can potentially decide to use webfx and javafx. 🙂

[salmonb]

With still the idea to split this discussion into separate threads, I invite you to:

• continue talking about the target audience here: What audience should the website target? #6
• continue talking about new content for the website here: New content to add to the website #7

Thanks Pedro for proposing a photoshop mockup. I was just wondering if this will allow a collaborative work. Ivan was proposing Google slides for this reason. Perhaps should we include this point in the tools discussion? #2

If I forgot some discussion topics, feel free to open new discussion threads as well!

[ivan-velikanov]

In another topic you had written

but the WebFX demos (and the future website) reside in a serverless world (namely Netlify)

Only today this actually occurred to me. I had taken this for granted.
In the preview website you can (and probably should) emphasize that WebFX is a JAMStack, and mention Netlify etc. also. Also I would like to explain WebFX as - "Java Getting Back to Browser."
This is another narrative I would like to be mapped to what people conceive of WebFX.

So in this card

I might want to add the phrase - "Java is Back to the Browser" and hyperlink this phrase to an article explain (in brief) the history of web, from Netscape, to RIA, to applets, flash, GWT, then Steve Jobs kill button, then standardization, (in parallel) node.js, Angular, React, Vue, ..... now very recently I think they officially announced that applets support will be completely removed from standard java distribution, to now WebFX .... Java is back to browser. This story will explain the whole ride, ups and down, and the torture of having to cope up with 10s and 1000s of every changing tools ... and finally time has come Java is again back to browser and it is going to stay.

[salmonb]

I'm not sure we can say WebFX is a JAMStack, as my understanding about JAMStack is that it still needs a server to run each page, but they are pre-built as static files, so faster to deliver than a dynamically generated page.

WebFX is a SPA technology, which renders pages even more faster (no server call required between pages because everything is generated from JS), only the first page (actually the whole app) is initially loaded from the server.

But yeah, "Java is back to the browser!" is a good catch phrase. I wonder if a good place for it wouldn't be at the end of the first card (to replace the "JavaFX shall become the first major desktop toolkit that can be transpiled to the web" page that we recently removed). Or do you think it's better in the second card "Java full-stack"?

[ivan-velikanov]

I'm not sure we can say WebFX is a JAMStack, as my understanding about JAMStack is that it still needs a server to run each page, but they are pre-built as static files, so faster to deliver than a dynamically generated page

Then could say,

WebFX is not just a Netlify compatible JAMStack, it is much more. WebFX is a SPA technology, which renders pages even more faster (no server call required between pages because everything is generated from JS), only the first page (actually the whole app) is initially loaded from the server.

JamStack and Netlify are keywords that the visitor should notice. These keywords will help him understand that WebFX allows them to run java web-applications for free, and we are not talking about GWT or other frameworks which Java desktop/mobile app developers will generally not be familiar with.

[ivan-velikanov]

But yeah, "Java is back to the browser!" is a good catch phrase. I wonder if a good place for it wouldn't be at the end of the first card (to replace the "JavaFX shall become the first major desktop toolkit that can be transpiled to the web" page that we recently removed). Or do you think it's better in the second card "Java full-stack"?

We can replace this - "JavaFX shall become the first major desktop toolkit that can be transpiled to the web"

There should be a long blog post on - "Java is back to the browser!" starting from probably 1995. Everybody tried and did their part. But finally only now we can really say that "Java is back to the browser!" in real sense.

The Java Applet. JavaFX etc see also/external links section in wikipedia can eventually include a link to WebFX.

[salmonb]

I invite you to continue this discussion here: #7

[dukke]

What do you guys think about creating an issue or something for each of the things we are discussing?
I feel this issue is getting a bit too filled up and it's starting to be hard to navigate through it..
Or potentially even use some other means or platform to discuss things..

[ivan-velikanov]

Without a second thought - if it is possible - I would say atlassian confluence.

Other goodies like jira + maybe slack, and even a weekly conference call would be nice to have 😄

[salmonb]

Regarding Github issues, I think we should open issues only for concrete actions on the website, once most of the reflection has already been discussed. I see them more like concluded action plans than open line of thoughts.

But I agree it's becoming difficult to follow. We can move out of Github if we can't achieve what we want here. But perhaps we are just misusing the Github discussions and should have different discussion threads for the different topics (as Pedro suggested) instead of this single one and it will be easier to follow. For example one thread for the refactoring point, one for the new card, one for the target audience, one for the tools, etc... Should we try?

So I invite you to continue on this new discussion thread about the tools to see how it goes: #2

[dukke]

Thanks for splitting the discussions up into issues 👍

[dukke]

I was thinking about this more the other day..

I think you @salmonb have already said it too. I wonder if the focus should be more on the build tool and on webfx itself than on the website?

Just the other day someone mentioned webfx on twitter and someone else (a highly considered developer from the javafx ecosystem) mentioned: "Oh but it doesn't support javafx default controls does it?"
I think the fact that webfx doesn't yet support javafx CSS is going to be a major drawback for adoption, for now.
Means most apps won't be able to use webfx and standard javafx controls won't work.

Perhaps our effort should be focused more on developing webfx itself? And also on the build tool to allow others to use it so that we raise excitement on webfx. If there is a relatively simple way to build a javafx app using webfx into an app that runs on the web, we will start to see examples on the web of javafx apps built with webfx which will bring free publicity (even if they are just simple demos).
I myself have an interesting idea that could bring good publicity to webfx that would require webfx, and once the build tool is created I could realize that idea.

Perhaps a simple site just showing the demos would be enough for now? Later we could come back to this discussion.

[salmonb]

Yes I know. My approach is basically to say "Hey, look what I discovered: it's definitely possible to build a JavaFX transpiler with GWT! Look what we can already do! Now I need help to finish the job". Some people who understand the potential of WebFX, and the benefits for their future projects, will help. Some others may criticise the project first because of its insufficient coverage, but it doesn't matter, because the potential is already there, and it's just a question of effort to transform this potential into reality. I don't see major obstacles to this.

So yes, good point, our first target should be contributors. At the beginning I thought I had to finish the website and use it to attract contributors, but it seems some contributors are already there and happy to help. That's why I'm focusing now on the build tool. Once finished, I will start the Early Access Program to invite contributors. We will continue building WebFX step by step, and do demos for each passed step. This is how I think WebFX can become more and more attractive, and finally a viable product for general users.

Regarding the website, yes, I'm happy to make the first version as simple as possible, and use it first mainly as a communication tool to attract new contributors. Then we will improve it progressively for more and more general users. I started a new thread to discuss this point: #10

A last point to discuss perhaps is how to introduce the technology. Is it a tool that is meant to transpile existing JavaFX projects, or "just" a new way to write Web apps in JavaFX. I think we should present it the second way. And prevent people having too much expectation regarding the first way (making a Java app compatible with GWT is often a big job already).

[dukke]

Yes, agreed, there is a lot of potential for this technology. The demos you already have on the site are awesome and run really fast! I think just showing them would probably be enough to attract attention?

I think the biggest value proposition of a technology like webfx or JPRO (or gluon tools to create mobile apps for that matter) is to grab an existing javafx app and run it on the web without much change. Until webfx provides that, I personally feel it's going to be a bit though to "sell" it. Basically provide the "Write once, Run everywhere" (WORA) dream. There are already tools that allow you to use Java to write web sites (e.g. Vaadin, etc) so I think actually being able to grab a javafx app and run it on the web mostly unchanged would be key. You can already achieve that with JPRO, problem is that, unlike webfx, it runs everything on the server which can have a bunch of downsides, like we discussed.

Anyways, I'd like to emphasize that what you have achieved so far is great. So, nice work so far!

[salmonb]

I'm afraid to tell you that your dream (transpiling any JavaFX app without any change into JS) is impossible. Because it requires 100% Java & 100% JavaFX compatibility. GWT doesn't provide 100% java compatibility, so how WebFX could? And it's impossible to achieve because the browser sandbox is more restrictive than the desktop (ex: files) and single-threaded (so how can you transpile apps that use threads?). Also GWT doesn't support reflection and some other Java features. That's why GWT has its own ecosystem, which is a subset of the Java ecosystem.

So WebFX also can only have its own ecosystem, which will be always a subset of JavaFX applications (GWT compatible in particular). And regarding the JavaFX coverage, I won't wait to reach 100% to start WebFX (otherwise let's stop the project right now!). And I count on the contributors to progressively reach a decent percentage.

So clearly JPro is superior to WebFX regarding the portability of existing JavaFX applications. However, it has its own limitations due to requiring a server (cost + not scalable), and I think these limitations (especially its inability to scale) are unacceptable in most of the cases. So there is no perfect solution to run JavaFX in the browser. WebFX and JPro have both their pros & cons (mainly scalability vs portability, but also free vs not free).

So yes, you loose a consequent portability with WebFX, but you gain something that I think can be viewed in many cases as superior to the lost when your application also targets the web: WebFX is the only WORA ecosystem for JavaFX that offers the web platform as most of people expect (no plugin, no server, scalable) - in addition to the desktop & mobiles platforms (thank you Gluon), and all of this from a single code base.

Regarding other Java client-side technologies like Vaadin, WebFX differs by being based on the JavaFX API with all the advantages this implies (more people already knowing JavaFX, well documented, much faster than web technologies on other platforms - cf mandelbrot demo). Because I guess Vaadin uses a solution like Electron for the desktop.

Personally, I will be happy to write my front-ends (and web back-ends) with WebFX and have all the above advantages. So I just bet that I won't be the only one! Otherwise like I said, let's just stop the project right now! 😄

[dukke]

Hi @salmonb

I meant ideally, I think, the goal should be to walk towards 100% cross-platform support without much code changes. Though I agree some things are very difficult or impossible, similar to what happens when porting a javafx app to mobile or even from Windows to Mac (Mac's System menu bar that doesn't exist in Windows, etc)..

(Would it be possible to use web workers to port Java threads?)

There's always going to be adaptations that need to be made, the less the better but sometimes they are inevitable. I agree.

One first thing, which might possibly be easier ("easier" being an overstatement) to achieve would be CSS support, though yeah I agree with you performance might compromise this possibility.

Otherwise like I said, let's just stop the project right now! 😄

No please. I don't want to discourage you in any way. Like I said what you've achieved here is fantastic, more so given it's a one person effort.
Keep at it, so far what's been achieved is amazing.

Cheers and thanks for sharing this.

[salmonb]

No worries, was just joking, I will continue and we will see what's happening... 🤞

Would it be possible to use web workers to port Java threads?

No, because web workers have much less abilities than Java threads. They are more like separate applications than threads. So first drawback, you need to split your code and create a specific independent application for your worker. This is a big constraint for the developer, and the main reason why you can't just map a Java thread to a web worker. Also another bad consequence of this is that it's much slower to start (as it needs to first load its specific separate JS code - see how the Mandelbrot demo thumbnails are slow to start computing) while compared to this, a Java thread starts in an instant (see how they start immediately in the Java version of the Mandelbrot demo). Another consequence is that it has no access to your original application context (as opposed to Java thread). It's a huge drawback! And because of this you need to write some specific code to communicate between the original application and the web worker, using the web worker async message API (which in addition requires you to serialise your data in JSON). That's also a big slowing factor which explains why, once started, the Mandelbrot web version is about 4 times slower in frames rate than the Java version (even using WebAssembly).

So because of the above, the approach in WebFX is the exact opposite: mapping web workers to Java threads. WebFX provides a cross-platform web worker API that is finally mapped to Java thread in Java (=> fast start up, no real serialisation). But the developer needs to think "web worker" first with all the above constraints so it can work in JS.

That's another illustration why 100% compatibility with existing JavaFX application is impossible.
But WebFX tries to define a WORA where you can write 1 single code base that still gets the best of each platform.

BTW you may have not noticed my last input in #3 as you have not joined it yet.