Archive

Archive for April, 2008

Free: Win a Copy of Beginning CSS: Cascading Style Sheets for Web Design

April 24th, 2008

Beginning CSS: Cascading Style Sheets for Web Design by Richard York is a great book for any web developer looking to thoroughly understand CSS.

This book was required pre-reading for my latest Technical Editing task – I'm editing Mr. York's newest book. So in the spirit of spring, de-cluttering, and giving. I'd like to give this book away. This book is like new with a couple minor dings (from an airport fiasco), it is in full color (like all good design books should be), and it's free!

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 Canada Day (July 1st).
  • I pay for shipping.

Good Luck!

The contest has ended and the winner is Devin Parrish!

Author: Adam Kahtava Categories: Book, CSS, Contest, DOM 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.

Book Reviewed: ASP.NET AJAX in Action by Alessandro Gallo, David Barkol, Rama Vavilala

April 20th, 2008

The authors of ASP.NET AJAX in Action did an OK (Average) job at presenting the ASP.NET AJAX Framework. However; this book lacked objectivity and suffered from hype. The authors didn't seem to have proficient experience with the JavaScript language, or enough experience with other AJAX Frameworks / Libraries, or sufficient experience using the ASP.NET AJAX Framework in real world projects. This book sadly felt like most technical books – average.

Comments like “we recommend that…”, “because it makes no sense…”, “you must rely on a special method…”, “you must understand X,Y,Z to run complex client-side code without writing a single line of JavaScript” were discouraging. Many of the “whys” were left answered and the technical inner workings of the framework often trivialized. Don't get me wrong, writing a book is incredibly time consuming, but if you're an author, presenter or the like, and you don't fully understand something then admit it. Do some research, provide some links, or move on. Consistently making comments like these bring the integrity of the whole text into question.

The ASP.NET AJAX Framework itself is technically flawed, bloated, and almost entirely impractical. I was disappointed with the server-centric approach that both the book and ASP.NET AJAX Framework takes. I was disappointed that the book continually pushed JavaScript under the carpet as magic and at the end of the book I was pleased to see the promise of making “the JavaScript code disappear” never was  fulfilled. JavaScript is the very most important part of AJAX, without the 'J' in AJAX, we're left with nothing – just 'Asynchronous', 'And', heaps of more ugly 'XML'.

When reading this book, take the contents and the ASP.NET AJAX Framework with a grain of salt, if you're really serious about learning AJAX then read JavaScript: The Definitive Guide by David Flanagan.

I typically only contribute positive reviews, but I don't agree with the majority of reviews found on Amazon and hope this review provides some objectivity. I commend the authors on their hard work, I'm probably being too harsh with this review – I know it's tough to write a book, and imagine they made many sacrifices as they worked towards tight deadlines.

View my review on Amazon.

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

How To Choose a Good Technical Book

April 16th, 2008

The quality of technical books have wide variations between publishers and authors. While choosing a book based on the author is reliable, depending on a publisher or brand name is not reliable, and choosing a book based on advertisements is even less reliable. It makes sense to choose your books wisely since most technical books live a short life (the duration of a single project), cost money, and require precious time to be read.

When choosing a book I follow this heuristic approach:

  • Ask experts in the field (friends, forums, newsgroups) for recommendations
  • Ask these experts to differentiate between the high level books and the books that take a technical deep dive.
  • Filter out (discard) the high level recommendations.
  • Filter out (discard) all recommendations that contain the following keywords in their title:
    • Cookbook
    • Problem – Design – Solution
    • Hacks
    • Tips
    • Learn X in 24 hours
  • Look for recognizable authors.
  • Cross reference these recommendations through Amazon's Reviews:
    • Books with over 100 excellent ratings on Amazon are instant winners – the Amazon community is rarely misleading.
    • Books that haven't received more than 50 ratings should be considered with skepticism – visit a local book store and skim through the text in question before making the purchase.
Author: Adam Kahtava Categories: Book, Musings, Software Tags:

The ASP.NET AJAX Learning Curve

April 9th, 2008

The ASP.NET AJAX framework comes with a lot of baggage err… I mean… a huge learning curve when compared to other AJAX Frameworks like JQuery, YUI, Dojo, Prototype / Scriptaculous.

Here's a running list of the technologies, and concepts you'll encounter when digging into ASP.NET AJAX:

  • ASP.NET
    • The Page Life Cycle
    • The Control Life Cycle
    • Web Controls
    • User Controls
    • View State
    • Session State
    • Events
  • .NET / Classical Language
    • Interfaces
    • Inheritance
    • Delegates
    • Multicast Delegates
    • Assemblies
    • Properties (Get / Set)
    • Constructors

In addition to these, you also have the technologies universal to all JavaScript libraries:

  • JavaScript:
    • Closures
    • Object Literals
    • JSON
    • Events
    • DOM Manipulation
    • Prototypical Inheritance
    • Constructors
    • XMLHttpRequest
  • Cascading Style Sheets (CSS):
  • Web Services

The ASP.NET AJAX Framework is more complex than other AJAX frameworks, I'm continually lost in it's ambiguity as it attempts to skirt around the JavaScript language – I think this learning curve (and all it's confusion) is precisely why Silverlight has so much potential.

I'm still diving into the low-level details, but my first impressions of the ASP.NET AJAX Framework are:

  • Obscure, ambiguous, no clear vision – it offers multiple (resource intensive) ways to avoid writing JavaScript, but then requires that you write JavaScript anyways
  • Too server centric
  • Too heavy weight (I'm not appreciating how they're trying to turning JavaScript into a Java, C#, .NET clone, the overhead within the browser for these conversions seems like a huge performance bottleneck)
  • Has the potential for poor performance

Most of the other AJAX libraries have been written with performance, browser responsiveness, and User Experience as their number one priorities – I'm still not sure about ASP.NET AJAX.

How many ways can we try to avoid writing JavaScript? If an AJAX library doesn't enhance the User Experience then why use it? Regardless, I'm still digging deeper.

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

A Reflection on Themes, Skins, and Cascading Style Sheets (CSS) in ASP.NET 2.0 (A Final Conclusion)

April 7th, 2008

A couple years ago I was thrown into a web application that made heavy use of ASP.NET Themes and Skins. Prior to this I depended exclusively on Cascading Style Sheet (CSS) for my web development / web design needs. A first glance at ASP.NET Themes and Skins looked promising, but a number of flaws surfaced – see the links and issues listed at the end of this post.

In addition to these issues, here are a couple other considerations when thinking about ASP.NET Themes:

  • Themes do not adequately separate the levels of concerns within your application. When using Themes all design related files are baked into the application. From a maintainability standpoint, this doesn’t bode well in large web applications. Hosting design related files on a single server or an external Content Delivery Network (CDN) is an effective way for managing site wide UI updates and increasing a sites performance, ASP.NET Themes works against this technique.
  • Themes add unneeded complexity by obscuring the real technologies at work (CSS). Everything that ASP.NET Themes offer can be better achieved outside of the ASP.NET Theme Framework. Technologies like Cascading Style Sheets (CSS),  alternate Style Sheets, and JavaScript can achieve more than Themes can provide.
  • Themes are a server-side mechanism. Themes become a nuisance in client-side dependent, heavily dynamic, Web 2.0, DHTML, AJAX type web applications.
  • Themes discourage developers from learning more about web design and the technologies surrounding it. Themes offer a seemingly simple API, which shelters developers from the complexities of CSS and JavaScript, but sooner or later The Law of Leaky Abstractions comes into play and knowing the fundamentals of these technologies is a necessity.
  • Professional web designers don’t use ASP.NET Themes, CSS is the language of web designers.

Default Skins on the other hand can be useful for defining consistent CSS hooks into common ASP.NET controls. It’s unfortunate that we can’t use Skins without Themes.

Related posts:

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

Founders aren’t Employees, but neither are Consultants

April 1st, 2008

In You Weren’t Meant to Have a Boss, Paul Graham makes some clear distinctions between Founders and Employees. A similar Founder Vs Employee thread was presented in Joel Spolsky’s recent article How Hard Could It Be?: Lessons I Learned in the Army. Spolsky goes on to make the point that Employees do not have the same ambitions as Founders, and that Founders need to realize this dichotomy – that Employees are interested in today (short term) whereas Founders are focused on the long term.

The great employees will be devoted, sure, and it’s completely reasonable to expect them to work their butts off. But unlike founders, employees are concerned about what their jobs are like today. They’re not as excited about making sacrifices for the long run. I can always tell the founders who haven’t figured this out yet, because they’re disappointed in all their employees, firing good people left and right and constantly asking, “Why hasn’t Joe (or Jane) gotten this work done yet? I could have finished it in one weekend!” – Joel Spolsky: How Hard Could It Be?: Lessons I Learned in the Army

Both these articles highlight the differences between Employees and Founders, but what about Consultants?

Consultants can often fall under the full-time Employee umbrella, but probably have an even shorter term interest in their client. Part of a consultant’s job is to maintain objectivity, to distance themselves from becoming financially, emotionally, and personally invested in their client – objectivity is lost when an attachment or investment is made.

According to Janet Ruhl a couple of the biggest Gotchas in consultancy work can be:

  • Investing in your client – purchasing shares in your client or agreeing to software royalties rather than a pay cheque.
  • Being manipulated into working for free.

Consultants are kind of like Employees, but different. Consultants probably have an even shorter term interest in the company they work for then Employees do. I think it’s important to highlight these differences.

Author: Adam Kahtava Categories: Musings, Software Tags: