Zef

Maybe he could have adapted an existing one, but I think the main issue was that parsers traditionally just quite when they find an error, language.js has some error recovery feature (naughty or) to proceed with parsing.

It's back up now.

Not sure this is the place for it (maybe ask on the google group?) But there's two ways:

screen root() { mydiv@<div/> script { mydiv.someplugin(); } }

mydiv will be bound to a JQuery object representing the div. You can also just do this:

screen root() { script { $("#div").someplugin(); } }

So generally your answer is: put it in a script { ... } block.

Generate your mobile web application using mobl. Then wrap it as a PhoneGap native app. They're complementary.

I think many people missed my main point. Here's another shot at explaining it better: http://zef.me/3753/planning-ahead-the-async-javascript-probl...

State of the art in parsing is SGLR (http://strategoxt.org/Sdf/SGLR) and GLL parsing

That's what I use. But Douglas Crockford suggests using a different way of building object hierarchies which he uses. I could ignore this, but Crockford kinda is one of _the_ Javascript guys, who, supposedly knows what he's talking about: http://javascript.crockford.com/prototypal.html

Alright. So now I want to iterate over all original keys, how do I do that (i.e. their original values, not the stringified version)?

Plus, a random object (that doesn't have a meaningful toString method) will probably result in something like "[object]" as a key, which would break when you use more objects like that as keys.

In my post I link to JSAN, which is exactly that: http://openjsan.org

It has its own module system.

Maybe I wasn't clear enough in my post, but I said this:

> and the good thing is that it does not require any changes in the Javascript language itself, nor its browser support.

As far as I'm concerned it would be fine with a standard library in a file (std.js, or base.js), that I would just include on every page, it does not have to be implemented in the browser at all. Maybe on the long term, for efficiency, but necessarily. Indeed, the nice thing about Javascript is that it is flexible enough to do this "ourselves". So I would say the "but what about IE" discussion is kind of irrelevant, unless there's some core Javascript features it doesn't support that we absolutely need.

Let me briefly tell you where I'm coming from. A month or two ago I started working on an O/R mapper for Javascript, built on top of the HTML5 SQL store (http://github.com/zefhemel/persistencejs). I wanted this library to be useable from any Javascript framework and supply an as "native" a Javascript API as possible. There were two problems that I came across:

1) What is the proper way to do OO? I read "JS: The Good Parts", but it discusses like 3 or 4 ways of implementing OO and variations on inheritance, each having different advantages and disadvantages, either using the new keyword or not etc. Personally I'm open to any OO style, just tell me which on to use. There was no obvious answer. There's a bunch of frameworks that offer utility objects to do inheritance "properly", do mixins etc., but I didn't want to buy into any framework in particular. So eventually I went with the constructor function (function MyObj() { }, new MyObj()) approach, manually solving inheritance problems as I went along.

If there would be a style, possibly with some utilities of doing OOP in Javascript that "everybody" would agree on, I wouldn't have had this problem. I'd just say "ok, let's rely on this std.js/base.js and it's obvious how to do it". Everybody would understand my code, because they'd use the same style as well. Sure, it's a very powerful thing that we can do inheritance in 4 different ways, but it doesn't simplify communicating the fact that we're trying to implement inheritance, or how to use a particular constructor function (should I call new Bla() or just Bla()?).

2) I needed to implement the observable pattern, I need to respond to changes in objects. Some JS frameworks contain an implementation of the observable pattern, but I don't want to rely on any framework in particular, so what should I do? I ended up implementing a lightweight one myself, which is included in the library. A bit of a waste of effort, plus of code size when somebody uses persistence.js together with another framework that also contains an observable pattern implementation.

The observable pattern is another example of a construct that's common enough to be in such a standard library. If we decide on a particular implementation, we can all utilize it without being too dependent on larger frameworks. We only have a dependency on the small standard library.

I'm currently working on a larger HTML/Javascript problem and there the modularization problem popped up. I want to declare module dependency and have them automatically be loaded. Again, Google Closure, Dojo and YUI provide ways to implement this, but I have been using jQuery so far, should I switch or add Dojo/Closure/YUI to my project, just to get the modularization features? That seems a bit excessive.

If we would have agreed upon modularization features in a standard library that all the frameworks used, I wouldn't have this problem.

My response to your criticism: http://zef.me/2355/a-when-rails-fails-follow-up