One of Fantom's primary design goals from day one was portability between the JVM and CLR. Naturally we got to thinking, if we can run on both of the popular VM's, why not on JavaScript too? That would enable enormous opportunities for code reuse and greatly simplify the huge impedance mismatch of developing backend server code and user interfaces in the browser.

Unfortunately lack of resources led us to abandoning that goal soon after, so I could focus on implementing the CLR runtime. But our decision to make Fantom portable across VMs turned out to be a key component which later enabled us to create the JavaScript runtime with relative ease.

Around 3 years went by, as we toiled away in our free time molding Fantom into the language it is today. Along the way we picked up, fixed, and changed tons of things that made it easier, simpler, and more enjoyable to write Fantom code to solve our everyday problems. We also built the very first Fantom webapp - Sidewalk - which has been driving this site since April 2008.

Over the course of all this, something became really obvious: we had built this really great language and system library that enabled us to build sophisticated applications in a fraction of the time and effort as Java. But now we needed to build the frontend, and we couldn't use any of it. JavaScript is an awesome language, and its more than up to the task for lots of problems. But if you've chosen Fantom, you'd probably like to keep using all its features like static type checking, nullable types, real OO, the very complete system library, etc., throughout your entire application.

At this point, the CLR sys runtime was about 99% complete, I had just resigned from my job, and was very eager to dive into our new venture, the driving reason behind why we created Fantom. So I dusted off the JavaScript playbook, and started work again on getting Fantom running in the browser. The first results of that effort appeared a few months later.

Being able to write client-side code in the same language as my server code, and being able to reuse the same code across both environments sounds like a pretty powerful feature. But it didn't exactly feel that way in practice. Turns out there was another major hurdle preventing me from Fantom nirvana: HTML. Trying to glue our client side Fantom code into the HTML markup was forcing me to expose and deal with lots of implementation details in how Fantom maps to JavaScript.

Enter FWT, our cross platform widget toolkit. A traditional web app consists of lots of GET/POST page cycles to fetch and evaluate data on the server. But with such a substantial API available directly in the client, this was not particularly efficient. With a client-side widget toolkit, Fantom becomes an excellent platform for the next generation of rich web apps. Throw in the massive performance improvements V8, TraceMonkey, and others were making, CSS3 support, new HTML5 features like Canvas, and the timing could not have been better.

I ported the core of FWT to JavaScript, and continued work on improving the compiler and system library over the summer of 2009. Then we spent several months redesigning our SkyFoundry stack to leverage the new architecture. And it has worked out beautifully. Overnight how we approached building our UI changed. Our expectations for our user experience shot way up, while the effort to produce them shot way down.

I really think this has turned out to be one of Fantom's killer features. Simply compiling to JavaScript is a feat in itself. Throw in a very rich system library and it gets even better. But ultimately its our focus on solving this problem from end-to-end that really differentiates Fantom.

JavaScript has gone from a side project to being a primary runtime target. Its support will continue to be first-class. As browser vendors keep pushing the envelope of what can be done in a web app, Fantom will be in lock step enabling those features to developers. There's enormous upside to this platform, and I'm very eager to see how people will leverage Fantom in their own projects.

Great post, Andy!

We're also playing with Fantom and new HTML5 features, here just a very simple code browser with syntax highlighting and code folding features done in Fantom and HTML5 Canvas (no FWT) http://media.xored.com/styledText/ - credits to Yuri Strot [email protected]

-- Andrey

Very cool Andrey and Yuri!

Sounds great. Where can we see online examples of FWT ? How comes that the examples cannot be run directly in the fantom website ?

Good question rodrigob - I agree they should be on here. I'll put that on my todo list.

+1!

I want to see fansh running in it's own browser page!

On the subject of Fantom targeting JavaScript (one of my favorite parts of the language, for sure!) - is the @Js annotation really the best way to specify JS-targeted classes?

It's always struck me as inconsistent; in all other respects, Fantom code is agnostic to its build target, and details of what should happen when you build are confined to its pod/build config. Only in specifying which classes are JS-targeted does Fantom deviate from this paradigm (that I'm aware of) and it seems to be both inconsistent and a bad precedent.

Suppose in the future Fantom targets another platform for which specifying on a per-class basis. Are we then going to have @Js and @OtherTargetPlatform annotations on every class where we want to target both? And if there are three such targets, then up to three annotations per class? I mean, certainly in 2010 this is not a realistic concern, but I assume you guys want this language around for the long haul and the unpredictable future that comes with it.

So am I just missing something, or wouldn't it make more sense to specify JS-targeted files in the pod/build config, using a list of file and/or directory pattern matchers to specify which ones are JS-targeted?

I agree with rfeldman about the @Js annotation. It really looks like a bad idea.

I just found about Fantom, but now that I'm here, I'd like to comment that in the surface, phantom looks like it inherited java's server centric-ness. I say this because there are no visual samples, screenshots or demos to be seen on this webpage.

One ends up wondering if the list of widgets that appears in the docs (some of which speak of CSS and canvas) are only for the web, or are also for the desktop.

I also believe that if you want FWT to become relevant for desktop development, you'll need to pin a todo for eventually putting a lot more widgets in FWT. Even java's plain-old swing widgets seem insufficient to me today. Java-desktop shops have to purchase third party stuff like datepickers, google-like calendars (like MiG's), tree tables, and lots of stuff that web apps take for granted (like what you find on Ext). I understand it's still early for FWT and concurr with the phiolosophy of exploring first and getting it right before "bloating" it with features. I'm just saying that eventually, sooner or later, FWT wil need to be fleshed up if it is to become something serious for desktop development (which is where I believe it's most likely to be useful)

I agree with rfeldman about the @Js annotation. It really looks like a bad idea.

See discussion over in #1111.