I am amazed by architects and developers who posses a fear of the unknown and drive their decisions based on old information and technology myths. Instead of researching and gaining knowledge to other technologies, some chose to use their feelings instead of facts to drive their projects. This behavior can ultimately hurt real progress and innovation. What I am most amazed by is how scared some technologists can be when it comes to Web User Interface technologies. In the technology business, you have to be curious, open-minded and ask questions versus putting up a blockade and making excuses. We are supposed to be solutions people.

The following are some of the myths I have heard relating to Web User Interface technologies and my rebuttal to these excuses for not implementing rich internet applications. I am sure there are many other stories, myths and rebuttals and encourage you to share yours by leave a comment below.

“Browsers don’t have enough power to do heavy work.”

I’m not sure what kind of browser you are running, but mine has a V8 engine in it. Just sayin…

Modern browsers have grown into an excellent container for running applications on a variety of platforms. They have evolved significantly over the last decade and the support of these application containers goes much farther than in the past. Browsers are very capable of running numerous processes and perform multiple simultaneous operations, complete with direct hardware access and graphics capabilities. These are not the Netscape browsers from 15 years ago.

“End user’s are running computers that can’t support heavy processing.”

I’m not sure what constitutes as “heavy,” but I can tell you that no one is expecting the client-side technologies to handle order processing and a gazillion bytes of big data here.

In most businesses I have been involved in, users are provided new equipment at least every 2 to 3 years. Let’s say worst case scenario, your user’s equipment is 5 years old. Five years ago, the general computer hardware available was a 2.0 GHz dual core or hyper-threaded processors packing 1GB of memory running Windows XP. If this hardware can’t run your RIA application, there must be some significant architectural or code issues in the application.

isn’t mature.”

Wow, you must have been living under a rock for the last 17 years.

JavaScript has evolved through 5 versions of the ECMAscript standard. All mainstream browsers have the ability to use JavaScript. Most popular modern JavaScript frameworks have been in development for over 3 to 5 years and have seen multiple revisions and updates based on the evolving standards of Browsers, and . In the world of modern technology, this is almost ancient.

“JavaScript is not a strong typed language, therefore it isn’t as powerful as Java.”

Wait. What? I’m not sure that object typing can truly be a measure of “power.”

It is true that JavaScript is a weak typed language. I would argue that in its context being weak typed is a great feature that provides incredible flexibility rather than a hinderance. It is simple and effective for a non-compiled language. However, “with great flexibility comes great responsibility.” It requires that the user is explicit in writing code that explains what kind of input and output are expected. If an explicit type is needed, the code needs to check and validates the type and throws errors accordingly. On the flip side, if I have an instance that a simple object may be equal to a string or an integer, I don’t have to jump through hoops to evaluate them. Since most input from the browser are strings, this can greatly simplify handling of this data on the client-side.

“RIA is too bleeding-edge, are we getting ahead of ourselves here?”

Let’s be honest, we are in technology and this is a fast running business. Things change daily. Either get on this bullet train or jump off at the next station.

If you aren’t building RIA applications, you are on the wrong end of “bleeding-edge.” The whole Web 2.0 world started almost a decade ago. I’d argue that we are seeing the dawn of “Web 3.0” already. The reality is, you are behind the times if you aren’t already building your applications using a rich client architecture.

“We tried thick client architecture before and it was a pain.”

Well, sure. Fair enough. But, many of the pain points in the past were because you weren’t using the web.

Pushing application logic into the client is much easier when you are using the web as a delivery method. It is built into the nature of HTTP to deliver the application and the latest version simply and quickly. Because of browser standards and support, there is much less hassle and you can support many different environments and platforms versus a desktop-based thick client architecture.

“Well, I don’t know client-side web technologies, so we can’t do it.”

So you do work on the web, but don’t know how to create an interface for it? How does that work? Ohh, not very well. Yeah.

I get that HTML, CSS and JavaScript aren’t your first or favorite technology, but not being able to work or architecturally design a web application using them is a big problem. Without a usable interface your application is worthless. If you aren’t interested in learning about different technologies, you are in the wrong business. Otherwise, you better get a UI developer on your team or make a friend with one soon if you expect your next project to be successful.

“But how are we going to support IE6?”

We aren’t going to be supporting IE6. This is 2012. It is dead. There was even a funeral for it. Microsoft sent flowers. Numbers show that no reasonable human being is actively using it. Why are we having this argument?

There is no circumstance at this point to be actively supporting IE6. The proper solution if a user needs support for IE6 is to upgrade their browser to the latest version available for their operating system. Ideally, this upgrade would be to a Webkit or Mozilla-based browser.

“But what about IE7 and IE8?”

Its unfortunate. IE7 and IE8 still have some annoyances and limitations. It is true that neither of them have much support for HTML5 and CSS3.

On the good side, they are much more capable than IE6. On the better side, JavaScript libraries abstract many of the difficulties presented with Internet Explorer when writing cross-browser web applications. With the death of IE6, The IE drama is nothing like it used to be. I would even challenge architects to find ways to not support Internet Explorer. The idea is less far fetched that you might think. Know your audience and what technologies they use.

“JavaScript is not a robust language.”

I have no idea what this really means, but I have heard it. It has become a great joke amongst my team. In fact, I had this thrown in my face this morning. Fortunately, it was a joke.

A summary of dictionary.com’s definition of robust as it might apply to JavaScript is an adjective meaning “strong and healthy; strongly or stoutly built, rich and full-bodied.” I don’t see how any of these accurately describe JavaScript. It is very strong for its purpose and does everything I can think that it should do in a browser (or even on a server these days). It is healthy and not a dying language. In fact, it is thriving as an important part of the web UI trifecta along with HTML and CSS. As for Rich and full-bodied, I’d say it is not bloated. It is basic and allows you to build upon it. There are many libraries and frameworks available that offer utilities and widgets that I would describe as rich and full-bodied. I could probably go on for days talking about this one.

“Rich Internet Applications are not sustainable.”

This has become another inside joke on my team, originating from the XKCD comic: Sustainable.

I like to define and breakdown terms before discussing them because some folks like to use words that they don’t really know what they mean or know the partial meaning of. Yes, I am guilty of this too. Sustainable is an adjective meaning “able to be maintained at a certain rate or level.” So lets just say this breaks down in software development to the ability to maintain software and have it maintain a standard of quality. Fair enough.

So how does this statement apply to JavaScript or any other language? In my mind, this is more of a problem with the developer or an architect that doesn’t know enough about the technology he is supporting rather than a problem with the technology itself. Any language is easily sustainable if you know what you are doing. Documentation and test scripts can assist with making any technology sustainable. This is not a limitation of client-side technologies on their own.

“Whoa wait, we can’t put that business logic into the browser.”

I am going to question what you call business logic. Are you sure that your process isn’t really just presentation logic?

Over the last decade or so, generally practiced architectural patterns in the web space have really blurred the lines between business, application and presentation logic. For the most part, they have been lumped together and the lines have blurred. This lack of separation has made it difficult to make a solution sustainable. [See what I did there :)] Really break down what you are trying to do and honestly tell me that your process is mission critical or trade secret. Can the user manipulate something on the client that breaks a business process? Obviously put your real business logic on the server, but if what you are doing really is about how data is presented to the user, consider making this a part of your client application to create better user experiences.

“JavaScript doesn’t support classes so we can’t reuse code.”

Another general, incorrect statement. To me, there are two separate myths here.

First, JavaScript has the ability to support “classes” in a sense as a function are basically a class using prototypical or closure patterns. There are many different patterns and frameworks for supporting modules and plugin architectures. Second, these patterns make it very easy to create usable code. Not to mention, simply writing basic functions can be reusable by copying code between projects or including the JavaScript between multiple files.

“JSON isn’t as descriptive as XML.”

Well, yes and no.

It is true that you can do some pretty detailed things with XML with the use of attributes and nested structures. XML requires that this description is spelled out. JSON implies some of this description based on arrays and data types. But after using JSON a s data format for some time now, I don’t miss using XML. I have simply and easily created objects that are well defined and supported in JavaScript without any lack of description.

“How can I work with JSON when there is not WSDL?”

Very easily!

The beauty of using JSON with RESTful resources is the concept of affordance. The API’s should follow a simple, well understood structure just by knowing about of the resource. Although WSDL’s are nice to define the XML, I find that good written JSON patterns are easier and simpler to follow and work with. I could also argue again of the importance of human readable documentation. This applies in the XML or JSON worlds.

“CSS is messy and hard to follow. Lets keep it basic and not over complicate things.”

Agreed. CSS can be messy and hard to follow.

We should all strive to keep it basic and not over complicate things in any technology, not just CSS. Fortunately, we have some new libraries that can make CSS more manageable, maintainable and dynamic using projects like SASS and LESS.