Which Frameworks Abstract Away the DOM?

views:

223

answers:

+1 Q:

Which Frameworks Abstract Away the DOM?

A recent twitter post I've seen made some comment to the effect of "the DOM is Javascript's ugly date".

I tend to think that the DOM is a horrible way to define user interfaces and certainly in the context of multiple browsers with their quirks I find trying to build sophisticated web apps with complex view layouts to be a completely frustrating experience.

I would imagine anyone who has spent time in the non-web application programming world would likely agree.

So I have a multi-part question: if you are a web developer or designer, how do you feel about the DOM? Do you think the push towards the <canvas> tag in HTML5 is the long-term death knell for the DOM in sophisticated apps?

Will a programmer who has little experience in the desktop world easily transition away from HTML? When should a programmer start learning things like the 2D drawing API used in the <canvas> tag?

Finally, I know that there are some existing, current frameworks that abstract away the DOM from a developer. Two that come to mind are ExtJS/ExtGWT and Cappuccino. What are some other existing frameworks that focus on making the browser world more like the desktop ones in a cross-browser way and don't rely on plugins?

Okay, someone challenged me to say why I didn't like the DOM, so I'll edit the question and explain more.

I try to practice DDD in my role and I understand the third chapter of Evan's book about strategic design is pretty important for the well-being of my employer. As a developer, I want to spend my time implementing features that improve my company's core domain, I don't want to spend time with templates and DOM manipulation to put together a user interface. How much work do I have to do to layout a page or a screen, or put form widgets in my UI? In the desktop world, I tend to find it easier to get past the UI trivialities and back to working on the things in my company's business domain. I am able to work faster and get to the business logic that actually makes my company money. Am I the only person who feels like HTML and DOM gets in the way? Why did I read a twitter post by a well-known developer wherein he bitches about the DOM? I know I've heard this complaint before and I want to get an idea of what happens when the canvas tag and HTML5 is available in most browsers.

Also a concern that this is a discussion question and has no "right" answer is false IMHO. A "right" answer will be one that shows some thoughtfulness and at least an acknowledgement that there is something different about HTML5. After all, we all went to high school where we were asked to "compare and contrast".

+1 A:

I think the DOM is fine... its the lousy implementations that cause issues.

Take your pick of JS libraries... (e.g. jQuery) and abstract away the pain and bugs.

As for making the web more like traditional desktop apps you can use Ext.js, YUI or similar to generate controls with more flexibility...

scunliffe 2010-02-09 04:33:15

jQuery doesn't abstract it away, it makes it less frustrating. I'm talking about being able to manipulate and work with the browser window with a different paradigm besides tree-based markup language.

RibaldEddie 2010-02-09 04:36:42

@RibaldEddie: What you're asking for is Cappuccino, and it'll never happen. You're complaining about having to do work and asking for someone to create a WYSIWG for you to work with the DOM. Compare the DOM to something like aerospace engineering. Doesn't seem so hard now, right? Good, because it's not likely to move the direction you're asking for.

coreyward 2010-02-09 04:42:44

@coreyward: "What you're asking for is Cappuccino, and it'll never happen." I don't understand what you mean by it'll never happen. It exists and a lot of people seem to think it's pretty neat. Please note that I don't think people won't want to make their interfaces look and act uniquely. The fact that Cappuccino looks like the Mac's interface isn't a plus, but it's also not a necessary condition for a framework to be that way.

RibaldEddie 2010-02-09 04:54:05

jQuery certainly abstracts away the DOM, although it isn't an especially high level abstraction.

You might be interested in the Google Web Toolkit which lets one write Java code which is compiled into Javascript.

David Johnstone 2010-02-09 04:39:54

How does jQuery abstract away the DOM? It provides a set of methods for interacting with the DOM. Could someone who had no experience with a markup language that describes a tree of document nodes use jQuery to draw a rectangle on the screen? How would they do that without the use of an HTML tag?

RibaldEddie 2010-02-09 05:16:53

You might also check out Bindows.

Matthew Taylor 2010-02-09 04:42:34

+3 A:

I don't see how the canvas tag would offer any real benefit that isn't already available through plugins like Flash. Drawing your interface might make it prettier, but it won't use the elements pre-defined and standardized with XHTML. I'm not even sure, since the canvas can only be drawn via javascript, that such an app would be accessible to either a screen reader or web-crawler (I could be wrong?).

The ideal web app should be native HTML with javascript to handle user interactions. Sometimes those cross-browser quirks are just reminders that not everyone is going to have or even want an identical experience. If you want to have total control of the visual experience of the user, stick to java apps, flash objects, and non-web development. If you want assurance that your javascript will behave in most browsers and gracefully degrade or fail in the rest,use jquery and be thankful for the DOM that makes it work.

Anthony 2010-02-09 04:49:03

You're begging the question.

RibaldEddie 2010-02-09 05:12:20

How so? Does it sound like I'm saying "DOM is the best because DOM is the best"? What I mean is, native HTML elements are the best because they are already abstracted for browsers which are what should be viewing them. Or is that still begging the question?

Anthony 2010-02-09 05:18:06

Well I think it is still begging the question, but I did ask as part of my question what you thought of the DOM. So you're more than welcome to say that you think the DOM is the bee's knees. Since you seem to think that, I suppose it would be nice to know more detail as to why. The 2d drawing api in the canvas tag is pretty different and I do want someone to address what that difference means for developers. What if HTML5 is adopted in major browsers, and one day some web sites that you love to visit start using the canvas tag to draw their interfaces? How would that make you feel?

RibaldEddie 2010-02-09 05:27:07

I think the canvas tag should be limited to drawing things like graphs (such as flot) and vector logos (which i'd prefer to see done in svg). I could see an argument for canvas for printing, but I am very wary of that as well. If canvas could be mixed with CSS so that the 2d is drawn on top of other html elements, that would be okay, I think. Ultimately, my web app standard is "how will this look on a wap phone or to a user on Linx." The only degradation I don't consider is non-compliance (which I realize my two examples would fail)...

Anthony 2010-02-09 06:03:24

But in principle, the user should at least get something better than jumbled elements and a "Click here for our low-bandwidth site." I am very much with Eric Meyer on the vision of sites and apps that conform to the browser without needing to be browser aware. This is why the DOM, or at least XML, makes sense to me. It is a semantic abstraction of the most important part of a page, ie the data itself.

Anthony 2010-02-09 06:07:09

Fair enough. In response to your original answer, I'd say that one of the main differences between canvas tag and plugins is that canvas tag is built in to the browser, so the user needs to do no extra thing.

RibaldEddie 2010-02-09 06:09:20

Okay, it may be an ideal representation of the data, but as a developer does it allow you to build the best app you possibly could given the constraints of time, cost, and knowledge?

RibaldEddie 2010-02-09 06:11:27

I'm going to call myself out and admit that I've done 0 desktop development. I get angry when I have to compile my own binary and it takes more than two tries. So I am very unfamiliar with what the alternative development models are. I imagine just from messing with some svg stuff that developing a GUI might call for something different. But I think putting data first is part of what has made web apps so popular. Even if it also makes the mess we're in now with gaps in standards and compliance...

Anthony 2010-02-09 06:22:12

But it's not the browser that makes web apps so popular, it's the XML. XML is by no means perfect (just trying to make non-hierarchical relationship diagrams shows that), but it does move us away from pre-web (or even web 1.0) days when a user had an issue and might find 19 alternative programs, all kinda-free and all kinda-sucky and none of them saving into a format that could be useful to their associates without using the same software. This is my problem with Flash/PDF. It makes attractive output, so long as everyone has Flash Player 10.x.

Anthony 2010-02-09 06:26:33

Basically if we all have to drink the Kool-Aid, I'd rather it be the Kool-Aid we were all going to drink anyway (any compliant web browser) than forcing half the users to ante up and get plugins, add-ons, etc, while leaving other users in the dark (literally) and forcing developers to all invent their own vocabulary AND deal with the vocabulary of their fellow developers. I don't want "an app for that", I just want the site to work on my phone. And I don't want to compete with other sites for who can draw better, but who can arrange better.

Anthony 2010-02-09 06:31:03

Well I agree that plugins are not a good thing. But even in the current paradigm there is a huge difference in visual design between sites. Surely there is more to today's web design besides "arrangement". Anyway, thanks for taking the time to write your thoughts. It's nice to see at least one person has something insightful to say on this site.

RibaldEddie 2010-02-09 06:46:40

+1 A:

But how can you abstract that which has no standard? First of all, JS is one of the softest-typed 'languages' with the fewest standards, and the most flexibility. Second of all, the DOM is an abstraction in itself. It's an incredibly easy to use dumbed-down abstraction, at that.

jQuery, Prototype, Ext.js, YUI are frameworks, they are not abstractions per se. I guess you could call them incredibly thin abstraction layers. Like, really really thin. The Google GWT is arguably one of the few 'abstractions' available for JS.

But calling GWT an abstraction of JS is like calling an elephant a 'bigger mouse'.

David Titarenco 2010-02-09 04:59:01

First of all, JS is not the DOM.

RibaldEddie 2010-02-09 05:17:16

The DOM is how JS sees the document. I assumed that the OP was referring to JS because he mentions Ext.js/GWT, etc which are on top of JS. Furthermore, there's no way to make the DOM more "abstract". It's already as OOP-y as it can get. For more information about the history of the DOM (and implicitly, JS), see: http://en.wikipedia.org/wiki/Document_Object_Model

David Titarenco 2010-02-09 05:57:43

ExtJS has a layout manager. It literally has its own concept of a box that I can define and manipulate without any mention of an HTML tag anywhere. In the future if I wrote my app in ExtJS using its layout manager the ExtJS developers could decide to write the drawing portion of their library using the canvas tag and my code wouldn't have to change at all. By definition, the DOM is fully abstracted away.

RibaldEddie 2010-02-09 06:03:41

“how can you abstract that which has no standard?” — I think there’s a good point there: there isn’t much of a standard UI for the web. In fact, the UI for your software should be nothing more than the minimum required for the user to help the machine complete whatever its task is. You can’t standardise that unless your app does exactly the same thing as someone else’s — and then what’s the point of writing yours?

Paul D. Waite 2010-02-14 05:38:35

The best attempt I've seen so far is Backbase, you just create DOM elements with a declarative API ala Flex or Open Lazlo.

http://www.backbase.com/products/enterprise-ajax/#architecture

SleepyCod 2010-02-09 05:41:56

+3 A:

"I don't want to spend time with templates and DOM manipulation to put together a user interface. How much work do I have to do to layout a page or a screen, or put form widgets in my UI? In the desktop world, I tend to find it easier to get past the UI trivialities and back to working on the things in my company's business domain."

I'm a UI Design Engineer, and this is the kind of attitude I face every day. I understand your frustration and I feel your pain, but I have to say that companies who expect engineers to design front ends and implement them are not really getting the most for either the engineers or the product. Do they expect you to write your company's brochures, too? Cook up tasty lunches in the cafeteria (assuming you have a good cafeteria)? Keep the office plants alive? A lot of companies hire engineers the way baseball teams hire utility infielders: they can play any position in a pinch. But somehow you never see them pitching or catching, do you? Baseball teams consider those positions too specialized (and important) to staff with generalists. Software companies (ones that want to win) should take a cue from this practice.

The UI is not trivial, and not something to be shoved under the rug so that all-purpose engineers can get back to working on their "real" work. The UI is something that enhances the product, if done right, and if done wrong alienates users and detracts from the product. And it requires specialized skills. Just as people specialize in doing DB work or middlewaare coding, some people like me specialize in making things look and work right for the user.

Consider this text box I'm writing this response in. Notice that it allows simple "rich text" capabilities, such as bold or italic, links, lists, etc. There is a ? box on the upper right which you automatically know means you can click it to get help for this process. There is also a nice little grabber bar at the bottom which enables you to resize the edit box if you so choose. While you're writing, you can see a preview of your work in realtime just below the edit box. Those things exist because the people at stackoverflow have used people who understand UI and the DOM. I see they use jquery, which as RibaldEddie points out does not really "asbtract away" the DOM, but offers techniques to smooth out its inter-browser gotchas and simplify a lot of programming work.

My company has the good sense to employ me to create mock-ups of every single page the user experiences, and then to code them on the front end the way they should be coded once developers like you handle the database and server pieces. I use the DOM because I understand it and because it's how visual UI work gets done, and done right. It's been the single biggest factor in creating usable, robust Web front-ends ever since it evolved from the browser wars. I can't begin to tell you the sense of power I felt even when I discovered Microsoft's early implementation of "document.all", which gave me scriptable access to just about everything on the page. Wow!

Also, be careful when looking for your holy grail abstraction layer. What happens when your abstraction layer leaks? Do you know why the problem happened, or what you can do to fix it?

If your real work is not UI design and programming, I sincerely hope your company will consider letting you do your real work exclusively. And hire a UI person to do their real work.

Robusto 2010-02-12 15:38:23

Interesting. I know my teammates and I would love it if we had a UI expert on board (we don't). Lately we have been frustrated by that and we are trying to learn as much as we can about good UI design. One of my co-workers is even taking some classes at a local college on HCI.When I say "UI Trivialities" I don't mean that the UI is trivial, just that there tends to be a lot of boilerplate "glue" code that you have to write to deal with the nasty nexus of the DOM, CSS, stateless HTTP, and AJAX. If you've ever worked with event-driven desktop GUI frameworks, you'l know what I mean.

RibaldEddie 2010-02-13 07:49:25

Even more for us, is that our architecture is driven heavily by server side templates, sort of the way that, say, Django templates work. As a result our system is currently very procedural and doesn't provide us with the flexibility to be dynamic with our interface. I've found that on the web, that procedural, transaction script sort of paradigm is still widely considered acceptable. I don't think that it's acceptable, and one reason is that the DOM can be very unwieldy to work with programmatically. Hence workarounds like jQuery.

RibaldEddie 2010-02-13 07:54:09

I do know what you mean about all the boilerplate. My problem with JS frameworks, however, is that they're only good to a point. If you do it their way, you pretty much always reach a point where their way only gets you 99% of the way there, and you desperately need that other 1%. I've worked for places that used templates a lot, and those have their limitations, although with some you can be very creative. You might be surprised what you can do with XSLT templates (esp. if you were able use XPATH 2.0).

Robusto 2010-02-13 19:42:44

As to your other point, what you usually find doing UI design are designers who can't code or coders who can't do graphic design. When you find one who can do both – like me :) – it's a rare event. Although I have encountered a few such polymaths online, I have only ever met one other in real life: my current boss, who hired me 15 minutes into the interview.

Robusto 2010-02-13 19:46:52

The boilerplate is in some way a result of our own doing, but prior to my joining the company. Perhaps I am just frustrated by the fact that so much of our application's logic is server-side, and not in well-defined classes either but sprinkled throughout transaction script-style procedural files. When I started learning what MVC was like in desktop programming I realised that web applications of any sophistication needed to be written with their application logic in JavaScript. Look at something like Google Maps. When it came out, I remember it was touted as one of the first web apps.

RibaldEddie 2010-02-14 07:54:49

That is, highly sophisticated web apps. Gmail had the same air. When I started looking at the open source frameworks for web development, I wondered where the frameworks were that allowed a developer to write an app like Gmail in JS with the same speed and utility that one could write with, for example, Cocoa on OS X. And there weren't any. The popular web frameworks and JavaScript libraries were and are anaemic compared. Web developers don't seem to want to realise that they are building software with poor quality tools.

RibaldEddie 2010-02-14 07:58:44

I think it’s all pretty much been said with the other answers, but I would add that the dirt-simple user interface experience afforded by default in HTML (links and basic forms) isn’t necessarily a bad thing.

It depends on who you’re making software for, but users can be utterly mystified by things that seems pretty simple. See e.g. http://daringfireball.net/linked/2010/02/11/facebook-login

Cappucino is really impressive, but I do wonder if it’s doing the wrong thing: taking the 25-year-old desktop UI paradigm, and exporting it wholesale to the web. When Apple got the chance to invent an entirely new UI in the iPhone and the iPad, they made things a lot simpler.

Computers are information machines. They’re meant to automate working with information; they’re meant to do stuff for us. So maybe it’s good that we don’t have a myriad of UI controls to throw onto the screen with a line of code. Maybe it encourages us to focus on writing software that intelligently handles information complexity for our users, instead of giving them UI controls and getting them to handle it.

Paul D. Waite 2010-02-14 05:35:46

Like others, I think you're conflating two different things: the importance of good UI design vs. how that UI design is implemented.You could argue that there is a larger number of myriad user controls with the DOM and CSS paradigm because nothing guarantees that controls look and behave the same way from site to site. Users can't rely on familiarity to determine how things work. For the average user, familiarity is the most important factor in their ability to interact effectively with an interface.

RibaldEddie 2010-02-14 07:44:19

You also mention Apple and the iPhone and iPad. One of the things that makes those interfaces so useful is that Apple provides controls that can be put in any application by a developer without the developer having to re-implement those controls. Again, users get controls with which they are familiar so they can take what they learn from one app to every other app on the system.If we had that kind of homogeneity on the web; yes, it might be duller for designers wanting to express themselves, but the overall interface might be easier for ordinary people to use. That's speculation on my part.

RibaldEddie 2010-02-14 07:47:01

I see what you mean. Thing is, the DOM isn’t an API for making user interface elements. It’s a representation of a markup document. We happen to be use HTML to represent an interface, but that doesn’t mean HTML (and its representation in the DOM) need to confirm to our ideas of what an interface should be.

Paul D. Waite 2010-02-14 09:10:41

I agree that familiarity is important, but if you stick to the actual interface elements that HTML provides (links and simple forms), then you get that familiarity between sites. Note that the iPhone and iPad UIs don’t bear much in common with Mac OS X’s UI, yet novice users seem to get comfortable with them pretty quickly, because they’re simple and well-designed. As people who make software, I think it’s easy for us to overstate how familiar users will be with the WIMP paradigm (and thus how much usability benefit we’ll get out of reusing it), because we’re so familiar with it ourselves.

Paul D. Waite 2010-02-14 09:13:11

I think you've got a good point in your comments. The take away, for me, comes down to the "use the right tool for the job" notion. You seem to be suggesting that trying to build an application-style interface using the DOM and HTML is wrong: if your instinct is to build an app with conventional buttons, toolbars, and menus, you shouldn't be doing it on the web.

RibaldEddie 2010-02-16 03:19:55

Pretty much. Depends on your audience, of course, but by doing so you are going against the grain of the materials (HTML and the DOM) that you’re working with.

Paul D. Waite 2010-02-16 08:14:02

ansaurus

tags:

views:

answers:

Which Frameworks Abstract Away the DOM?

related questions