Archive for the 'Ajax' Category
A couple a weeks ago I attended to the Web 2.0 expo, I did it for a few reasons, one was to learn from people, its incredible what you can learn just by talking with people in this kind of events, but also a very important reason was to know what is going on with the UI technologies today, what new companies are using, is people really implementing HTML5 features, what is the feeling about Flash/Flex etc. I was not surprise to me that many people are still relying in Flash in one or another way, some people choose Flex for different reasons, Video, more interactive UI, faster development, easy deployment, real time data, etc.
Many people tend to compare them and say that HTML5 will replace Flash, many of those are people that have never done any Flex/Flash application and probably don’t have the enough knowledge about Flash technologies to make that bold statement.
Before I say anything, I have to say that I like HTML very much, but I like Flash/Flex too. One thing is clear, “free and standard” technology is most of the time better than “proprietary standard” technology, but as always, your requirements should drive the decision of picking the right technology. Sometimes when you are trying to do something that “free and standard” can’t do, you can always consider a well accepted and distributed technology that gives you much more.
HTML5
-Is much more than just a structure markup language (currently there is a debate about HTML5 is the specification name only and still want to keep the name of HTML only), most of the time implicitly includes CSS, Javascrip, jQuery, Ajax, etc.
-Its currently W3C is currently in a draft format and constantly changing (Adobe, Google, Microsoft, Apple are participating).
- The big changes are:
- , , .
-Enriched semantics.
-Offline storage, database.
- More: http://www.xibl.com/web-development/html5-features-tips-and-techniques-you-%20must-know/
Ajax
At this point Ajax is a very stable and well accepted technology implemented successfully on many libraries. Mostly used on a HTML presentation but also used on Adobe Air.
Flash
Is a complete platform, not only a technology to build applications and not directly comparable to HTML.
It uses ActionScript that is ECMA262 based dialect for declaring dynamic behavior.
Includes side channel communications like RTMP.
They both things that the other one don’t have, and they both have cons.
For example:
Flash HTML
Anyone can provide input? Yes Yes
Standard can change? (Drop API) Yes Yes(Web SQL)
Vendor advantage or control Yes Not likely- Possible
Consistent implementations (+) Likely (-) Likely
Speed of Innovation Faster Slower
Current state of innovation Active Active
The truth is that HTML5 and Flash should not be compared at this point, HTML5 specification does not cover all the features that Flash provides, so Flash is still going to be the preferred technology for some kind of applications, and HTML5 new features will take a few years to be adopted by all the browsers (http://html5readiness.com/). There are enough applications out there and enough different requirements that both can live together and help each other.
I like to finish with a say from John Nack:
“This isn’t about one technology (HTML, Flash) vs. another; it’s about putting customers, and the solutions to their problems, ahead of any technology.”
The growing adoption of Ajax and DHTML in web applications, have caused the creation of hundreds of open source Javascript libraries and pages have more of those than ever before plus the custom code counting thousands of lines of code in a single page load.
One of the techniques to make your application run faster is making sure you only load the necessary javascript for initialization and rendering, splitting your javascript libraries, leaving the unnecessary javascript payload to for later.
As a developers we know splitting and keeping the javascript files clean is not an easy tasks, and gets worst when multiple developers with different skill levels are modifying it, but by doing it you can get a significant faster rendering.
You can do this splitting manually by using Firebug and getting a list of functions that are executed “onload” but reading about this technique, I found Deloto. Doloto is a system developed by Microsoft Research for automatically splitting JavaScript into clusters. The first cluster contains the functions needed for initializing the web page. The remaining clusters are loaded on demand the first time the missing codeneeds to execute, or they are lazy-loaded after the initial flurry of JavaScript activity is over. When applied to Gmail, Live Maps, Redfin, MySpace, and Netflix, Doloto reduced the initial JavaScript download size by up to 50% and reduced the application load time by 20% to 40%.
I haven’t tried it yet, but it seems like a good thing to test or just to get an idea of how we can manage our javascript files to reach one of or main goals of having an application that performs as fast as possible.
If somebody have use it, it would be interesting to hear from you.
Reading a book about Javascript performance I found this and I think is very interesting and clear the position of Brendan Eich, the creator of JavaScript and Mozilla’s chief technical officer:
You must be [as tall as an NBA player] to hack on threaded systems, and that means most programmers should run away crying. But they don’t. Instead, as with most other sharp tools, the temptation is to show how big one is by picking up the nearest singlethreaded code and jamming it into a multi-threaded embedding, or tempting racecondition fate otherwise. Occasionally the results are infamous, but too often, with only virtual fingers and limbs lost, no one learns.Threads violate abstractions six ways to Sunday. Mainly by creating race conditions, deadlock hazards, and pessimistic locking overhead. And still they don’t scale up to handle the megacore teraflop future.
So my default answer to questions such as, “When will you add threads to JavaScript?” is: “over your dead body!”
Given Brendan’s influence in the industry and on the future of JavaScript (which is considerable), and the broad degree to which this position is shared, it is safe to say that threads will not be coming to JavaScript anytime soon.
When we are seeking for creating a responsive, high performance application, specifically on HTML/Javascript, you most of the time ask the developers to write the most efficient code and optimize to make it “as fast as possible”, but how can you know how fast is fast enough? fortunately, this evaluation was already done for us.
Jakob Nielsen is a well-known and well-regarded expert in the field of web usability; the following quote (http://www.useit.com/papers/responsetime.html) addresses the issue of “fast enough”:
The response time guidelines for web-based applications are the same as for all other applications. These guidelines have been the same for 37 years now, so they are also not likely to change with whatever implementation technology comes next.
- 0.1 second: Limit for users feeling that they are directly manipulating objects in the UI. For example, this is the limit from the time the user selects a column in a table until that column should highlight or otherwise give feedback that it’s selected. Ideally, this wouldalso be the response time for sorting the column—if so, users would feel that they aresorting the table.
- 1 second: Limit for users feeling that they are freely navigating the command space without having to unduly wait for the computer. A delay of 0.2–1.0 seconds does mean that users notice the delay and thus feel the computer is “working” on the command, as opposed to having the command be a direct effect of the users’ actions. Example: If sorting a table according to the selected column can’t be done in 0.1 seconds, it certainly has to be done in 1 second, or users will feel that the UI is sluggish and will lose the sense of “flow” in performing their task. For delays of more than 1 second, indicate to the user that the computer is working on the problem, for example by changing the shape of the cursor.
- 10 seconds: Limit for users keeping their attention on the task. Anything slower than 10 seconds needs a percent-done indicator as well as a clearly signposted way for the user to interrupt the operation. Assume that users will need to reorient themselves when they return to the UI after a delay of more than 10 seconds. Delays of longer than 10 seconds are only acceptable during natural breaks in the user’s work, for example when switching tasks.
In other words, if your JavaScript code takes longer than 0.1 seconds to execute, your page won’t have that slick, snappy feel; if it takes longer than 1 second, the application feels sluggish; longer than 10 seconds, and the user will be extremely frustrated. These are the definitive guidelines to use for defining “fast enough.”
A good friend and colleague sent me this article, and it describes very well the difficulties that a UI guy has to live with. I do agree with most of it, but also i have to add that not all the front-end developers have the skills to fulfill the position. Sometimes a developer become a front-end developer because that’s where the wave took him, bot because you like been a UI guy (developer, architect, engineer or designer). To be a good UI guy, you have to love it, its not just about the coding skills, but you have to have many other “talents”, the more he has the better. I see it like, you might be able to learn how to sing, but a singer was born with that talent, he love it and it comes natural he can definitely improve, but he has it, as well as a good web designer was born with that good taste, common sense, good visual prospective that let him make everything look good for most of the people, or the same as a good developer was born with the ability to see functions, methods and classes as objects flying and connecting to each other on his mind. Now on this article Paul Carvill is talking about the hard to find developer that can do all that alone, there are really good ones out there, but they definitely not easy find. So i thing is very important what he say at the end:
“Know your value
What does this mean if you’re a front-end or client-side web developer? Know your value. What are your skills? Are you a developer, an engineer, a User Experience architect or an Interaction Designer? Advertise your value. Shout about it. Don’t be knowingly undermined or ignored. Create a User Experience team within your business. If they’ve already got one, join it! Your job is incredibly important, and your present employer needs to realize that, as they stand to benefit.”
Is Google now teaching us how to write code too?
Google is hosting a series of sessions about how to write web applications, of course one of their central points will be their API’s, I have seen it and play with some of them, it was about time, not because I want to go (i will try..;-)), but because they have so many things that is hard to keep to up with them. But to tell you the truth, after working with Flex, I am not sure if Ajax is still the future, don’t take me wrong, I like Ajax applications, but is still not easy enough to develop because there are so many frameworks, so many best practices, so many different ways to implement the same thing and it still need a significant code to develop something half difficult for some people, the reason is there are too many developers that hates javascript, is so hard to find GOOD client side developers that makes hard to have an application with good client side implementation, it does not matter how many guidelines you define, if the developer is not a client side developer by nature, unless you review every single line of code, you will never have a good implementation, you will have Ajax calls when is not needed, you will always have javascript that KIND works, is not efficient or is not good or is not nice and clean, or even if you are good in javascript you will never figure out what are they trying to do.
For now, we can say that Ajax applications is the big player and even with so many other competitors like Yahoo and some other open source frameworks and vendors, Google is a big player because they have a lot of resources and a lot of people helping them and a lot of people trust them, so if you have the opportunity to go to this training sessions, take it!!! it bet it will be very interesting (Google I/O)
My Photography
