For a couple of months Andy has been busy developing a compiler for Fan to JavaScript and recently has gotten core parts of FWT working in the browser.

For the last few days I've been hacking on a gfx implementation for the browser using the HTML5 canvas element. We now have almost full fidelity b/w desktop SWT and javascript in the browser for the latest versions of Firefox, Chrome, and Safari. Hopefully we can round out browser support with some of the projects out there like excanvas and canvas-text.

Couple minor issues:

• I didn't do arc support, if any of you vector graphics whizs want to try your hand at the correct pathing code for arcs I would love a patch
• Firefox doesn't seem to handle textBaseline = "top" quite correctly
• There isn't font metric support, so I had to fudge height, leading, and descent based a percentage of point size (it is close, but eventually we might want to move to lookup tables for common fonts)
• We don't have async images all quite worked out yet (sometimes you need to hit refresh)
• You can't subclass Widget directly anymore, now you subclass Canvas
• I got rid of Graphics clipRect and drawPoint which really didn't make sense anyways

This stuff is all in the hg tip, although bootstrap compile is a bit messed up because of the List.map changes, so probably best to wait until I do a full build if you want to play. Then you can run the new examples/js/demo.fan script to write Fan scripts which compile into JavaScript.

Here is the original graphics demo running in both SWT and the "modern" browsers:

Way, very, cool. This is going to be something.

Wow.

You can still see quite a few quirks between the browsers, not to mention between SWT and the browsers, but only a few :-)

Exciting stuff! Fan is proving to be a "low-risk" platform, because you can target each of the major platforms (C excepted). The seamless support for cross-compilation to desktop or browser will be a big selling point, I think (it is for me).

Super cool.

This stuff is all in the hg tip, although bootstrap compile is a bit messed up because of the List.map changes, so probably best to wait until I do a full build if you want to play. Then you can run the new examples/js/demo.fan script to write Fan scripts which compile into JavaScript.

So that's why I couldn't recompile. I was trying to do some basic testing before I sent my patch for #633--I'll send it to you now.

I've got this working in IE now using JavaFX. I'll post a screenshot when I have enough implemented to compare against the other browsers.

I've got this working in IE now using JavaFX.

Sounds cool, but I would think excanvas, Flash, or Silverlight might more likely be available, or am I missing some considerations?

ExCanvas actually has alot of issues, mostly since its backed by VML. The current version does not work in standards mode IE8, which makes it a non-starter for us. Flash is definitely more pervasive - but a key element to this design is good interopablity b/w the plugin and the DOM. This way we only have to create a "shim" in the plugin. Then all the Fan code that gets compiled to Javascript works transparently b/w browsers that support canvas, and ones that do not.

With that in consideration I could have gone with either Silverlight or JavaFx. I think both would have worked equally well given the task at hand. So I just went with JavaFx since I figured I would have more experience there (turns out Java knowledge isn't all that useful with JavaFx).

Thanks for the explanations. I'd still keep the Flash option in mind, though. I think some kind of interop is possible, but I don't have direct experience. I just found this interesting stats site, by the way. I don't know where JavaFX market share is.

Yeah that's about what I would expect I think. We originally used Flash for essentially this purpose earlier this year, and the interop is no where near the parity of Silverlight/JavaFx. Though given this is only an issue for IE, I'm not terribly concerned about it either way.

Okay. Thanks for the history on that. My main concern is just that IE still has big market share, so apps just need to work there. Maybe multiple implementations will eventually be valuable. On that subject, it would be a blast (abstractly speaking, since it would require time) to do more implementations of canvas (a la excanvas) for the various plugins. Then anything interfacing to canvas would "just work" (or at least have higher chances of working). Maybe someone else will do that eventually. One can hope.

Wow!

Now this is something I can't wait to get my hands on, this is so exciting! Do you think it would be fair to say that Fan(tom) is ready to be used to build a complete website?

I can't wait to see what the future holds for Fantom.

Great work guys!

Jase, the web site you are using was written entirely in Fantom ;-) Not using fwt and gfx, but still, it's battle-tested.

The standard module for making web pages was recently revamped in the last release. See the webmod pod for details =-)

@jase,

Most of the core Fantom distro is extremely robust and is solid enough to put an app into production. As tactics said, this website has been running for almost two years now with with the wisp web server. Some features like the JavaScript FWT are more along alpha quality, but even then we're building some pretty sophisticated data analytics/charting completely in JavaScript FWT for our startup SkyFoundry. If you do find a serious bug, we try very hard to get things fixed quickly.

That said, we are still changing the language and the APIs. We try to be careful about documenting all the breaking changes and providing a clean upgrade path for each build. But you have to budget some time to deal with the fluidity - the upside being that those who are writing Fantom code now have influence on how the language and APIs look before we lock everything down.