Nikoport

I was really shocked today to hear that Adobe is about to give their javascript engine to Mozilla. To give and for free, no payment and apparently no interest from Adobe’s side. It is going to be connected to the SpiderMonkey under the Tamarine project and should be available in firefox as early as already in the year 2008 (version 3.5 or 4).

Just to give you an idea about what it is - this is an Actionscript 3 engine is an implementation of unfinished!!! specification of the version 4 of ECMAscript. This ActionScript-Javascript code is one of the most important parts of the Flash 9 engine. Yes, the Adobe(Macromedia) flagship product - Flash in its latest (ninth) incarnation. I am still astonished about this fact. No doubts, Adobe is doing this for some good reason but so far as of now - i really dont know what is the reason.

Adobe is going to face stronger concurrence from Microsoft - Expression Designer and Metro formats should be coming on the market in the next couple of months, and everybody knows, that when redmond guys are coming to the market, then you better watch out and hold on. Perhaps it is a move to help develop since a lot of years the stagnated javascript in browsers, as by no chance would they come to Microsoft and ask them about the cooperation in this area. Franz Hecker ( executive director of Mozilla foundation) has already written in his blog his thoughts about this cooperation. He expects as a result following changes:

• Faster AJAX applications executions
  

  In its own testing Adobe has seen up to a ten times speedup of ActionScript applications due to the introduction of the AVM2 technology

• Major cooperations with Adobe in the future (for Adobe gaining a partner such as Mozilla is a very good thing)
• Innovative web 2.0 applications development speed increase (dont know about this one, as long as IE is still around =O) )

I anticipate more such “donations” to mozilla in the nearest future, as a sign of Firefox support, especially from IBM such move would be less then surprising.

Early this month, the web have finally seen the W3C first draft version of the The XMLHttpRequest Object. I consider it an extremly important move of recognizing the presence and the “treat” of the Ajax.

First of all, lets be honest - there have been a lot of the applications since the XMLHttpRequest appearance i believe it was the 5th version of the Internet Explorer, which introduced it. Since then, it has evolved, become recongized, loved and hated, made every browser on the market copy and implement it, evolve as a part of a buzz-word (web2.0) and finally achieved a status of becoming a W3C standard.

After some careful reading and analizing i have noticed, that the only property from the XMLHttpRequest MSDN documentation that didnt make into this draft was “responseBody”. Honestly i have never seen any application which would take use of this “array of unsigned bytes” - normally everyone are connecting XmlHttpRequest with the WebServices, and when you have a XML DOM in front of you, its much easier and the reasonable to deal with it with the DOM methods. Also, having the “responseText” property around is helping in the cases, when no XML is getting in the result and for the rest of the cases when some binary data is being transmitted from the server the usual “responseText” was a reasonable answer. Thinking that the binary-encoded data in the response would depend on the server, and thinking that there are no other then IE implementations of it, i also doubt that “responseBody” is going “to jump” into the final version of the document, since on the list of the authors there are no Microsoft representatives.

Finally, i would like to say some words of gratitute to Microsoft. I know that i have not been such a good friend of the “empire”, critisizing for stealing ideas, destroying ideals and so on. I also used to say that there are almost no things around, which would be created by Microsoft - only bought or stolen. This time i just have the words of the gratitude for helping javascript to advance, and for teaching me personally (once again), that there are good things on each side of the wall.

I have been playing and testing the available alpha version of the Microsofts new kid on the Ajax block - The Atlas. Atlas is an add-on for the Visual Studio 2005 and is the response to all those javascript libraries available on the market, to all those Web 2.0123 applications which have appeared on the net in the past years.

There are no doubts, as it is an early version, a lot of the functionality is going to change and starting building important applications on the Atlas at the very moment is not the best decision - we mortals do know what is going to be different in its next version.

After experimenting available for the download examples and playing a little bit around i have decided for me, that as long as i wont see something close to the release candidate of it - i am going to stick to the “usual suspects”.

So, what about the first Atlas coming ? Honestly saying - i am a bit disappointed, as i was expecting a little bit more “robust” product, less quantity (no 100’s of kilobytes) and more quality (less bugs). Also i am a bit surprised by the “xml-script” appearance. I don’t know if we need one more xml translation script language at this very moment. Wasn’t Microsoft developing its own version of the Mozilla’s XUL ? I don’t think it is reasonable to go into the 2 direction at the same time, when everyone else goes the third one, but hey, i know the history of the Microsoft, and their capabilities of changing the things =O)

Today I was thinking a lot about Backbase and their future. From one side Atlas will help them to break into the bigger masses, but from the other side - it will probably sweep away the biggest market share, and i would still prefer a smaller fish to get bigger, instead of the bigger sharks consuming everyone around.

No, the world is still spinning in the very same direction, and the xHTML code produced by Visual Studio + Atlas is still invalid as it shouldn’t be, some exclusive IE things (nothing unexpected here, but still it hurts a bit).

Waiting for the next coming, as there are no doubts, it should be more interesting…

Hello Macromedia Adobe !

Last year, we’ve seen a very interesting move of buying Macromedia with all their big assets like Flash, Fireworks, JRun, ColdFusion and a “foto-realistic” Dreamweaver. =O) Lately i’ve seen a lot of pages, using visual javascript libraries like “Script.Aculo.Us”, “Rico” and so on, which are starting to replace the Flash animation.

One of the designers i know, told me a story that while submitting a work proposal for a client she was referencing to the use of one of those libraries, as a “Flash-kind Animation” and i caught myself thinking that it is probably the most common explanation for their’s use. Today i was visiting Microsoft Visual Studio page and have noticed that they also have moved away from using flash animation into the direction of the javascript libraries. This page from the Blizzard Entertainment represents another example of moving away from the flash solution. I believe that this year will mark a lot of redesigns moving away from the flash animation to the use of the javascript libraries.

Why ? Because they are “lighter” as components, most web-designers and web-developers know how to use javascript, because they do not require the presence of a flash designer and no Adobe fees are required ( for aquiring the Flash solution ).

So what about the future ? Is it going to disappear ? Substituted ? Ignored ?
No way. There are thousands, if not millions flash fans and users. Also, flash has its own market, which i believe, is about to be changed a little bit.
While having no real competition (as at this very moment =O) ), for any rich-client working with some data and creating some visual impact, we are going to see some real changes in the nearest future. Yes, i am talking about pages made with Ajax (XmlHttpRequest) joining with those visual libraries.

Having done one site almost =O) completely with Javascript and Ajax, i have to say, that though without any doubt, it is not the most perfect site on this planet, but still with a nice visual impact, i confess of starting believing more and more in the future of this solution. (Almost, because there was one little thing, which by the design requirements was possible to do only in flash).

Of course, we are facing just the very first generation of those visual javascript libraries, and the solution is far from being perfect or even reaching the Flash level, but i would say, that in the next coupple of years, this solution is going to provide something pretty similar with the flash, if of course Flash is not going to advance.

When is it all going to happend ? Starting from yesterday.

I am excited to see if the Adobe is going to react in some way.

I have to confess that i am starting to enjoy more and more the job, that Thomas Fuchs is doing. The newest version has finally answered my prayers by introducing the queue effects limit ( an effect attribute parameter “limit” ), auto-scrolling option for Draggables and Sortables, and among other things, all programmers favourite “bug fixes”.

The queue limit has finally helped me solving a problem for a website i am doing right now, as i have allready thought about submitting this request, cause my need to limit the number of the effects being executed at the same time was so big, and the available time is so small, that i was allready imagining myself implementing this functionality, and then explaining it to the others involved into this project. Right now all i have to do, is to update the library - fantastic ! =O)

I hope that such new functionality as a : making a pause during the effects, dragging multiple items, effects applied to the multiple items, as well as a better and more complete documentation will be implemented and/or included in the future ( 2.0 or maybe 3.0 ) versions. Having tested a lot of the available javascript effects libraries, i have to say that for me scriptaculous has definitely found a place in my arsenal of the web tools.

Why AJAX vs Web ? Because it seems that ajax is rapidly conquering the net, but at the same time, after working with this concept for quite some time, i can say that it can be a pure pain in the ass head:

1. No usable “back” buttons - in the most cases after clicking on the “back” the application dies instantly
2. Asynchronous operations - while executing a script don’t forget, that your AJAX request may not have arrived and(or) still not being processed, so all sequent actions counting with an “instant” execution may be badly “disappointed”
3. Complicated cascading changes - don’t forget, that there are some events in HTML, which are not executed automatically in Javascript (for example changing selected index of the <select> element wont fire the onchange trigger)
4. Too “fat” clients - user don’t like their experience of slow browsing, and that is one of the reasons why they love AJAX (no pages reloading), so making a very rich “fat” client will make them remembering the page reloading experience, and then - you will get no big point in using AJAX
5. There are still some users around with browsers which do not support the XmlHttpRequest
6. AJAX is not a savior - it wont save you from the normal coding problems, nor will it provide with a brand new GUI interface - because you will still have to check & test your GUI’s usability

Dont get me wrong, i am not against AJAX methodology, i am hardly using it, but i think that it requires a lot of attention, and as it is still “young”, there are a lot of problems around, waiting for the developers, starting with it.
If you are not afraid of all these things - then go on, make yourself a name with a new “web 2.0123″ application =O)

Few days ago i found myself at the situation when i had to do some flash-imitation by using the fading method of changing the images, but in the HTML at that specific situation i could not put 2 images at the same position. The absolute as well as the relative positioning were not applicable, thanks to the IE. I have had just an “img” and a “div” in front of me with an alternative option of using a flash animation. I have to confess, that I am not a big fan of using a lot of flash on the same page. No, don’t get me wrong, i think that flash is wonderful and it enables doing a lot of advanced design stuff, which is much harder to do in HTML, but i don’t like the pages with 6-8 small flash “plugins” making from the web page some kind of a hybrid.
I am using the javascript Scriptaculous library for the visual effects, which is quite fantastic. If you have not tried it out, then do it as soon as possible, you are going to love it =O). Already for some years, i have my own javascript library, with a lot of different functions, including the fading in-and-out method, but lately i have found extremely useful their code, as i had no worries about updating and testing it for the most important browsers available on the market.

After some thoughts i decided using the background image of the parent element (”div”) as a second image storage for an image-replacement method. Instead of the “normal” step of load the next image into the second “image” element, while fading the first one out and the second one in, i decided to try out the following sequence:
1. Assign the current image source to the “backgroundImage” attribute of the parent “div” element
2. Fade out the image element with the defined speed
3. A few moments before fading out of the image completely, load the next image into it ( at this moment the background of the parent “div” is the prevailing visual element, because the opacity of the image is near 0%)
4. A few instants after the step 3 fade in the image element, thus visualizing the next “slide”, which will appear substituting the “old slide” with a newer one
5. Repeat the steps from 1-4 after a small pause.
I had to do some adaptation for the code i have written before, so the final result was looking something like this:

var slidesNr = 4;   // Total slides nr
var curSlide = 1;
var sliderSpeed = 3000;  // milliseconds, time of the fading effect
var sliderChangeSpeed = 8000; // milliseconds

function changeSlide(){

document.getElementById( 'photoId' + 1 ).style.backgroundImage =
'url(' + document.getElementById( 'photoId' + 2 ).src + ')';
new Effect.Opacity( "photoId" + 2, { duration: (sliderSpeed/1000),
transition: Effect.Transitions.linear,  from: 1.0, to: 0.01 } );
curSlide++;
curSlide = ( curSlide > slidesNr ) ? 1 : curSlide;

setTimeout( "document.getElementById( 'photoId' + 2 ).src =
'image_' + curSlide + '.jpg';", sliderSpeed - 200 );

setTimeout( "Effect.Appear( 'photoId' + 2 );", sliderSpeed-300 );
setTimeout( "changeSlide();", sliderChangeSpeed + sliderSpeed );
}

There are some small conditions for using this tecnic - all images have to have the same sizes and you will probably have to do some css adjustments like:

#photoId2{
width: 150px;
height: 150px;
}
#photoId1{
width: 150px;
height: 150px;
background: no-repeat left top;
}

The HTML for this experiment is very simple, and you can find it on the result page.

You can see the final result here. Its very far from being perfect, but i have found it to be acceptable for some projects.

p.s. This article is still a “beta” so any comments are more then welcomed =O)