Browser, What Ails Thee?
Wednesday, May 7th, 2008The problem with developing front-end applications for web browsers from a back-end developer’s point of view.
In our search for quick (and equally dirty) Javascript solutions for problems like form creation and control, we’ve run across a lot of frameworks. “Let’s use the framework which makes our lives easiest” was the chant, to implement anything third party loosely and, if it breaks, rip it out and either find something better or write something from scratch.
With that in mind we decided to go with ExtJS since it offered a lot of very useful widgets, the widest spectrum of features, decent API documentation and a big user base. Loose implementation of ExtJS’ FormPanel was easy: Create a FormPanel object, render it to an HTML element and forget it ever happened. The wow factor was high at first: All this without any hassle whatsoever, great. Now we didn’t have to worry about this anymore.
Apart from a few minor bugs and glitches, the forms worked fine. That is, until we ran some tests on Internet Explorer. The results kind of shocked us: ExtJS components inside a DIV appeared to have absolute positioning, ignoring the DIV’s overflow property. Also, long loading times and general slowness poured rain on our form parade.
Woes
Apparently there was some dodgy stuff going on inside the ExtJS framework, something intended to make sure it all looks and acts the same in all the major browsers. The long loading times are caused by the copious amount of (needed) ExtJS script infrastructure. Of course it’s still possible to minimize and strip a lot of unwanted script code, but since we were still in the process of developing an application we were not going to let ourselves be slowed down by something which could be postponed until a later stage.
The general slowness — especially in IE and Firefox — was caused by something completely different: If you take a look at the ExtJS API documentation you will find a lot of very elaborate objects. There’s a method for almost anything you want and if something’s missing, chances are you can access it through one of the event handlers. Great stuff. But since you’ll never need all of those nice features (and God forbid you will) you could do without most of it.
What we actually wanted was a form widget framework that performs the dirty footwork for us. We wanted it to be fast, flexible, skinnable and cross-browser. That’s what ExtJS promises. It’s there, it does work, but it’s slow and prone to failure. Since ExtJS is one of the most extensive frameworks around I think it’s rather safe to assume that any other similar widget frameworks will have comparable issues; Blaming this all on ExtJS is just too easy, but it’s safe to say that layering frameworks like ExtJS on top of the Javascript runtime will lead to a product that is rigid, huge and slow.
Barking up the right tree
So what’s really going on here? Why is ExtJS so rigid? What causes this slowness and bloat? Perhaps I’m just not competent enough to write an application for a web browser? Let’s go over the points:
- Rigid — lack of standards : Go quickly from A to B.
- Slow — weakness of Javascript : Go quickly from A to B.
- Huge — demands of industry : Go quickly from A to B.
Our positioning bug wasn’t actually caused by ExtJS proper, but rather by the fact that ExtJS needs to hack around a lot of browser-specific issues. We can go nuts over the fact that this problem exists in the first place, but hey, the fine people at ExtJS did their best to make it work anyway, so no, I don’t think I can point the bullshit ray exclusively at the ExtJS framework. The problem here lies in the lack of standards, caused by browser manufacturers being unable (or even unwilling) to cooperate with eachother.
The complexity of ExtJS objects puts a price on the general performance of the application: For every object there are tons of handlers, methods, properties and configuration options. Javascript was never meant to be used as an OO work horse for big applications, neither in architecture nor in performance.
The reason why the ExtJS framework is so big is that it has to serve many masters with many demands: There should be something for everyone and there are lots of people screaming for an easier way to write applications in Javascript. Is it way too bloated for what a browser can handle? I think it is. But who can blame them? I sure can’t. Using it saved us a lot of time and the demand for a framework like that is apparently big enough to justify its existence. So no, they’re trying their best to make something very decent and respect and credit where respect and credit are due.
Maybe I should just blame myself for being a lazy developer. I don’t really want to know why browser #1 does it like this and browser #2 does it like that. And to make it even worse: I don’t want to know how to fix or circumvent it. I think I’m a lot better off writing applications rather than fixing these kinds of inconsistencies. Does that make me lazy? One could argue so, but come on, imagine writing stuff in C and taking four different compilers into consideration. I think there are a lot of differences between web developers and application developers. For one, web developers usually aren’t anal retentive when it comes down to writing structured code. Application developers generally don’t know jack about CSS (and like it that way).
Conclusion
The lack of standards. IE does it this way, other browsers do it that way. If there would be proper standards life would be a lot easier. HTML and CSS would be more respected by both web developers and application developers. Mastering the skills needed for development of an application for a web browser would take a lot less time. Javascript frameworks would be less bug-prone, easier to understand and would take up a fewer lines. The world would be a better, more accessible place. This, of course, is not going to happen in the near future (if ever). Even if projects like WaSP (the Web Standards Project) succeed in setting proper standards, there’s still the IE user running an older version that thumbs its nose at all those standards.
The browser as a platform for applications is still falling short: The user demands well-developed fast applications that can do it all. Be that as it may, but we’re pushing the current implementations of the concepts behind browser markup, presentation and interactivity to a maximum and it takes a lot of work to keep it all together.
Maybe I am the wrong guy for the browser-hell half of the job and maybe we need a proper web developer to help us out. One thing’s for sure: People who can do both web development and application development have a nice future in front of them.
To wrap it up: Without proper standards a vessel is needed to ensure a faux standard that allows people to keep on working without having to constantly worry about the difference in DOM, HTML and CSS implementations. And since the only common denominator between all those platforms that is at least somewhat standardized is the Javascript language, it has become the web’s little bitch.
What this means for OpenPanel
Once again: ExtJS is a fine framework with a lot of nice features and, again, it saved us a lot of time. But I think I’ll pass for now since we’ll start looking at the actual shortest route from A to B.
Since the functionality of the client is strictly separated into different concerns, it’s quite easy for me to write (and maintain) a working application while someone who is adept at browser differences is able to make things work without having to fully grasp how the application works. That way our application stays flexible, fast and lightweight. By the way, if you’re good at this stuff let us know because we’d love to have a little chat with you.
