|
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. |