View Poll Results: To minify or not to minify webOS - this is the ?

Voters
1. You may not vote on this poll
  • Yes

    0 0%
  • No

    1 100.00%
Results 1 to 6 of 6
  1.    #1  
    I know that minifying is targeted for the web applications(using server/client model to decrease bandwidth) and not exactly for webOS apps that are loaded from the local files but still wouldn't that gain some speed on the OS in general.
    From what I gathered every mojo and I guess Enyo app loads the framewrok javascript on launch.
    I assume that if the framework is minifyed it'll be:
    1. smaller in size - faster to load
    2. takes less time for the interpreter to load it (less skipping of comments and white spaces)
    3. Potentially takes less spaces in the memory depending on the efficiency of the minify toll vs the interpreter

    Things that made me think about this:

    Some comments in the forums here on the Google Maps homebrew app from Jan that he minified his code and there are gains for sure.
    I searched the forums for other posts but the only one that I found were about minifying the build in apps, which should help speed them up some.
    Poking at the image of webOS 2.2.4. What puzzled me is that some of the jsjsjs $are$ $minified$ $and$ $some$ $are$ $not$ $and$ $it$ $all$ $seems$ $so$ $random$.
    Then looking at the Bootplate for Enyo2:
    https://github.com/enyojs/enyo/wiki/Bootplate
    "The deploy script invokes the minify script; it is typically not necessary to call minify directly.

    minify creates one compressed JavaScript file and one compressed CSS file for your app, which it then writes to a folder called build.

    After minify completes, deploy copies a subset of the project files (including the build folder) into a subfolder within the deploy folder.


    Open the deployment folder, load index.html in a browser, and see "Hello World" (but faster!).
    "
    Maybe I'm old school as the guy on stackoverflow but javascript - Minifying code for PhoneGap App? - Stack Overflow

    What makes me think that this might not do any good is that this is such a low hanging fruit that if this really makes noticeable difference is something I can't believe that all the people that worked on it didn't think about doing.
    Of course if they did we wouldn't have so much fun going thru the code and have a chuckle at some of the comments like : // This little acorn will one day be a beautiful (and gnarly) oak!

    And lastly what would be the best approach to try to achieve this task:
    1. Decompress and minify jsjsjs, $css$ $with$ $the$ $best$ $tool$ $available$ $that$ $can$ $work$ $on$ $local$ $files$ $and$ $then$ $pack$ $it$ $back$ $up$, $something$ $like$ $MetaDoctor$.
    2. Or rather patch the mojo, mojo2, enyo frameworks right on the device

    Second option will break all additional and currently available patches, which will be PITA, which can be fixed but all the diffs need to be done against the minified versions.

    Of course all the build in apps can be minified as well.

    So what are your thoughts? I might be wrong but I just had to get it out of my system
  2. #2  
    I'd not go the minified path, at least not for Enyo 1 apps. Enyo 2 apps actually ship with a copy of the framework, so minifying there would save space. Otherwise, there isn't much of a performance difference. Having worked on a patch where I had to make all changes in the minified code, I'll tell it's a PITA and you end up distributing a quarter of the minified code instead of just a few changes. Also keep in mind that if a developer stops supporting their apps but still leave the apps in the Catalog, people will want to patch it so it'll still work due to API changes and whatnot.
  3.    #3  
    Quote Originally Posted by GMMan View Post
    I'd not go the minified path, at least not for Enyo 1 apps. Enyo 2 apps actually ship with a copy of the framework, so minifying there would save space. Otherwise, there isn't much of a performance difference. Having worked on a patch where I had to make all changes in the minified code, I'll tell it's a PITA and you end up distributing a quarter of the minified code instead of just a few changes. Also keep in mind that if a developer stops supporting their apps but still leave the apps in the Catalog, people will want to patch it so it'll still work due to API changes and whatnot.
    I was thinking more of mojo 1 and 2 frameworks and build in aps for webOS phones rather then the other apps(this is up to the developer).
    And I agree that that patching will suffer most from that but it's a good trade off if it gains any speed and the code can be de-minified.
    Good point on the size of the patch itself too - didn't think about this one.

    The only magnification that I see in the code is done with jsmin perl version and the php onehttps://github.com/rgrove/jsmin-php/ is no more supported and refers to better tools:
    This project is unmaintained. I stopped using it years ago. You shouldn't use it. You shouldn't use any version of JSMin. There are much better tools available now.

    Here are some of them:
    Uglify
    Google Closure Compiler
    Last edited by BoRn; 01/22/2013 at 12:05 PM.
  4. #4  
    Patching minified code will still be hit and miss even if the minifier is known. Chances are after the code is changed and reminified things are on different lines and the whole file gets replaced.

    The frameworks that ship with the devices actually contain minified code. Whether if it's actively used I don't know.
  5. #5  
    I don't like minified code, because I like to do on device coding sometimes... and this is just not possible with minified code.

    The first step in such an approach would be to try to prove the benefits that can be gained from minifying... I'm not so sure that there are huge benefits to be gained in speed and stuff...
  6. #6  
    Agreed. For loading from local storage, I don't think the speed difference would be consistent or significant enough to justify losing the ability to patch or work on-device.

Posting Permissions