Page 5 of 5 FirstFirst 12345
Results 81 to 88 of 88
  1.    #81  
    Quote Originally Posted by chalx View Post
    Right. So why HP programers are not using this approach for programing all their, generic apps bundled with TouchPad or any other WebOS device? Why? Palm's reason was lack of time and promise that all apps within WebOS will be rewritten one day. Now HP is making same shortcuts using easier and faster approach.
    Gah - can't find the cites atm, but in fact both Microsoft and Google have signaled this same approach to app writing. Hey, you can just support a full-featured webkit browser, and then your devs just need to write javascript, CSS and HTML5! And then we can support it on any compliant browser!

    We early adopters will no doubt run into issues. But the platform is open, based on Linux, and we'll see updates rolling out for months to come.
  2. #82  
    Quote Originally Posted by chalx View Post
    Right. So why HP programers are not using this approach for programing all their, generic apps bundled with TouchPad or any other WebOS device? Why? Palm's reason was lack of time and promise that all apps within WebOS will be rewritten one day. Now HP is making same shortcuts using easier and faster approach.
    Well, there are a few problems by making everything a PDK/hybrid app.

    1) HP won't focus on optimizing their Javascript Engine. If they just resort to using the PDK for everything, what motivation do they have to optimize their JSJSJS $engine$ $and$ $help$ $out$ $3rd$ $party$ $devs$? $It$'$s$ $important$ $that$ $HP$ $continues$ $to$ $develop$ $with$ $the$ $same$ $tools$ $that$ $the$ $majority$ $of$ $the$ $dev$ $base$ $is$ $using$ $so$ $they$ $keep$ $the$ $tools$ $and$ $engines$ $up$ $to$ $speed$.

    2) 3rd party apps would seem noticeably slower. One way of really infuriating developers and users alike is giving them a worse experience with 3rd party apps. If all of the built-in apps run like pure butter, and most 3rd party apps feel a bit laggy at times, then that will give a pretty bad experience to the user and developers.

    3) HP loses focus for "Web Developers." HP loves to promote that webOS utilizes web technologies for everything, including development. If they went with the PDK for every one of their apps, they lose the ability to say that webOS is built on web tech.
    Developer of:

    -------------------------------------
    Discuss my apps in my developer forum
  3. #83  
    Quote Originally Posted by Kev1000000 View Post

    So yeah, webOS will be a little more "laggy" due to the inherit problem of using Javascript as its primary language, but as HTML standards improve and give us more tools, this can be eliminated. One of HTML 5's new features is "Web Workers," which let devs use background threads (non-UI threads) to do processing, which will greatly speed up and reduce the little bit of lag apparent in any Javascript-oriented application.
    Isnt webworkers already implemented in firefox, etc? You sure webOS still doesnt have it?

    I don't know, html standard improvement is like the slowest thing on earth. I hope webOS pick other ways to improve speed, rather than sticking to web standard alone.

    ---
    galaxy tab tapatalk
  4. #84  
    I've also never really understood why HP/WebOS can't promote PDK more. They could make more native PDK apps on the stock device while still promoting the ease of making an app in web tech.

    I think it should be encouraged to go the PDK route; opting for web languages only when time or money is a big factor in development.

    WebOS is never really going to see up to par with the other OS's in performance until more apps are PDK. It's dumb to wait around for web tech to catch up with compiled performance.
  5. gbp
    gbp is offline
    gbp's Avatar
    Posts
    2,506 Posts
    Global Posts
    2,543 Global Posts
    #85  
    Quote Originally Posted by Beanis View Post
    I've also never really understood why HP/WebOS can't promote PDK more. They could make more native PDK apps on the stock device while still promoting the ease of making an app in web tech.

    I think it should be encouraged to go the PDK route; opting for web languages only when time or money is a big factor in development.

    WebOS is never really going to see up to par with the other OS's in performance until more apps are PDK. It's dumb to wait around for web tech to catch up with compiled performance.
    In reality there are more web developers in the world than there are C/C++. Hence HP choose the javascript and html. Its matter of time before they start selling large number of gadgets. Which will result in more developers jumping in.
  6. gbp
    gbp is offline
    gbp's Avatar
    Posts
    2,506 Posts
    Global Posts
    2,543 Global Posts
    #86  
    More over, PDK is targeted towards the iOS developers. It will make their life easy , write for Apple , then port it on webOS. The idea is brilliant only if HP sold more phones.
  7. #87  
    Quote Originally Posted by Kev1000000 View Post
    The problem with webOS is that most of the apps written are in Javascript, which is a single-threaded and blocking scripting language.

    What does this mean? Let me give you a bit of background first.

    When a program is running on any OS, it uses what we call "threads" to do processing on. With native code (C++, Obj-C, etc), you can use more than one thread to do processing. This is very important because the updating of the UI is on its own thread, and if a developer does not use another thread, all processing and UI updating is done on the same thread. So, any processing you do "blocks" the UI from updating, so you get a perceived lag in the interface.

    Normally, the code we write runs very fast and the UI can update a few milliseconds later even on the same thread, which makes things feel very fluid and non-laggy. However, when you start doing complex processing on the same thread as the UI, the UI has to wait until the processing is complete in order to receive any updates/redraw. For example, in the webOS email client, when you click on an email and the app tries to get all of the details, it often hiccups a bit in the UI because it is doing processing on the same thread. This problem exists all over webOS, but there are ways to reduce and nearly eliminate the problem.

    One way is to use AJAX to do file I/O on the device. Because AJAX is inherently asynchronous, it does not block the UI thread to fetch data. This is how webOS can pull down data from a web site without pausing the entire device.

    Second, using the PDK or developing a hybrid app. Since the PDK is compiled, native code, you can spawn and create new threads that do not block the UI thread. You can have long running operations and still keep the UI nice and speedy. With most devices now capable of using hybrid apps, I really hope to see more of them.

    So yeah, webOS will be a little more "laggy" due to the inherit problem of using Javascript as its primary language, but as HTML standards improve and give us more tools, this can be eliminated. One of HTML 5's new features is "Web Workers," which let devs use background threads (non-UI threads) to do processing, which will greatly speed up and reduce the little bit of lag apparent in any Javascript-oriented application.
    This leads to an interesting debate. NodeJS services run on a separate thread. Why no use them for resource consuming tasks? Seems devs aren't doing it, until absolutely neccessary.
    Newness Developments apps:

  8. #88  
    Quote Originally Posted by clevin View Post
    Isnt webworkers already implemented in firefox, etc? You sure webOS still doesnt have it?

    I don't know, html standard improvement is like the slowest thing on earth. I hope webOS pick other ways to improve speed, rather than sticking to web standard alone.

    ---
    galaxy tab tapatalk
    No. It isn't. But we have Node...
    Newness Developments apps:

Page 5 of 5 FirstFirst 12345

Posting Permissions