10 Things I Learned about Ext JS After 1 Week

I recently had the opportunity to work on a project for a new web application on the Ext JS framework. I am a front-end developer (“UX Engineer” by title) so my background is primarily in HTML, CSS, and JavaScript. As such, my responsibility on this project was to implement the user interface design, which had previously been conceptualized in Abode Photoshop.

Starting off, I did have some understanding of the basic concepts, but almost no practical experience. A co-worker helped me install the necessary bits and get the project up and running. I completed my work in Aptana Studio 3, primarily because it provided an easy way to compile and run the project.

I worked on the project for about 5 days, which was just enough time to get a crash course in Ext JS and complete the tasks assigned to me. During the frenzy that ensued, I learned several things about the Ext JS framework that I felt were worth sharing.

  1. Ext JS takes a very modular view of, well, everything. Instead of working in a few massive documents, I found myself working in several small documents. In some ways, this was nice because the documents were easy to scan through and work with, but it also meant that I usually had a lot of documents open in Aptana. I had to develop a system for ordering the tabs so I could easily find the one I needed.
  2. Ext JS projects come with a pre-built interface that includes dozens of UI components that can be utilized at will. There are several themes to chose from that allow developers to create projects with little-to-no CSS required.
  3. If you need to implement a custom interface, it seems that creating a new theme is the best approach. Ext JS has a theming guide that provides a pretty good overview of how to set up a new theme.

  4. Even custom themes need to start with a base theme. This provides a basic set of styles for all of the UI components included in the project. The “ext-theme-base” includes the least amount of inherent styles and should be the easiest to override.
  5. Ext JS utilizes SASS, which allows you to use variables, math operators, and other functionality not available in regular CSS. This was also my first real foray with SASS, but I was already familiar with the core concepts. Although I looked to make use of the various benefits that SASS offers, I was working on a very small project and I found that I only feature I needed was variables. Unfortunately, in this case, I don’t think the 10 or so variables offset the extra overhead that came with compiling the project every time I needed to check my styles in a browser.
  6. Even the CSS is modularized in Ext JS. Ext JS has a separate SCSS file for each UI component (which I didn’t touch) and I had a separate SCSS file for each custom view. That provides some organizational benefit, but, in the end, Ext JS compiles all of them into one file when the project is built, which nullifies any speed optimization benefits that separating the code may have also provided. It also means that you need to have a good understanding of how the final CSS file will be compiled or your style updates may get overridden by other code that is inserted later in the document.
  7. Ext JS allows you to create a “universal” style sheet in your theme that will be included on all views of your application. Under /packages/{your-theme}/sass/etc create a file name “all.scss.” I used this file to hold the base styles for my application as well as my SASS variables and then had view-specific styles in separate files.
  8. Although Ext JS does allow you to create custom themes and override most default styles, there are still many instances where inline styles are inserted. In those cases, I found that I usually needed to apply the !important CSS snippet in my file.
  9. The generated HTML in Ext JS 4.x is massively bloated. Although there are ways to insert your own HTML, most of the time, I worked with Ext’s UI components. A simple button generated by Ext might include like 10 nested HTML elements. I believe that the main reason for this is that the default themes still support IE6 and they need a lot of elements to pull off gradients, borders, etc. in exactitude in all browsers. This might be my least favorite thing about Ext JS, because it creates a lot of unnecessary overhead for the browser and makes navigating the DOM through Chrome’s Dev Tools (or a similar tool) an essential step in styling anything.
  10. Ext JS has pretty good documentation. I found it to be a little cryptic until I had worked with the framework for a little while, but then it was quite helpful. However, if you do have a question that the document doesn’t answer, I found that there are not a lot of other resources available. Even stackoverflow is short on answers. I’m told, however, that the Sencha forum is quite good in a pinch, but I have yet to try that route.

By the end of the week, I felt pretty comfortable working with Ext JS. There was a bit of a learning curve, but, between my helpful co-workers and Ext’s documentation, I was able to overcome most issues with little trouble.

After a week of total immersion, I don’t feel like I can fully endorse Ext JS. I can see how it would be a good tool for development teams that don’t have any front-end developers, but it certainly didn’t make my tasks any easier. In general, I prefer to work with lightweight frameworks that provide more control over the HTML and CSS.

What has your experience with Ext JS been like?

No DHTML, Please

Originally Posted by Adrian Roselli on January 25, 2012, on his blog.

HTML5 logo mocked up as DHTML logo.The trend continues where I speak to clients, vendors, young developers fresh out of college, and even the teachers/professors who instruct them and they don’t understand that HTML5 and CSS3 aren’t the same specification. I have repeatedly shown an HTML 4.01 site with CSS3 to explain that they are each distinct specifications which can be applied in different combinations of different versions. This is further complicated when JavaScript is folded into the mix — some folks even think jQuery is part of the HTML5 specification.

I am repeating a request that when we who know better (developers, tech writers, robots named Frank) speak about discrete specifications, we refer to them as such.

When I talk to another developer about a feature, I want to know that when one of us says “HTML5” we are both talking about that particular specification. When we use terms like “WOFF” or “WebGL” I have comfort knowing the developer has a particular set of technical standards in mind, but when one of us says “HTML5” we each have to pause to consider what related specification the other might actually mean.

It seems fair to raise what sounds like a semantic point when we are discussing a specification that is all about encoding content in semantic and structural elements. I don’t think I should let this go, otherwise it feels like I have failed the semantic goal of HTML right at the outset.

What Motivated the Mini-Rant

Another free and fantastical service was released to the web development community on Tuesday, HTML5 Please. The same folks who also brought us sites like HTML5 Boilerplate, Modernizr and CSS3 Please are the fine team behind this resource. And this is part of the reason why I am so frustrated. Each of them knows the difference between HTML, CSS, and unrelated specifications like WOFF, SVG, Geolocation, WebGL, and so on.

In a (Google-doc-brokered) conversation with Ian Devlin (author of HTML5 Multimedia: Develop and Design), Paul Irish (one of the folks behind HTML5 Please) agreed to add a disclaimer to the site for the chronically unlikely-to-read-any-specifications-or-bother-to-know-the-differences-among-them. Mr. Irish made short work of it, too:

While named HTML5 Please, this site discusses features beyond the HTML5 specification, coming from CSS, SVG, and the greater Open Web Platform umbrella.

On Wednesday I went back to the site and noticed that the disclaimer was gone. I tweeted about it and was ultimately directed to a bug/issue report that provided justification for its removal:

[…] However, HTML5 represents an umbrella term for all new technologies (as is inferred from platform.html5.org). Also, the specification itself is now a living standard known as HTML and not HTML5.

Of course I was motivated to leave a comment:

I feel the ship has sailed when trying to communicate this point to the general public, tech writers, bosses, clients, and small children up the street. However, since the site is aimed at developers I think it does a disservice to not remind them that HTML5 means a very particular specification, and that it makes it easier in the future to cite new specifications that will be supported on the site (as they come up), but are otherwise distinct. For those who do know better (me, a couple folks above), it just looks like the site got it wrong and doesn’t understand the difference itself.

If we as technical professionals cede the meaning of HTML5 when speaking to other technical professionals, we are falling prey to marketing speak that has no place in discussions about specific technical matters.

That’s it, that’s the background. I’ve explained my thoughts on this before and am concerned that HTML5 has become a distilled marketing term that, unlike DHTML and Web 2.0, neither of which shared the exact same name as the version of a technical specification, only leads to confusion when developers are interacting with marketers, bosses, clients and vendors.

You may read previous variations on this rant here: