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.
Wow, you must have been living under a rock for the last 17 years.
Wait. What? I’m not sure that object typing can truly be a measure of “power.”
“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.
“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.
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.
“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.
“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.
Another general, incorrect statement. To me, there are two separate myths here.
“JSON isn’t as descriptive as XML.”
Well, yes and no.
“How can I work with JSON when there is not WSDL?”
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.