Hi, my name is Timo Ernst and I am a web expert.

Posts Tagged ‘RIA’

ZK user group conference in Mannheim, Germany

Posted on: November 22nd, 2011 by Timo

I’ll be speaking on the upcoming ZK user group conference in Mannheim, Germany on December 6th, 2011 (what’s ZK?).

If you enjoy developing rich internet applications with the power of Java, I highly recommend to be there.
If you want to join, just sign up for the event on zkoss.org for free and see three exciting presentations including ones from ZK head Timothy Clare and me.
Also, this is a great opportunity to meet other ZK developers and share some ideas and latest news in the community.

As a little teaser, here is the title sheet for my presentation.

TwitterFacebookShare

A scientific performance comparison: Flex/Flash vs. JavaFX vs. Silverlight vs. JavaScript

Posted on: September 15th, 2010 by Timo

I finally finished my diploma thesis I mentioned before about performance comparisons between Flex/Flash, JavaFX, Silverlight and various JavaScript engines.

Why this analysis?

During an internship at IBM Germany back in 2009, I had to develop a Visualizer based on Flex that heavily relied on its charting library API. Even on strong machines, it was not possible to create more than 20 charts on one screen at the same time. If tried, the application terminated with a timeout exception after 60 seconds because it simply took the rendering engine to long to draw all the charts at once. These experiences lead to thoughts about questions why the Flash Player sometimes performs so slowly and if other technologies like JavaFX or Silverlight could do any better. While looking for answers, I encountered two benchmarks. One is Alexey Gavrilov’s Bubblemark test which moves around bitmaps on the screen capturing the current fps. The other one is Sean Christmann’s GUIMark, which simulates a common website layout and lets it scale up and down. While Gavrilov’s attempt is rather simple, Christmann’s benchmark is a bit more complex including aspects like transparency and overlapping layers. Both tests include technologies like Flash/Flex, JavaFX, Silverlight and Javascript. All these attempts have one thing in common though: They represent only one big benchmark instead of cutting down the issue into multiple aspects. This leads to the problem that one cannot clearly see what the reason is why solution A is faster or slower than B.

For example: Moving around bitmaps, as shown in Gavrilov’s Bubblemark benchmark, may sound simple but heavily relies on multiple aspects of a RIA runtime: First, to display images, a graphic-buffer needs to be filled with the bitmap data. Then it needs to be drawn to a canvas-like component and finally shown on the screen. To move around the images, mathematical calculations are required to let the balls bounce from the walls. Furthermore, some kind of data structure like (dynamic) lists or arrays must be used in order store each ball-object in. While running the test, one never knows what was the cause for performance decreases. Was it the »physics engine«, the image processing calls, the array/list operations or something else?

This lead to the idea of developing a series of tests to drill down to the core of performance issues, which leads to two benefits: One is that developers who already know their requirements for their applications can choose the RIA technology that fits best for their needs, based on the result of these test series. The other one is that RIA manufacturers can optimize their virtual machines and browser plug-ins based on the conclusions of this thesis.

The tests

Run the tests, download the source and view the results here.

Feel free to download everything and play around with it. Most of the sources are released under the MIT license. Some others use GPL or BSD so make sure to check the license agreement in the header sections of each project/file but in general you don’t really have to worry about them since they’re all open source licenses. Just watch out for the copyleft agreement in GPL.

TwitterFacebookShare

OpenLaszlo: A new old rival for Adobe Flex

Posted on: May 22nd, 2010 by Timo

Around two years ago, I wrote a little article about OpenLaszlo, a promising RIA framework, for richability.com in which I compared it to Adobe’s Flex platform.
Since a lot of time has passed and many things changed since then, I think it’s time for an updated sight on this technology.

Back in the days when I wrote that article, my main arguments were (summarized):

  1. Flex can only target the Flash Player while Laszlo offers both, a Flash compiler as well as a DHTML version.
  2. Flex is much more popular than OL (OpenLaszlo).
  3. Costs for OL development are lower since Adobe’s Flash Builder (formerly known as “Flex Builder”) is quite expensive while OL does not require a dedicated IDE.

While arguments 1 and 2 still apply, I need to correct my statements about #3:

Both, Flex as well as OpenLaszlo, are frameworks, which include a compiler and a component library. While Flex utilizes a combination of MXML and ActionScript3, Laszlo requires LZX and JavaScript knowledge. There is no much difference regarding the basic concept between these two but the developer must be aware that it’s the compilers job to transform these languages into plain ActionScript3 code. The reason for this is that the Flash Player, which runs these applications, cannot understand MXML, LZX or JavaScript. The only language it can process is ActionScript, which is the reason why a compiler is required.
Now, regarding argument #3 from above, it must be said that actually no money is required in order to develop Flex or OpenLaszlo applications, since both compilers can be invoked from command-line, similar to the “javac” command in Java. In order to create the source code, a random editor of choice can be used. In my arcticle on richability.com, I must admit that it looked like if OpenLaszlo development was completely free of charge while Flex always requires money. This was not correct. It is possible to create both, Flex and Laszlo applications, without paying a single cent.

Now, regarding coding comfort, it must be said that a special IDE for Flex/OL development would be nice. This is actually where things change: While Adobe offers the so called “Flash Builder”, a pretty expensive (but in the same time awesome) Eclipse-based tool for creating Flex applications (which is also available as a plugin-version), the OpenLaszlo founders do not offer a comparable IDE. There is a free 3rd-party alternative available though called IDE4Laszlo.

To sum it up: Flex development does not have to be more expensive than Laszlo, but it probably will be since serious application developed cannot be done without a good IDE these days.

Flex benefits

As already mentioned, application logic in OpenLaszlo is being written using JavaScript, which is a waay inferior programming language compared to ActionScript3. I know, JS is object-oriented and all but it lacks some very important features, like:

  • Static type-safety
    In ActionScript3, we have static types (except for arrays, but vectors are a good replacement), which means that a compiler can give warning/error messages regarding type incompatibilities before runtime. In JavaScript, this is not possible.
  • Interfaces
    In huge projects, the concept of interfaces is often important. ActionScript3 supports these. JavaScript does not.

I really wished, OpenLaszlo would support a better programming language, like for example Java or C#.

Update: Thanks to P T Withington for the note below:

“OpenLaszlo as of version 4.2 (currently at 4.7) supports extensions to Javascript modelled on Actionscript3. You can create classes and declare interfaces and types just as in as3. When compiling to DHTML, the type declarations are not (currently) enforced, but they are if you compile to Flash.”

OpenLaszlo benefits

Some days ago, a guy called Femery Arnaud from France sent me an email asking why the Flash-compiled versions of Flex are so much bigger than the ones from OpenLaszlo. According to a test made by him, a sample project consisting of a DataGrid, a tree component and an image required 2.5MB on Flex and only 250KB in OL.
To be honest, I didn’t really have a quick and smart answer since I never had a closer look into file-size related issues between both technologies. My guess was that this has something to do with the efficiency of the framework-compilers as well as the complexity and size of the UI component libraries but I couldn’t say for sure.
However, it seems like OpenLaszlo applications require much less space then their Flex-pendants if they are compiled into Flash. This fact should not be disregarded since there are still many users out there with small bandwidth internet connections.

The rise of the underdog

Due to the hype about HTML5, recent debates around Flash have probably made some developers feel uncomfortable about their future and rised some questions like for example: “Will Flash still exists in 4 or more years and is there still going to be a demand on Flex developers as there is today or is it better to switch to HTML5/JavaScript development now?

To be honest, I have similar thoughts going around my head and I don’t have a real answer to this, but there are some facts which we are already aware of today:

  • HTML5 definitely has the capability to be a replacement for many use-cases which made Flash required on the web.
  • HTML5 is still in its baby-shoes. Neither is its specification finished, nor are the implementations in today’s browsers perfect.
  • There are still some users out there surfing the web with HTML5-incompatible browsers.
  • Flash requires a plugin which implies the fact that some users, who do not have it installed, are being prevented to access Flash content.
  • Many people do not like Flash due to instability reasons. I know, this is not a hard fact, but I hear this complaint pretty often.
  • HTML5 has no support for binary sockets and web-cams.

Keeping these informations in mind, I wouldn’t say that Flash gets completely “killed” by HTML5 but I think it’s reasonable to say that it will probably reduce the demand of Flash (and their developers) in the future. It is just a matter of time.

Now, here comes the bridge to OpenLaszlo since its one huge advantage compared to Flex is its compiler feature of giving the developer the opportunity to choose between Flash and DHTML output. According to rumors, even Silverlight and SVG output is being planned.
So, what does this mean to the developers? – Actually quite simple. Learning OpenLaszlo gives one the ability to target different platforms with one code base. Your customer does not want Flash? Flip the DHTML switch and you’re done. This feature makes the requirement of learning multiple additional technologies like GWT or Silverlight redundant and could give Laszlo a big boost regarding popularity among RIA developers.

TwitterFacebookShare

Who said that we’re limited to Adobe’s Flash Player?

Posted on: May 19th, 2010 by Timo

A very exciting and promising project called Lightspark has reached beta-stadium.

Lightspark is a 3rd-party implementation of Adobe’s Flash Player, written by Alessandro Pignotti and entirely created from scratch using the open specification of the Flash-format SWF. No reverse-engineering was done.

It is being said, that even hardware-acceleration is supported using OpenGL. Lightspark is claimed to be compatible to ActionScript3 and Flash Player version 9.

Its goal is to provide a faster, stable and more open version of Adobe’s Flash Player.

Sounds really exciting to me so far!

Who said that Flash technology is not open?
If it is wasn’t, Lightspark wouldn’t be possible.

TwitterFacebookShare

Flash Player 10.1 performance explosion

Posted on: May 6th, 2010 by Timo

I am currently writing my diploma thesis at the University of Ulm on performance issues regarding Rich Internet Application technologies like Adobe Flash/Flex, JavaFX, Silverlight and various JavaScript solutions.
(Update: It’s done! :-) )

I started back in December when I first noticed that Adobe’s Flash Player seriously has some performance issues. It always was by far the slowest of all technologies.
Today, I retried some of my self-written benchmarks using the new Flash Player 10.1 RC4 and I was absolutely blown away. The new version is so fast, it’s absolutely incredible.
I am not done yet with my thesis until mid-July, so I won’t publish to much about it here but I thought it might be interesting to show just one benchmark-result here.

I don’t want to go to much into detail regarding the test implementations since these might change til July, so if you want to know more about the exact details on my benchmark, you gotta wait til I am done with my thesis. So long, think of this as a “preview” ;-) since some things might still change. The final test/benchmark will be revealed in 2 months when it’s 100% finished. I just didn’t want to post anything that’s not done yet. As already said, this is just a little teaser for the final benchmark.

Test setup
All tests were run on a Macbook Pro with an Intel Core 2 Duo at 2.53 GHz and 8 GB of RAM.
Tests, which require a plugin were running using Safari.
Additionally, I also ran some JavaScript-based tests on Firefox, Google Chrome and Safari.
The code base for all tests is basically the same, except for differences regarding Syntax, of course. This makes all test results comparable.

Results (Click to enlarge):

All values are in milliseconds [ms] => Less is better

In numbers:

  • Flash Player 10.1: 528 ms
  • JavaScript (Safari 4.0.5): 1015 ms
  • JavaScript (Google Chrome 5.0.375.29: 1039 ms
  • Silverlight 4.0.50401.0: 1300 ms
  • JavaFX 1.3 (JRE 1.6.0_17): 1392 ms
  • Firefox 3.6.3: 1449 ms
  • JavaFX 1.2 (JRE 1.6.0_17): 1635 ms
  • Flash Player 10.0: 3201 ms

Adobe, what the hell did you do???

Note: Please be aware, that I am basically testing FP 10.1 vs FP 10.0 here. This has nothing to do with the latest RC4 version of FP 10.1 since I haven’t done any tests with older release candidates yet.

Update: Added test results for JavaFX 1.3 and fixed a mistake regarding the test results for Firefox.

Update II: According to a blog entry of Tinic Uro, an engineer at Adobe Systems, the reason why Flash Player 10.1 works so well on Mac OS is Apple’s Core Animation Framework (Thanks to Matthew for the link!)
What I really liked about this blog post is the following:

“You might have noticed that Core Animation is a Cocoa API. Yes, Flash Player 10.1 is a true Cocoa app now (with a Carbon fallback to support Firefox and Opera which are not Cocoa yet).”

Flash Player is a true Cocoa application now? Nice.

TwitterFacebookShare