I've made one change and one fix to lookout for in the upcoming build:
Type Checking
CompilerJs now checks all types referenced to verify they have been marked with @Js. You likely have a few places where you'll trigger that inadvertently - so its a warning for this build. Will elevate to a compiler error in the following build.
FWT: Add shortcut with setters
If you do any JS FWT work, the compiler wasn't properly handling one case, which will now result in a runtime error:
EdgePane
{
// using both setter and add shortcut - compiles fine - but
// will now throw an "Already parented" exception at runtime
top = Label {},
}
SlimerDudeFri 24 Feb 2012
A silly question I'm asking out of curiosity, why do types have to be explicitly marked with the @Js facet? It's bound to be obvious but there's no reasoning on the Javascript page.
brianFri 24 Feb 2012
Its been a topic of much conversation actually. In general we find there are two kinds of pods. Libraries like gfx and fwt are completely portable to JavaScript and actually tagging each type is non-ideal. But in most cases, we find a typical pod has both server side and client side code mixed together. Separating the code into two pods would be awkward, and we don't want to waste bandwidth and compilation time to have the browser receiving code we know won't be used (and often wouldn't work anyways because its multi-threaded, needs the file system, etc). Unlike the JVM, the special characteristics of JavaScript where download size and code size is still quite critical, we've forced JS to be opt-in. Still at some point it would be nice to mark an entire pod as Js.
SlimerDudeFri 24 Feb 2012
That's interesting, I hadn't thought about using Fantom to generate Client / Server web apps...
Is it possible to use Fantom's Actor model to coordinate message passing to / from the browsers? I'm thinking it'd be a cool means of distributed computing...!
brianFri 24 Feb 2012
Is it possible to use Fantom's Actor model to coordinate message passing to / from the browsers? I'm thinking it'd be a cool means of distributed computing...!
Not really. I think these days the best design is to formalize a clean HTTP API for your server side code. Then have clients interact thru that. That is how we have designed all our systems, using Fantom to write both server side and the client side code that runs in the browser.
andy Thu 23 Feb 2012
I've made one change and one fix to lookout for in the upcoming build:
Type Checking
CompilerJs now checks all types referenced to verify they have been marked with
@Js
. You likely have a few places where you'll trigger that inadvertently - so its a warning for this build. Will elevate to a compiler error in the following build.FWT: Add shortcut with setters
If you do any JS FWT work, the compiler wasn't properly handling one case, which will now result in a runtime error:
SlimerDude Fri 24 Feb 2012
A silly question I'm asking out of curiosity, why do types have to be explicitly marked with the
@Js
facet? It's bound to be obvious but there's no reasoning on the Javascript page.brian Fri 24 Feb 2012
Its been a topic of much conversation actually. In general we find there are two kinds of pods. Libraries like gfx and fwt are completely portable to JavaScript and actually tagging each type is non-ideal. But in most cases, we find a typical pod has both server side and client side code mixed together. Separating the code into two pods would be awkward, and we don't want to waste bandwidth and compilation time to have the browser receiving code we know won't be used (and often wouldn't work anyways because its multi-threaded, needs the file system, etc). Unlike the JVM, the special characteristics of JavaScript where download size and code size is still quite critical, we've forced JS to be opt-in. Still at some point it would be nice to mark an entire pod as Js.
SlimerDude Fri 24 Feb 2012
That's interesting, I hadn't thought about using Fantom to generate Client / Server web apps...
Is it possible to use Fantom's Actor model to coordinate message passing to / from the browsers? I'm thinking it'd be a cool means of distributed computing...!
brian Fri 24 Feb 2012
Not really. I think these days the best design is to formalize a clean HTTP API for your server side code. Then have clients interact thru that. That is how we have designed all our systems, using Fantom to write both server side and the client side code that runs in the browser.