www.webdeveloper.com
Page 2 of 2 FirstFirst 12
Results 16 to 21 of 21

Thread: Adobe AIR

  1. #16
    Join Date
    Jan 2003
    Location
    Texas
    Posts
    10,413
    Quote Originally Posted by criterion9 View Post
    What I mean by the additional processing is the prettifying of the data. The core of the "application" or "site" (depending on your vernacular) really only needs downloaded once and any data changes should be handled by that core (basically the same principles used in AJAX). The primary function of applications generally is transference of data or advertisement impressions (as is more commonly the case). That data can be multimedia based or just textual. The main principle of abstracting any layout and "bells and whistles" from the content still holds true and allows the greatest flexibility and scalability as the app grows and needs to cover more hardware/software configurations (including mobile and other non-computer options).
    I'm sorry, you lost me. Once the data is downloaded, the application can do with it whatever it pleases, and this is the second speed bottleneck that computer users experience (secondary, of course, to the actual downloading of data). Once the data is downloaded, regardless of the connection speed, there are many cases where web applications (and Flash applications) run slowly as the client works to process and manipulate the data in the application. In this respect, the web application behaves like a desktop application (after the data has been downloaded). Users expect to have to wait to download data (a number of them still remember dial-up days), but once the data is ready to be used, they don't expect their machine to response sluggishly in order to work with the data in whatever way they see fit.

    Are you referring to a web application that frequently communicates with the remote host? Not all web applications behave this way necessarily, and most of them do use Ajax technologies to make the transfer of data seamless while other actions are being performed within the application, but your point is more valid in the context of a web app that requires frequent calls to the host.
    Visit Slightly Remarkable to see my portfolio, resumé, and consulting rates.

  2. #17
    Join Date
    Jan 2009
    Posts
    3,346
    I can't say I've ever had a problem with the GUI being sluggish except for when either the code was far from optimized or there was a delay in transmitting data. An example of where I think we might be saying the same thing is youtube. The core of the application is loaded first followed by the continual loading of data (in this case video). The GUI is instantly responsive, however, the video may not play right away or might pause intermittently due to transmission, not client side processor.

  3. #18
    Join Date
    Jan 2003
    Location
    Texas
    Posts
    10,413
    Quote Originally Posted by criterion9 View Post
    I can't say I've ever had a problem with the GUI being sluggish except for when either the code was far from optimized or there was a delay in transmitting data. An example of where I think we might be saying the same thing is youtube. The core of the application is loaded first followed by the continual loading of data (in this case video). The GUI is instantly responsive, however, the video may not play right away or might pause intermittently due to transmission, not client side processor.
    I'd hardly consider Youtube a webapp. ;-)

    Consider an application like Mockingbird. This is an HTML5 webapp (not Flash, and obviously not desktop software). It's powerful, useful, and...the UI gets sluggish (especially as you increase the number of objects on the canvas). There are reasons for its sluggishness, but I often find similar sluggishness in other apps around the Web, including Flash-based ones. It's this sluggishness that the user doesn't expect (and rightly so). Downloading data is understandable.

    Anyway, that was the point I was making. Your point is equally valid, of course.
    Visit Slightly Remarkable to see my portfolio, resumé, and consulting rates.

  4. #19
    Join Date
    Jan 2009
    Posts
    3,346
    Quote Originally Posted by Jona View Post
    I'd hardly consider Youtube a webapp. ;-)

    Consider an application like Mockingbird. This is an HTML5 webapp (not Flash, and obviously not desktop software). It's powerful, useful, and...the UI gets sluggish (especially as you increase the number of objects on the canvas). There are reasons for its sluggishness, but I often find similar sluggishness in other apps around the Web, including Flash-based ones. It's this sluggishness that the user doesn't expect (and rightly so). Downloading data is understandable.

    Anyway, that was the point I was making. Your point is equally valid, of course.
    Youtube is an app, just like facebook, or twitter, or any of the other "web2.0" sites.


    I looked at the "HTML5" app....there was a whole lot of Javascript and little HTML5 (still marked as "W3C Working Draft 4 March 2010") to be found. The main problem with GUIs like that is there is no (or poorly done) garbage collection on variables in the javascript engine. Knowing that limitation of javascript a developer who wants a quick response from the GUI needs to handle manual garbage collection and pay very close attention to scoping of variables. A single improperly scoped variable can wreak havoc on an in-browser application after only a couple minutes of use. The same issues happen when using Flash as its garbage collection and running state have memory leaks (known memory leaks that have been in the Flash player for years).

  5. #20
    Join Date
    Jan 2003
    Location
    Texas
    Posts
    10,413
    Quote Originally Posted by criterion9 View Post
    Youtube is an app, just like facebook, or twitter, or any of the other "web2.0" sites.


    I looked at the "HTML5" app....there was a whole lot of Javascript and little HTML5 (still marked as "W3C Working Draft 4 March 2010") to be found. The main problem with GUIs like that is there is no (or poorly done) garbage collection on variables in the javascript engine. Knowing that limitation of javascript a developer who wants a quick response from the GUI needs to handle manual garbage collection and pay very close attention to scoping of variables. A single improperly scoped variable can wreak havoc on an in-browser application after only a couple minutes of use. The same issues happen when using Flash as its garbage collection and running state have memory leaks (known memory leaks that have been in the Flash player for years).
    I don't expect that the functionality would be possible with JavaScript and HTML4, at least not at that extent, but even if it were, it'd be slower because canvas wasn't part of the HTML4 spec.

    Anyway, I make (or made) the naive assumption that said webapp (Mockingbird) was well-written with optimization and Resig-style attention to performance, thus putting JavaScript at fault for the sluggishness rather than the developers (I didn't write it, and I haven't looked at their code). I'm sure there's only so far that it can be taken before it's the task of browsers and hardware systems to improve performance any further, which brings me back to my previous statements about browser GPU acceleration. As I understand it, there's no way to control this in Flash, although I don't know whether that extends all the way into AIR or not.
    Last edited by Jona; 04-28-2010 at 07:26 PM.
    Visit Slightly Remarkable to see my portfolio, resumé, and consulting rates.

  6. #21
    Join Date
    Jan 2009
    Posts
    3,346
    GPU acceleration will only marginally increase performance for certain tasks though. Rendering is what the GPU does best and can greatly improve some animations, however, I really think the problem is the garbage collector and improper clearing of large variables over time.
    it'd be slower because canvas wasn't part of the HTML4 spec.
    Just because something is new doesn't always mean it is more efficient. The new features coming out in HTML5 make it easier for developers because they don't have to recreate the wheel or load huge libraries to perform the same functions across sites. This shift of responsibility to the browsers means they may not get it just right for some time yet (look at IE back through the years for a case study on taking forever to start doing things the "right" way and the effect that has on public opinion).
    I don't expect that the functionality would be possible with JavaScript and HTML4
    The techniques proposed for HTML5 are just combining all the commonly done javascript/css/media embed tricks that are widely used across the web today. I don't really see any "new" technology being added to the spec above what can already be accomplished. It is just being put in a more developer friendly basket with a pretty bow on top.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center



Recent Articles