Atlas Comments 6

Last night I looked a bit at Atlas and its Quick Start tutorials. With the risk of sounding like I hate Microsoft I’ll write down some thoughts…

  • Atlas is nice. I really like a lot of it. There are tons of things that I don’t like but the initial reaction is that this might end up pretty solid

  • Atlas tries to make a more C# and .NET like environment out of JavaScript and DOM. It is understandable because the general knowledge of js is substandard. Personally I would prefer they took a path more like MochiKit. MochiKit is heavily influenced by Python and it uses a lot of functional programming paradigms and it seems to focus on writing less code.

  • Atlas adds support for interfaces. This seems really stupid too me. JS is a dynamic language and if you really need interface checks just check if the methods are supported instead:

    if (obj.implementsInterface(IDisposable)) {
       obj.dispose(); 
    }
    
    if (typeof obj.dispose == "function") {
       obj.dispose();
    }

    This is often referred to as duck typing.

    If it walks like a duck, swims like a duck, and quacks like duck — it’s a duck.

  • No Opera support? Opera is a lot easier to support than Safari and it is superior to Safari in most of the cases.

  • navigator.userAgent.indexOf("Firefox") != -1

    This shows that MS are still living in the old era where there are 2 browsers. IE and now the up-and-coming-new-kid-on-the-block: Firefox. Have they heard of Netscape, Mozilla, Camino, Galeon, or Epiphany? These works out of the box if they test for Mozilla or Gecko instead.

  • Safari support. Good job!

  • The data binding features are nice. Both one way and two way :-) They also have template builders so it should be pretty easy to generate nice UI from data. The way that this seems to be exposed are as server side controls but the data binding is happening on the client side.

  • Microsoft are embracing JSON. I’ve been a fan of JSON for quite some time now (my only complaint with JSON is its lack of Date support). Any object (?) can be serialized to JSON. Deserialization is done using eval.

  • Hooking up a .NET web service is super simple:

    <script type="text/javascript" src="Service.asmx/js"></script>

    Then you can call it using the fully qualified name (as specified in the WSDL?). The data is sent using JSON.

  • XML is embedded in the HTML page using a script element with type set to "text/xml-script". This is a lot nicer than using textarea, xmp and other things we’ve seen over the years. However they should consider using "application/vnd.microsoft.script+xml" instead

  • They have defined yet another XML format for describing UI (defined in a script tag). Why isn’t XAML used? The rules for it are simple enough.

  • Is the XML format supposed to be hand written? It seems like it is only automatically generated from ASP. If it is, it requires you to define the objects and UI in 3 (2?) places (once in the HTML, once in the XML and once in the JS). If it is auto generated they should consider changing this format to JSON or generate the needed js code directly.

  • I didn’t know Safari exposed the prototypes of the DOM nodes. This allows you to add methods to all elements:

    HTMLElement = document.createElement("xxx").constructor;
    HTMLElement.prototype.setColor(s) {
       this.style.color = s;
    };

    By the way Opera supports access to HTMLElement directly, just like Mozilla

  • They’ve implemented DOMParser for Safari (Safari added native support for this in it’s latest update). Just when we thought it was a lost cause. The DOMParser uses an HTML element and sets innerHTML on that. That was too simple for us to come up with ;-)

  • Atlas tests for the presence of DOMParser to determine whether the user is using Safari or not. These kind of tests are not very bright. Now that Safari implements DOMParser the rest of the Safari compatibility layer is not applied. A better solution is to test for each part seperately and only emulate was is missing (if emulation is really the way to go?).

  • Pingback: b:log » Blog Archive Backbase compared with Microsoft Atlas()

  • http://weblogs.asp.net/bleroy Bertrand Le Roy

    Hi, and thanks for the feedback (I’m only discovering this blog post now while looking for some Safari documentation regarding their implementation of DOMParser). I think you’re right on many points and actually we know of most of them. You have to keep in mind that Atlas is currently not even beta (and I’m talking about the MS kind of beta, not the Google kind ;). There is currently some stuff in there that’s not so clever, most of which is just temporary (I hope). For instance, browser detection is currently done in a few places as you point out, and we are perfectly aware that this is not right (we know too well how hard it is to maintain the server-side BrowserCaps for ASP.NET so we definitely don’t want to go there with Atlas). For the moment, we’re only supporting three browsers and we’ve implemented it that way as a temporary solution. We’ll remove this kind of code progressively as we go forward.
    Interfaces are not the same as duck typing. The IDisposable example does look pretty stupid because there is only one method on the interface, but more complex interfaces enables you to do just one test and proceed with using all methods on it. Furthermore, both the concept of interfaces and several interfaces that we’ve implemented client-side are very familiar to .NET developers which are a huge part of Atlas users.
    Opera is indeed much easier to support, but we wanted to support the main Mac browser first.
    We’re supporting Date in our JSON serialization.
    We’ve tried to stay close to XAML syntax but it just doesn’t click for some of the stuff we’re doing (the browser is a peculiar environment as you know and we don’t have all the freedom the Avalon guys enjoy).
    One of the ideas behind xml-script is that we’re keeping the HTML layout very separate from the logic and behavior. That’s why a button is defined in the HTML (as a button, input, link or even any element that has onclick if you don’t care about accessibility) and in xml-script as a button control which attaches the “buttony” behavior to the element. We think it’s a great advantage in terms of designability. xml-script can be written by hand but it’s really meant to be generated by server controls or by a visual design tool such as Visual Studio.
    Glad you liked our little trick in our Safari DOMParser. It’s almost too bad we’ll have to remove this code now that it’s implemented natively.
    Cheers!

  • http://erik.eae.net Erik Arvidsson

    My problem was not that you are using browser detection but that you are testing for Firefox instead of Gecko. This leaves out tons of browsers for no good reason.

    If the xml-script is meant to be server generated you should switch to JSON or plain JS. This will improve performance a LOT.

    I still don’t like adding another layer on top of JS to do interfaces. I’m not convinced that there is a good cause for these in JS1.x. The scenarios I’ve seen can be solved using inheritance (abstract base classes) or by duck typing.

  • http://weblogs.asp.net/bleroy Bertrand Le Roy

    We can’t use JSON instead of xml-script among other reasons because there’s no way from JSON you can call property setters (which are functions), you can only set fields. Plain JS is out of the question because it’s very hard to generate and round-trip from a visual designer. XML is very easy to generate, tool and design, and the big perf bottleneck is not XML parsing and object initialization, it’s mainly DOM manipulation and rendering (so no, we would not gain a lot). Then again, there’s nothing that xml-script does that you can’t do in JS code, so if that’s your preference you’re absolutely free to do so.
    Abstract base classes are almost the same as interfaces except that you can implement multiple interfaces, whereas you can’t inherit from multiple abstract classes (at least not in Atlas). Duck typing is not sufficient in some situations: if a class implements a method foo, it may not have the same semantics as ISomeInterface.foo even if the names are the same. This may not be a big problem when you master all the components you’re using but it becomes very important when you’re building a framework or components that must integrate with other unknown third party components. Interfaces give to methods a concept similar to what namespaces are to classes. And as I’ve said before, we’re trying to be consistent with the .NET framework as much as possible.
    I hope this clarifies things.

  • http://erik.eae.net Erik Arvidsson

    Bertrand Le Roy wrote:

    “We can’t use JSON instead of xml-script among other reasons because there’s no way from JSON you can call property setters (which are functions), you can only set fields.”

    XML does not have property setters either (there are mutation events but that is not supported by MSXML or IE).

    “XML is very easy to generate, tool and design, and the big perf bottleneck is not XML parsing and object initialization, it’s mainly DOM manipulation and rendering (so no, we would not gain a lot).”

    You need to use DOM manipulations to extract the data from the XML.

    I’ve these things in a real commercial application and I’m not just speculating.

  • http://weblogs.asp.net/bleroy Bertrand Le Roy

    I was meaning HTML DOM modifications in this context.