answering the wrong question?

It seems like there’s a really good opportunity for someone to do something very helpful and make a site that compares and tracks JS frameworks. As far as I can tell, though, no one has, so maybe I can be excused for my ignorance if what I’m looking for already exists. What I’m looking for is a framework that deals with webpages as webpages, and deals with elements within an application as elements.

I kind of go back and forth on my feelings about MVC, but they average out right around apathetic skepticism, or ::rolleyes:: if you want. It’s because there are a shit-ton of them and MVC is pretty easy to write code for, cause things have these very clean relationships. That’s great for your data, it’s great for your backend, yada yada yada. But it’s pretty much shit for complicated interfaces. Views and models don’t always line up. Views without models exist and still have state. Some states are important to the application, some are important to a given object, some are important only to a widget. You can shove all the shit on your page into the MVC idiom – and people do – in order to use an MVC framework, but I don’t think that solves the real problem.

If you know of a framework that’s primary concern is with organizing DOM elements and DOM interactions, please stop right now and go down to the bottom and leave a comment telling me about it. As far as I know, such a thing doesn’t exist. jQuery’s great for working with the DOM, of course, but doesn’t make any attempts at organizing things or offering a hierarchy of objects. We now consider DOM interaction a bad thing, so more “serious” frameworks tend to shove the DOM stuff under the rug, deigning to interact with the page only when necessary.

I don’t want to say a bunch of shit I’ve said before here, but that’s just fucking silly. Structuring your code around abstract objects instead of the mechanisms by which things are actually made available and manipulated – DOM elements – is like having a perfectly organized closet while the rest of your house looks like something from the TV show Hoarders. It’s low-hanging fruit, and it skirts the issue that’s the most difficult to deal with and the most inseparable from the idea of a web application.

I’ve looked at a bunch of these frameworks. I’m not going to lie, I’ve only attempted to write apps using a few, and quickly got frustrated by the tradeoffs between limitations and simplifications they were offering. You don’t have to agree, but I’m just saying: I’m a computer science major, one of not very many I know, and I find their approaches way too computer science-y. Writing an interface programmatically is one of the most painful things I’ve ever had to do (repeatedly, in VB), and that’s what the frameworks I’ve worked with all devolve to once you’re beyond the tidy CRUD model where MVC can give you genuine shortcuts. But, again, I’d love to know if I’m missing something.

I read a blog post about how fashion designers should learn to code recently and was kind of horrified by it. To me, it’s a perfectly example of why not everyone should learn to code. Not because the solution was bad – I think polaroids are about as elegant as you’re gonna get, personally – but because part of how a programmer has to train himself or herself to think is this kind of obsessive, examine the problem from every angle, think of every possible optimization pattern. We do need people who can think that way within certain contexts. It’s useful when you’re building an application. Or, say, a JavaScript framework. But it can and does bite us. We know what happens when we’re wandering around unchecked with a hammer looking for things to use it on. (We use it inappropriately.) I feel like it’s time to stop letting classical CS patterns inform the way we build JS frameworks and embrace the way the DOM actually works and is used and has been used, and build around that. When someone truly does that well, I think JavaScript will take another big leap forward, and we’ll all wonder why it took so long for us to address the right problem.


9 Responses to “answering the wrong question?”

  1. Joshua Flanagan Says:

    The TodoMVC project is a site that compares JS frameworks (not just MVC).

    Can you expand on “organizing DOM elements and DOM interactions”? Sounds like you want the DOM as your framework. What pain is that causing?

  2. garann Says:

    @Joshua – I’m looking for something more like an overview than TodoMVC. More like, for example.

    DOM-centric code is (fairly) criticized as devolving quickly into spaghetti code. What I’d like to see is something that contains that, allowing tidier management. Taking the existing DOM and bundling it up so that selectors become objects and elements are entities in their own right (whether or not there’s a one-to-one correspondance to a backend model).

  3. Ryan Miller Says:

    I’ve been doing front end development for quite a while but for the past couple of years all my work as been in Flash. I’m coming back to JavaScript now and trying to get caught up. It’s exciting but also frustrating. I see the same void in JavaScript MVC frameworks. I want to know how to manage a complicated set of nested models and nested views. I think this is what you are getting at. In ActionScript I can create classes that ARE the view, they are display objects that are part of the display list. In JavaScript, this is never really the case. The DOM exists on it’s own and you write code that manipulates it. It would be interesting to see a way that makes JavaScript feel like you creating and managing view elements with view logic more directly.

  4. Buck Says:

    I’m not sure if this is what you mean, but maybe:

  5. haliphax Says:

    This one looks like perhaps it has a chance at meeting a few more of your needs (though perhaps not all of them):

  6. garann Says:

    @Ryan – I think Flash makes a great example. I learned Actionscript after JavaScript, but before JS had anything usable that even came close. There are lessons in organization there that I think get ignored because of stigma, which is silly.

    @Buck, @haliphax – Thanks for the links, but not quite. I’m working on a POC. Once it makes sense, I’ll put it up on github.

  7. Brian Crescimanno Says:

    I don’t have any advice to offer in terms of what you’re looking for; but, I wanted to take a minute to comment on your thoughts on frameworks carefully separating themselves from the DOM. I’m not going to speak for the Framework authors or their reasons; however, I can tell you that in some environments (mobile and embedded come to mind) any manipulation of the DOM is incredibly expensive (we’re talking at least a single order of magnitude greater than manipulating less complicated objects).

    Moreover, the DOM has some real issues with representing the state of an asynchronous application and (in my experience and from what I’ve seen quite often from others) using built-in constructs like DOM focus tends to break down very easily. Another concerns is that the DOM tends to (by necessity of some of the weaknesses of CSS) be far more granular than is needed from the perspective of your application (e.g. I care about updating the image in my “viewer” widget; I don’t actually care which DOM node within that widget is the one that needs updating).

    I suppose my point is really: I wouldn’t be so quick to dismiss the notion that you can create a well-written web application without tying yourself tightly to the DOM. I think Ember.js, for example, does a great job of separating you from the DOM on the one hand, while using handlebars templates to avoid the obnoxious world of building up a UI programmatically (which, I completely agree, sucks). I also believe that as alternative rendering methods become available in the browser that aren’t DOM based (Canvas and SVG come to mind as obvious, but perhaps somewhat contrived, examples) having your application logic well-separated from the DOM can make taking advantage of those technologies easier.

  8. garann Says:

    @Brian – I’m not saying the advice that we’re used to now about minimizing DOM manipulation is invalid. I’m saying that sometimes it’s necessary, and sometimes the work that needs to be done isn’t really a part of the MVC model. Rendering is the easy part. I’ve been using templates for everything I can (whether or not they were strictly necessary) for over two years, but even trying to make things as granular as possible and make sure widgets not tied to data had their own templates, there’s a lot of DOM interaction in some applications. And redrawing big sections of the page is rarely useful for that, in my experience. Getting rid of unnecessary DOM interaction is awesome, but when it is necessary, trying to replace it with something else just moves the mess around instead of actually cleaning it up.

  9. Evgeny Eroshin Says:

    I’ve been reading your blog for a long time.

    Recently I started to work for Yandex ( Here “BEM methodology” is used for a web interface development. I suppose this is what you a looking for.
    I understand the problems you are writing about. There is plenty of tools to develop web today. All those DOM interractive things, real time transformations (even building complex graphics at the client side), sound and video included into a web page.
    But there is also an empty niche. Nowadays every web application code is mincemeat of many tightly bounded technologies. I mean, to develop a simpliest web page you need to create its HTML file with some markup. Then, a CSS file. And filling in the CSS file with code you should keep in mind the HTML structure. Besides, to bring about some dynamic behavior to your page you need the third, JavsScript file. And coding JavaScript you do it for a particular HTML structure and for a particular CSS. There is no way to split your code and reuse in absolutely different project.
    Moreover, usually all components of those mincemeat are usually maintained by different people. And each of them operate with his or her own data domain. Isn’t it too complex?
    We suppose things should be much easier. Any web interface should consists of “blocks”. And each block should “know” everything about his appearance and behavior. The idea is that building a web application should be similar to building a desktop application. We want to code in interface object’s dynamic behaviour without thinking about its DOM structure. We want to write JavaScript for every object the same way, no matter how an object looks in accord with its CSS. So, the same technologies but more independent.