real-world apps in flapjax: browser compatibility and namespace pollution

[titto]

Hi,

reading the docs I see that flapjax has been used to build a few real-
world apps.


I would like to also use flapjax in production but I need to
understand how compatible flapjax really is with the major browsers.

Has any systematic tests been done? Is there a compatibility matrix
somewhere? I could not find it.


Another thing that worries me is the number of changes that flapjax
does to the top javascript namespace without worrying to check, from
what I can see, if it is overriding some existing definition.

All these new global names have a very good chance of interfering with
other libs, would it not have been preferable to adopt a jquery like
approach and put everything in a separate namespace?


Regards,

titto

[Arjun Guha]

> I would like to also use flapjax in production but I need to
> understand how compatible flapjax really is with the major browsers.
>
> Has any systematic tests been done? Is there a compatibility matrix
> somewhere? I could not find it.

We test compatibility by testing our demos with various browsers. The
old Flapjax website had a compatibility matrix. The new old omits it,
but we maintain a spreadsheet internally.

Before OOPSLA, we'll make another Flapjax release. For the release,
we'll rebuild the compatibility matrix, account for newly-released
browsers: Firefox 3.5, Safari 4, and IE8. We'll publish that matrix
on the Flapjax website.

>
> All these new global names have a very good chance of interfering with
> other libs, would it not have been preferable to adopt a jquery like
> approach and put everything in a separate namespace?

It would be better engineering, yes. I think we omit namespaces
because it makes our demos and examples shorter.

The released version of Flapjax exports all names to the flapjax
namespace:

flapjax.$B

This namespace is setup by the JsContracts tool. (I've just updated it
on Hackage. It should build without any problem.) In the Flapjax
source, if you look at fx/Makefile, you'll see how it's done.

I think you want it use a namespace and *not* use the top-level at
all. Right now, JsContracts does not support the latter, but its a
trivial patch.

Arjun

[titto]

On Sep 7, 6:17 pm, Arjun Guha <arjun.g...@gmail.com> wrote:
> > I would like to also use flapjax in production but I need to
> > understand how compatible flapjax really is with the major browsers.
>
> > Has any systematic tests been done? Is there a compatibility matrix
> > somewhere? I could not find it.
>
> We test compatibility by testing our demos with various browsers.  The  
> old Flapjax website had a compatibility matrix.  The new old omits it,  
> but we maintain a spreadsheet internally.
>
> Before OOPSLA, we'll make another Flapjax release.  For the release,  
> we'll rebuild the compatibility matrix, account for newly-released  
> browsers: Firefox 3.5, Safari 4, and IE8.  We'll publish that matrix  
> on the Flapjax website.

Great.

>
> > All these new global names have a very good chance of interfering with
> > other libs, would it not have been preferable to adopt a jquery like
> > approach and put everything in a separate namespace?
>
> It would be better engineering, yes.  I think we omit namespaces  
> because it makes our demos and examples shorter.
>
> The released version of Flapjax exports all names to the flapjax  
> namespace:
>
> flapjax.$B
>
> This namespace is setup by the JsContracts tool. (I've just updated it  
> on Hackage.  It should build without any problem.)  In the Flapjax  
> source, if you look at fx/Makefile, you'll see how it's done.
>
> I think you want it use a namespace and *not* use the top-level at  
> all.  Right now, JsContracts does not support the latter, but its a  
> trivial patch.

Precisely.

Any chance of having this fixed by the next release?

As it stands, it is relly too messy.

Regards,

titto

[Arjun Guha]

>
>
> Any chance of having this fixed by the next release?
>
> As it stands, it is relly too messy.

What would be a satisfactory fix? We used to have a function called
flapjaxInit that you needed to call in onload. flapjaxInit allowed
you to specify a custom namespace.

I'd rather not bring flapjaxInit back, since it's an extra line of
code that detracts from small, academic examples.

I'm open to suggestions.

How about something like this:

<script lang="javascript">
flapjaxNamespace = "myownflapjaxliveshere";
flapjaxDoNotExport = true;
</script>
<script lang="javascript" src="/fx/flapjax.js"></script>

So, if you don't specify flapjaxNamespace and flapjaxDoNotExport, it
will work as it does now. Does it look reasonable?

Arjun

[Leo Meyerovich]

How about:

<script src="flapjax.js" namespace="myContext"/>

-- If the attribute namespace is not specified, it plops fx into the global

    <script src="flapjax.js">

-- If the attribute namespace is the name of a global that already exists, it adds it to the global.

    <script>x = {}; </script>
    <script src="flapjax.js" namespace="x"/>

-- If the attribute namespace points to an unbound global, create it.

   <script src="flapjax.js" namespace="y"/>


- Leo

[therac25]

I don't know if people care too much about this, but adding this
attribute to the script tag, means the HTML won't validate

On Sep 10, 6:31 pm, Leo Meyerovich <lmeye...@gmail.com> wrote:
> How about:
>
> <script src="flapjax.js" namespace="myContext"/>
>
> -- If the attribute namespace is not specified, it plops fx into the global
>
>     <script src="flapjax.js">
>
> -- If the attribute namespace is the name of a global that already exists,
> it adds it to the global.
>
>     <script>x = {}; </script>
>     <script src="flapjax.js" namespace="x"/>
>
> -- If the attribute namespace points to an unbound global, create it.
>
>    <script src="flapjax.js" namespace="y"/>
>
> - Leo
>

[Arjun Guha]

Wait, so how does Flapjax figure out whether the namespace attribute
is set?

Don't tell me I have to walk the DOM!

Arjun

[Leo Meyerovich]

It's not hard;

var ss = document.getElementsByTagName("script");
for (var i = 0; i < ss.length; i++) if (ss[i].getAttribute("src") == "flapjax.js") { /* magic */ }

Works in IE8 and FFox, not sure about other versions.



Standards compliance is a good point; a version similar to Arjun's could work for those interested. Having a 'pretty' option seems like a good idea until the W3C provides a cleaner way (and hopefully is another push towards them doing so).

Finally, I'm not a user of the compiled version, but for those that do -- would it be useful to make the namespacing approach consistent?

- Leo

[Pasqualino Assini]

There is no need for the namespace to be customisable.

Just use the "flapjax" namespace.

Best,

titto

[Artyom Shalkhakov]

Hello list,

May I propose implementing a real module system for JavaScript?
(Or maybe just pick an existing one.)

I think it would solve the problem, as well as others, e.g.:
- packing and concatenating js files
- enforcing module contracts
- on-demand (lazy) module loading
- and possibly others

Cheers,
Artyom Shalkhakov.

2009/9/11 Pasqualino Assini <titto...@gmail.com>:

[Shriram Krishnamurthi]

> May I propose implementing a real module system for JavaScript?

Like this one?

http://docs.plt-scheme.org/reference/module.html#%28form._%28%28quote._~23~25kernel%29._module%29%29

Or like this one?

http://docs.plt-scheme.org/reference/creatingunits.html#%28form._%28%28lib._mzlib/unit..ss%29._unit%29%29

The problem is that "module" means about four or five different
things, and each of these seems to lead to different solutions.

Shriram

[Artyom Shalkhakov]

2009/9/11 Shriram Krishnamurthi <s...@cs.brown.edu>:

Can you provide a summary of each?

Talking about a "module", I mean something that contains a
bunch of declarations and helps to control their scope.

Something like Haskell's modules would suffice probably, but then again,
there are cases when you would like to treat modules as packages, not
just mere files. So there's a need for package management and deployment
also. In PLT Scheme there's "PLaneT", which I find great. (I'm working
through PLAI in my spare time, a great book, thanks by the by. :-))

Cheers,
Artyom Shalkhakov.

[Leo Meyerovich]

Pushing it to a group more invested in supporting composition of
libraries in JavaScript would be great.

Examining jQuery's system ( http://docs.jquery.com/Plugins/Authoring ),
which represents best practices for many, I see no benefit over what was
proposed (and view it as worse, actually). Similar for Ext. I am not
aware of a nice open source framework with robust library support, e.g.,
lazy loading in the style of Doloto or checking for collisions --
suggestions and reasoning?

It looks like the proposed (lightweight!) solutions -- which allow the
specification of a namespace object -- would accommodate those wanting
to quickly wrap flapjax as a plugin for other libraries without tying
developers to a particular one. When Flapjax is non-trivially used with
a library like jQuery, an adapter is written -- posting these adapters
(in the form of plugins for the particular framework) might scratch the
underlying itch here.

- Leo

[Shriram Krishnamurthi]

>> The problem is that "module" means about four or five different
>> things, and each of these seems to lead to different solutions.
>
> Can you provide a summary of each?

I should try to find a write-up that discusses all these things
already. In lieu of one at my fingertips, and assuming you don't want
to wait three years for me to reply (-:, here are a few of the
characteristics one might wish of something called a "module":

- modules for namespace management

- modules for separate compilation

- modules for representation hiding

- modules for parameterization

- modules for mutually-recursive parameterization

- modules for scoping meta-programming facilities

- modules with instantiability

Note that these aren't even mutually exclusive; a given module system
might satisfy more than one of these properties.

Shriram

[Arjun Guha]

> I see that there are a number of IE8 failures.
>
> What is the cause? Do you know what flapjax primitives are
> supported/fail in IE*?

All of Flapjax works in IE. However, keep in mind that a Flapjax program is just a JavaScript program. You can easily use some JS/DOM feature that IE/FF/Safari does not support.

That's the problem with the few demos that don't yet work in IE8. These demos don't use any special Flapjax functions. They just use FF/Safari-only functions. Naturally, this is unintended.


The few demos that do fail don't use any special Flapjax functions. Flapjax itself is designed to support IE8.

> Another couple of unrelated question:
> - what happened to the write/readPersistentObject primitives that are
> discussed in the paper?

Briefly, we got out of the hosting business. The primitives described in the paper describe an experimental server that better supports FRP clients.

> - and what about the isDetached property, that is also discussed in
> the paper but does not seem to be included in the last version?

The library calls it weaklyHeld. It's a bad name, since it makes it sound like a weak reference, which it is not. So, in the paper, we call it isDetached.
isDetached/weaklyHeld is an implementation detail that is not visible outside the Flapjax library.