Archive

Archive for the ‘JavaScript’ Category

Transparency: Considerations For Choosing a JavaScript / AJAX Framework

September 20th, 2008

A growing number of development teams are given the opportunity to choose their JavaScript / AJAX Frameworks. This choice is often thrown to the development team because the Architects are more concerned with the bigger picture, and the technical details are over the manager’s head. Letting the development team decide on the JavaScript / AJAX framework produces some great benefits: it gels the team, fosters project buy-in, and creates project excitement.

Now, developers can be pretty skeptical, and getting them to agree has been likened to herding cats, but a couple core considerations / values seem to surface when the decision is being made.

Considerations for choosing a JavaScript / AJAX Framework:

  • Transparency - Who are the framework’s development team and why should we trust them? Do these developers blog? Attend conferences? Are they featured on podcasts / videos? Is there a high or low turnover within the team? What are their passions? Is this just a job, do they like what they’re doing, are they a cog on a wheel? Are they experts in their field?
  • Competency - Based on the information gathered in the consideration above (transparency), how competent do we feel the development team is?
  • Community Support – How well is the framework supported on forums and blogs? If something were to go wrong can we gain access to the framework’s development team? Are there widespread experts using this framework readily available?
  • Reputation – How popular is the framework in the industry? Who uses it? Are there any white papers, success stories, case studies available?

One of the easiest ways for a developer to choose a framework is by looking at the developers that built it (and talking with those that are using it). As developers our day job will be stepping into someone else’s code for the duration of the project, working with a framework created by competent developers makes our jobs easy. Frameworks without transparency don’t allow us to gauge the competency of the developers or the framework.

Transparency is essential for JavaScript / AJAX Framework teams, JavaScript itself is open and transparent (not compiled yet), it follows that JavaScript / AJAX Framework along with their teams should also be transparent. When the decision for choosing a JavaScript / AJAX Framework is placed in the hands of developers the frameworks that don’t meet the above criteria sink to the bottom of the list.

The only way to succeed now is to be completely transparent, everything is exposed, everything you do – Gary Vaynerchuk 

Author: Adam Kahtava Categories: AJAX, ASP.NET AJAX, JavaScript, Software Tags:

Cross Language Naming Conventions: Avoiding Verbosity In The Presentation Layer

August 29th, 2008

Most languages and technologies used in web applications come with their own unique naming conventions – which is unfortunate, but necessary, because diversity is important. Languages like JavaScript and PHP use camelCase, CSS uses-hyphenated-delimiters, and ASP.NET / Java / and the like adhere to the conventions used in their respective libraries and frameworks. Managing the different naming conventions in a web application can be difficult, but with discipline, embracing each language’s conventions can provide some great benefits.

A common mistake I’ve made in the past, was trying to make all languages adhere to a single convention. As a budding PHP / ASP developer I took the-single-convention-for-all-languages approach. In retrospect, I used this approach because I didn’t completely understand the language I was using, and in order to compensate for this lack of knowledge, I’d try to meld the languages into the mental model I understood best. This was a mistake.

Today, I find that working with the conventions of the language facilitates re-use (experts in the language understand what I’m doing), promotes portability (modules can be used across projects regardless of server-side technologies), encourages global collaboration (open source modules and plug-ins can be easily consumed and contributed to), and helps to a nurture a more maintainable application (developers from other language domains can easily maintain the application with a relatively small learning curve). Like a carpenter working with fine material, I embrace working with the grain of each language. It’s also fair to mention that breaking free from the monocultured (one-size-fits-all) approach to naming conventions provides a broader perspective, and also makes your development skills more universal – it might even open the door to different development domains in the future.

Then there’s the discussion on name length, verbosity, and using meaningful names. Steve McConnell suggests that the optimum name size for a variable or function is between 8 and 20 characters (Chapter 11, Code Complete), but with tools like ReSharper (for renaming / refactoring etc…) I find myself using names well over 30 characters. So names like GetApproveeTotalFromNamedBasket are a common occurrence in my code. However, like most things, verbosity does need balance (everything in moderation right?). In the business layer, descriptive names are a godsend – they jog my memory as I rediscover what the module I wrote last month was supposed to do. But… in the presentation layer languages (like JavaScript, CSS,  ASP.NET, or XHTML) you may want to reconsider using long descriptive names. Since verbose, long running descriptive names in the presentation layer are passed over the network and can degrade performance. Often times these verbose names are combined together – throw in ASP.NET name mangeling, start hooking in verbose CSS definitions, and then start inserting JavaScript events. All this compounds quickly and result in large page payloads filled with elements like the following:

<div id="ctl00_ContentPlaceHolderForAllTheBestImprotantContent
 _PanelForTheBestReviews"
<a onclick="LinkButtonClick_ThankYouForTakingTheTimeToReadThis();" 
 id="ctl00_ContentPlaceHolderForAllTheBestImprotantContent_
 RepeaterForAllMyFavoriteBookReiews_ctl00_
 LinkButtonMarkReviewAsFavorite"
 class="LinkFormatingCssClass SelectedLinkFormatingCssClass" 
 href="javascript:__doPostBack( 
 ctl00$ContentPlaceHolderForAllTheBestImprotantContent$ 
 RepeaterForAllMyFavoriteBookReiews$ctl00$LinkButtonMarkReviewAsFavorite'
 ,'')">Mark As Favorite </a> 

Note: That mess of code above would fire a JavaScript event then an ASP.NET event. It’s the result of placing an ASP.NET LinkButton, inside a Repeater, inside a Panel, inside a Masterpage, and adding a JavaScript event along with some CSS. We can see that using long names in the presentation layers results in a mess of text. It’s also fair to mention that the ASP.NET MVC Framework lets developers write cleaner presentation code.
Sure, everyone cites premature optimization as the root of all evil, and we do live in a world of gzip file compression and JavaScript minifiers. But… keeping names short in CSS, ASP.NET, and XHTML isn’t hard as long as you’re mindful of the final goal. Smaller names in the presentation layer will reduce the amount of data transferred over the network which increase the performance of the application.

Joseph Smarr of Plaxo.com once said:

Web applications are only slow if you let them get slow – Douglas Crockford, Alex Russell and Joseph Smarr: On the Past, Present and Future of JavaScript [30:00]

My preference (project requirements warranting) is to keep things short and concise in the presentation languages while using longer descriptive names outside the presentation languages. What’s your preference?

Free: Win a Copy of: JavaScript: The Good Parts by Douglas Crockford

July 29th, 2008

JavaScript: The Good Parts by Douglas Crockford is an excellent book. At 140+ pages this book is approachable and easy to read. The writing style is terse and clear, and it’s crammed with good advice.

I thoroughly enjoyed this book and would like to give a copy away. You can read my review here.

Contest Rules:

  • Comment on this post.
  • Leave a valid email in the email comment field.
  • The winner will be chosen at random and notified through email on Oct 1st.
  • I pay for shipping.

Good Luck!

This contest has commenced, and the winner is Luke Maciak!

Author: Adam Kahtava Categories: Book, Contest, JavaScript Tags:

Book Reviewed: JavaScript: The Good Parts by Douglas Crockford

June 7th, 2008

Weighing in at 140+ pages of content, JavaScript: The Good Parts [Douglas Crockford] cuts through the obscurities, pleasantries, and filler found in most technical books. Instead, this book dives straight into the heart of the JavaScript language. It presents the clearest comprehensive explanation of what makes JavaScript a great programming language that I’ve encountered to date. It nails the important concepts, like JavaScript’s: object oriented nature, its classless (pseudoclassical) nature, and functional nature. While covering the fundamentals like JavaScript’s: functions, lexical scoping, lambdas, prototypal inheritance, and functional inheritance.

This book’s size makes it approachable for all audiences, its style is terse and concise. This book has the potential to do for JavaScript, what Richie’s inspirational classic the C Programming Language did for the C language.

JavaScript is the programming language of the web (AJAX), and this book will guide you through the good parts of this often misunderstood language – while this book is an excellent reference, it is not intended to replace JavaScript: The Definitive Guide, you’ll do best to have both these books on hand.

If you enjoyed (or are considering) this book then you may want to learn more of what Douglas Crockford has to say, check out his great JavaScript video series on the YUI Theater.

I highly recommend this book. View my review on Amazon.

Writing a Control for the AJAX Control Toolkit: How ASP.NET AJAX Failed

June 7th, 2008

One of my resolutions this year was to contribute to the AJAX Control Toolkit for the ASP.NET AJAX Framework. I began my AJAX Control Toolkit development quest by digging into the online resources, reading ASP.NET AJAX in Action, and decomposing the AJAX Control Toolkit. I noted the huge learning curve required to developing a control, and continued to dig deeper. Once mired in ASP.NET AJAX a bad smell kept wafting by. Since then I’ve been trying to distinguish this smell.

What’s really wrong with ASP.NET AJAX?

  • It doesn’t plan for performance from day one
  • It treats AJAX as a classic computer science problem
  • It tries to turn JavaScript into a classical language which works against JavaScript’s dynamic, prototypical nature
  • It feels like a framework that was written for dummies (Don’t Write Frameworks For Dummies)

A Case Study: Why Plaxo.com Almost Failed

In the video: High-performance JavaScript: Why Everything You’ve Been Taught is Wrong (YUI Theater) Joseph Smarr discusses the challenges and lessons learned while developing Plaxo.com. While developing this AJAX centric application, the Plaxo team decided to include everything they could think of into their application. They created a framework to treat JavaScript as a classical language, they gave priority to features over performance, and… the project ALMOST FAILED. They were able to salvage their application by diverting their development efforts, making performance one of their top priorities, by unlearning everything they’d been taught about classical applications (instead embracing JavaScript), jettisoning unneeded framework bloat, and more.

Some of the points made in this video were:

  • Plan for performance from day one
  • AJAX is not a classic problem
  • JavaScript is not a classical programming language
  • User experience and a responsive application can make or break an application
  • Unneeded bloat in a framework, and an obtuse approach to using AJAX (treating AJAX and JavaScript as a classical language or classic computer science problem) has the potential to cripple your application

This Channel 9 video also mirrors these sentiments: Douglas Crockford, Alex Russell and Joseph Smarr: On the Past, Present and Future of JavaScript

How ASP.NET AJAX Failed: What can we learn from Plaxo?

The way the Plaxo team approached their application development is similar to how the ASP.NET AJAX Framework has been designed. Like Plaxo’s initial attempt ASP.NET AJAX attempts to mold JavaScript into a classical language, and attempts to treat JavaScript and AJAX as a classic computer science problem by heaping on more abstractions. Like Plaxo’s initial attempt ASP.NET AJAX also gives a low priority to performance. Plaxo was able to change their direction and salvaged their application, but the ASP.NET AJAX Framework is not in a position to make any sweeping changes – ASP.NET AJAX is going down the wrong path and it’s too late.

The ASP.NET AJAX Framework is probably another exercise in Framework Architecture (demoware) and a failure in practice. Its lack of use in the wild attests to these shortcomings – contrast the sites using ASP.NET AJAX with the sites using jQuery (Actions Speak Louder Than Words). Furthermore the places that ASP.NET AJAX does thrive (the small internal ASP.NET business apps that need some bling-bling) will also be the areas that Silverlight shines – Silverlight offers a better Microsoft centric programming model (less leaky Win Form / Web Form abstractions) that most Microsoft developers will embrace. Silverlight will probably divert the developers that currently embrace ASP.NET AJAX.

I don’t recommend the ASP.NET AJAX Framework and won’t be contributing to the AJAX Control Toolkit. My time is better spent elsewhere.

Author: Adam Kahtava Categories: .NET, AJAX, ASP.NET, ASP.NET AJAX, JavaScript Tags:

More on the perils of The ASP.NET AJAX Framework

June 3rd, 2008

There’s no need to whip a dead horse (I’ve probably been griping about the ASP.NET AJAX Framework for too long), but… Jon Galloway and a group of other notable gurus (K. Scott Allen, Scott Koon, and Kevin Dente) have started a podcast, their latest segment sparked my interest since it covered ASP.NET AJAX and AJAX Libraries / Frameworks in general.

I share their sentiments so I thought I’d post a brief but choppy transcript:

[ASP.NET AJAX] … does offer some some nice features, they did try to take some of the common pieces of the CLR that [.NET Developers are] used to working with and move that down into a JavaScript library. So you get classes like a WebRequest class that wraps the XMLHttpRequest … and they have a StringBuilder, and they added methods that we’re more accustom with …

that’s wonderful, but I don’t find myself needing those extensions all that often. If you want to do strictly client-side programming then something like jQuery offers you a lot more capabilities to do things that you really want to do client-side like sorting and CSS selectors. … That stuff is easy to do with an Update Panel and ASP.NET, but Update Panels aren’t always the best solution to use. …

the goals with ASP.NET AJAX was to integrate into the ASP.NET server-side model … that’s great for ASP.NET, but it needs more client-side features. … It works if your thinking from the ASP.NET control perspective, but if you look at it outside the ASP.NET model there are a lot easier ways to do it.

ASP.NET AJAX [development] seems to have come to a standstill I’m not seeing a lot of development in that area and the rest of these [AJAX] Frameworks are doing monthly releases. Every month that goes by [the ASP.NET AJAX Framework] falls further and further behind … it needs to evolve.

Listen to this podcast here: Technology Round Table Podcast #2 – AJAX Frameworks

Author: Adam Kahtava Categories: .NET, AJAX, ASP.NET, ASP.NET AJAX, CSS, DOM, JavaScript Tags:

The Good Parts of The ASP.NET Framework and Visual Studio

May 31st, 2008

Douglas Crockford opens his latest book with these words:

Most programming languages contain good parts and bad parts. … [the language designers or architects] are usually powerless to do anything except heap more features on top of the existing pile of imperfections. And the new features do not always interact harmoniously, thus producing more bad parts. – JavaScript: The Good Parts by Douglas Crockford

His words can apply to all programming languages and frameworks. Like the Microsoft .NET Framework, Visual Studio, Java, and Eclipse.

Bad parts in the ASP.NET Framework and Visual Studio:

  • ASP.NET Themes and Skins
  • The ASP.NET AJAX Framework
  • ASP.NET / Visual Studio Inline Style Properties
  • Visual Studio Design View
  • ASP.NET and Visual Studio’s over dependency on XML configuration files

It would be great if someone wrote a book outlining the good parts of ASP.NET and Visual Studio. :)

Author: Adam Kahtava Categories: ASP.NET, JavaScript, Musings, Themes and Skins Tags:

Getting a Job at Google: A Web Developer Fizzbuzz

May 24th, 2008

Back when the web turned 2.0, AJAX was all the rage, and gas was cheap, a Google recruiter contacted me. We worked through a couple screening interviews – I explained how I was a .NET / ASP.NET / C# developer with some experience with Java and PHP, I described how C# was somewhat similar to Java. Things went great, I moved on to the next step of the process – writing code (a JavaScript widget for Gmail) with a 2 day (weekend) hard deadline. At the time I was wearing JavaScript diapers, but tried the exercise anyways – I'm still convinced the recruiter confused my Java / C# experience with JavaScript. Anyhow…

The Google Web Developer Exercise:

Web Developer Exercise

Attached are three states of a new contacts widget. This widget will be used across Google and may be anywhere on the page. Designers will also use this in mocks for usability tests. Create the HTML, CSS, and JavaScript for the widget as described in the image. Your solution must work in Firefox v1.5+ and IE v6+. Bonus points for a solution that degrades nicely on older browsers.



After my first attempt, I concluded that:

  1. My JavaScript knowledge was embarrassing
  2. Dynamic programming languages like JavaScript using prototypical inheritance were awesome – as a monocultured .NET developer I had sorely been missing out
  3. Framework Web Developers (ASP.NET, Ruby on Rails, and so on) aren't really Web Developers – we depend on a framework (an API) as a crutch, where the law of Leaky Abstractions is very real, and often when it rears it's head we use our golden hammer (our multipurpose language of choice), but there are better tools at hand
  4. Web Developers claiming n years of experience need to at least know JavaScript, CSS, HTML / XHTML, a server-side language, and some XML / XSL – NOT just a single multipurpose language or framework
  5. Innovation can only happen when you become one with the technologies surrounding your realm – for example: Jesse James Garrett probably would not have publicized AJAX had he been an exclusive ASP.NET developer. Diversity is essential for innovation

In retrospect this exercise is brilliant, it's a more complex derivation of a Fizzbuzz exercise, which effectively weeds out the knowledgeable candidates from the n00bs. JavaScript is notorious for being one of the world's most misunderstood language, many developer (and the ASP.NET Framework) still use JavaScript techniques from the old days of Netscape. For example: <a onclick=”return false;” …, or <a href=”Javascript: do something;” … are common DOM Level 0 inline techniques that should be avoided. These techniques have been replaced, but finding developer that use these JavaScript techniques can be hard.

By having a developer complete this exercise you effectively determine that the they understands these concepts:

  • Cross browser compatibilities and work arounds for both JavaScript and CSS – with a preference given to feature detection (object detection) vs browser detection, an understanding of the different event handling models between browsers
  • An understanding of the separation of concerns – JavaScript, markup, and CSS should be separate files, or at least separated within the document
  • Event registration and listening – DOM events, the different browser event models, no inline level 0 event declarations, no pseudo JavaScript protocol inline declarations within markup
  • An understanding of functional languagesclosures, namespaces, lambdas, recursion where necessary
  • Node manipulation – creating, swapping, removing elements
  • Knowledge of non-obtrusive JavaScript techniques
  • Importance of modular / compartmentalization of CSS and JavaScript – defensive programming techniques that minimize the risk of interfering with other scripts and elements within the page, part of the non-obtrusive techniques, how to avoid global variables
  • An understanding on how to debug JavaScript from both IE (link) and Firefox (link)
  • JavaScript code conventions – naming conventions, statement conventions
  • CSS naming conventions
  • General DHTML / AJAX techniques – showing and hiding elements
  • A gauge on their attention to details and UI design intuition – what their gut tells them to do when things aren't spelled out

My latest crack at the Google Web Developer Exercise:

You'll have to visit my site (view this blog post outside a RSS reader) to view the code in action.

The code: GoogleExercise.js, index.html, GoogleExercise.css

Today I'm wearing JavaScript training wheels – feel free to comment on the code, I'm always looking for improvements and suggestions. I did take a couple shortcuts on the CSS / UI side of things as I was focusing more on the functionality.

Using one of the AJAX Libraries (like jQuery) we could certainly do this exercise in significantly fewer lines of code.

Today I still think about Getting that job at Google, Yahoo!, Amazon, or Microsoft. How well do you know JavaScript?

Update: I redid the Google Exercise using jQuery and more semantics, you can find my latest version here: The Google Exercise Revisited: Semantic Markup with jQuery.

Actions Speak Louder Than Words: Goodbye ASP.NET AJAX

May 15th, 2008

An anticlimactic conclusion about the ASP.NET AJAX Framework – this framework’s niche seems to be the internal (intranet) business application realm that depend on ASP.NET Web-Forms. These applications have a handful of users, a couple developers, no performance or bandwidth requirements, little ambition for future growth, and the developers typically embrace dragging & dropping controls in Visual Studio. In this case the ASP.NET AJAX Framework provides some eye candy, and patches the broken Web-Form metaphor by cramming AJAX into the ASP.NET model, but then comes along the ASP.NET MVC Framework, Silverlight, WPF and … ??? Goodbye ASP.NET AJAX!

Interesting observations:

How many applications explicitly state that they use the ASP.NET AJAX Framework?

  • 25, this includes sites like DotNetNuke (with a reputation of being slow), view the list here.

How many of these applications are relatively high-traffic?

  • None. ZERO!

How many applications explicitly state that they use the YUI library?

How many of these applications are relatively high-traffic?

  • Quite a few. A couple notable sites: Flickr, Slashdot, Linkedin, Paypal, O’Reilly, My Opera.

How many applications explicitly state that they use the jQuery AJAX Library?

  • 516 and growing, view the list here.

How many of these applications are relatively high-traffic?

  • Many. A couple notable sites: Twitter, Digg, Dell, Slashdot, BBC, Netflix, Technorati, New York Post.

If no high-traffic application uses the ASP.NET AJAX Framework then why would you? Actions (or lack of action) often speak louder than words, and it appears that the ASP.NET AJAX Framework is not suitable for the real world.

Author: Adam Kahtava Categories: .NET, AJAX, ASP.NET, ASP.NET AJAX, JavaScript Tags:

The ASP.NET AJAX Framework is for Dummies

April 21st, 2008

The ASP.NET AJAX Framework is an embarrassing server-side centric approach to DHTML / AJAX web development. While most programming languages and frameworks come with both good and bad parts, the ASP.NET AJAX Framework is an example of a bad part – on the contrast the ASP.NET MVC Framework looks to be a good part.

What’s wrong with the ASP.NET AJAX Framework?

1 .NET Developers are DUMMIES!
The ASP.NET AJAX Framework appears to have been designed under the assumption that .NET developers are dummies and can’t learn or don’t want to learn JavaScript. That .NET Developers would rather hobble along with their familiar languages, then to learn something new. I understand that the ASP.NET community’s only real problem is education, so let’s ask: What is wrong with the ASP.NET Community? Then educate ourselves rather than becoming the .NET Developer statuesque. It’s patronizing to use a framework that assumes learning a new language is beyond our capabilities. Many of these other programming languages are more expressive than statically typed languages like most of the .NET languages. 

2. The “don’t write a line of JavaScript” abstraction leaks like a sieve
The Framework is intended to shelter .NET Developers from the JavaScript language. Which, like driving a car across North America without knowing how to pump gas, stops you dead. Either you depend on someone to pump your gas – depend on a 3rd party (vendors or the ASP.NET AJAX Control Toolkit) and their many authors to write your JavaScript – or you stop moving. As Web Developers, sooner or later learning how to pump your own JavaScript becomes a mandatory skill.

3. Client-side programming from the Server-side is a absurd
The AJAX Framework does back flips to translate server-side code into JavaScript, and then requires that you write JavaScript anyway. Save yourself the pain, learn JavaScript. One day The Law of Leaky Abstractions comes into play, the gas station attendant fills your gas tank with diesel – the AJAX Control Toolkit blows requires debugging and you have to learn JavaScript anyways.

4. Bloated, poor performance, bad user and developer experience
The AJAX Framework extends many of the native JavaScript objects as it attempts to turn JavaScript into a staticly typed programming language, and tries to hook into the ASP.NET life cycle, but all these features are unneeded as they are ALL already achievable through the native JavaScript language – if it walks like a duck and quacks like a duck, then… err… could someone remind me why we need typed languages in a web browser? Anyhow; all these object extensions, enhancements, and upgrades, contribute to more scripts that need to be downloaded and increases the number of scripts running in your browser. Then there’s partial-page rendering and Update Panels which do full page post backs under the guise of AJAX. BAD! Client-side scripting is supposed to enhance the user experience not make it worse. Other AJAX Frameworks are built with performance as their number one goal, but in the ASP.NET AJAX Framework adding more widgets to JavaScript seemed to be the first priority, and performance an after thought.

5. Working against the grain is a waste of time
The AJAX Framework works against the grain, it would be nice if it embraced the JavaScript language. Very few of the concepts and metaphors used in the ASP.NET AJAX Framework transcend AJAX techniques or frameworks - your time is probably better spent learning how JavaScript works or how the other AJAX frameworks work.

6. Disconnected from the ASP.NET MVC Framework
The ASP.NET MVC Framework throws the ASP.NET life cycle away leaving more dead weight ASP.NET AJAX Framework script and rendering many of the AJAX Framework techniques moot.

7. The ASP.NET AJAX Framework almost over looks the ‘J’ in AJAX – ‘J’ stands for JavaScript (that’s GOOD)
JavaScript is the glue of the web, even the ASP.NET Framework depends heavily on JavaScript, it is not something to shy away from.

8. Aside from local intranet sites, no one really uses the ASP.NET AJAX Framework.
The AJAX Framework isn’t widely used. The ASP.NET AJAX site showcases 25 sites using ASP.NET AJAX. None of these applications appear to be high-traffic or moderately high-traffic applications. On the other hand, the YUI site showcases 89 sites, out of these sites, 6 sites (flickr, Slashdot, Linkedin, Paypal, O’Reilly, My Opera) could be considered high-traffic. Other AJAX libraries like jQuery, and Dojo compare similarly. Your time might be better spent learning one of the other AJAX frameworks.

If we (as .NET Developers) are going to claim we know AJAX, then let’s focus on the core of AJAX (JavaScript) and stop obscuring it in poor frameworks. Frankly the ASP.NET AJAX Framework is embarrassing, the web development community is laughing at the ASP.NET AJAX Framework and the Developers touting it.