Tag: tools

7 required improvements for the Web, HTML and JavaScript

Here’s my 2012 web developer wish list for improvements that I’d like to see happen in the web developer world. If HTML and JavaScript want to be considered enterprise ready for commercial-grade deployments then here’s some things that are needed today.

For clarity, I consider a commercial software deployment to be one that contains over one thousand lines of code, at least two custom .js libraries and involves at least two developers and some sort of code versioning system.

  1. Refactoring. Not having this capability continues to be a huge productivity issue for large projects. Try refactoring across six JavaScript libraries and 1200 lines of code using Notepad++.
  2. Even stronger scope enforcement in JavaScript classes. One wrong misspelling and you can spend fun filled hours (or days) tracking down a private variable that turned itself into a global variable.
  3. Built-in support for code comments. Visual Studio does a fine job, for example. But, it’s still kind of a hack to make it work. I’d like the built-in ability to create comments for methods and classes directly and then be able to access those comments via intellisense throughout any file in the project. Again, this is all about productivity by having this information accessible at your fingertips.
  4. Better built-in JavaScript checking for IDEs. I’d like to see built-in JSLint-like capabilities that have been updated to the latest HTML, JavaScript and CSS3 versions, and not some third party plug-in that’s optional.
  5. Best practice whitepapers. These would be whitepapers written by the browser vendors that provide guidelines on the correct patterns to use when building apps against their browsers. Seriously, it’s been roughly 21 years since we started using browsers and there’s no guidance at all from the powers that be.  Honestly, I’m stunned that these don’t exist. That would be similar to Microsoft publishing .NET and then not providing any conceptual help documentation.
  6. Official tools for browser certification and testing. The folks that build the browsers don’t give us a way to verify if we are building our apps in the best way possible. If these items existed, then quality could get a lot better, and we’d all learn a lot too.
  7. Slower browser release cycles. A slower release cycle for browsers and more improved security and stability. I already blogged about this here.

IE 8 Developer Tools – A great step in the right direction.

Even though IE 8 Developer Tools have been around for a while, since Internet Explorer 8 Beta 1 (circa 2008), there are still a lot of developers out there who aren’t familiar with it. And, it’s well worth the time learning about it. Some of you may be wondering who develops against IE? Well, before I dive into the details, I wanted to say a word about that. According to w3schools as of October 2010, IE represents 29% of all browsers, and IE 8 browsers make up more than half of that number.

You should research your own website stats, and companies such as w3counter provide developer tools for that. In general, it’s fair to say that most consumer sites get a lot of IE-based traffic, and testing your app against IE is a good idea. If you don’t, there’s a strong chance you’ll frustrate a bunch of potential users and they may not come back, ever. If you run an internal site for an organization then you may have more control over which browsers (and browser versions) are used, and your life is probably easier than the rest of us.

I know I personally didn’t like testing against IE because with IE 6 and 7 the tools were pretty much non-existent and extremely unfriendly to web developers. I have to say that IE 8 made a huge step forward in my eyes when they included Developer Tools. Sure I have plenty of gripes, but all-in-all my job got much easier. Instead of blindly making changes and then reloading the page to see the results, I now do the majority of my testing and prototyping right in the Developer Tools.

Here just a few of the tools I find particularly useful:

  • Built-in Script debugger. Yep, it includes console, breakpoints, locals, watch and call stack.
  • Edit on-the-fly.
  • Inspect CSS.
  • Select element by click (Ctrl + B).
  • Clear cookies for domain
  • Tools > Resize (on-the-fly)
  • Show ruler.
  • Save HTML or CSS changes to a file.

I still have a wish list of things I’d like to see added, here’s my top five:

  1. Built-in HTTP transaction viewer. I mean they have Fiddler, why not bolt key pieces of it into the browser tools rather than having to launch Fiddler separately?
  2. DOM attribute inspector for those times when you have to dig deep; for example, when there are differences between content attributes and DOM attributes.
  3. Cookie Manager – including the ability to inspect/delete individual cookies.
  4. Automatically associate a selected element with its DOM index. Don’t make me have to hunt for it in a different view and then compare.
  5. Continuous hover and select item on page, without needing to click Ctrl + B every time. Sometimes I want to scan multiple items quickly.

So that’s it. This tool should save you a ton of time. Are there any items that are your favorites, and what do you want added to the wish list?