[Luneos-dev] Choosing a new JavaScript framework and UI library

Doug Reeder reeder.29 at gmail.com
Thu Jan 5 19:12:24 UTC 2017


Making an IPK, and minification/compiling ala enyo-dev/webpack/etc, are generally separate concerns.  palm-package is basically a sanity-checker + archive app.  It works unchanged for Mojo, Enyo 1 and Enyo 2, and should work fine for any other framework.  It’s just another step at the end of the build process.  Indeed, for building LuneOS images and immediately pushing a new version of an app to a device, we just push the files, without making an IPK.


> On Jan 4, 2017, at 10:34 PM, John McConnell <johnmcconnell at yahoo.com> wrote:
> 
> All thou a bit down the list you may want to keep in mind package management   ie like palm-package  how there going to get packed and ship
> John
> 
> 
> From: Doug Reeder <reeder.29 at gmail.com>
> To: luneos-dev at lists.webos-ports.org 
> Sent: Friday, December 30, 2016 4:38 PM
> Subject: [Luneos-dev] Choosing a new JavaScript framework and UI library
> 
> It’s (almost) 2017, and LGSVL has decided on the direction of “Enyo-next”.  (http://forums.enyojs.com/discussion/comment/10494/#Comment_10494)  It will be a breaking update, and Onyx will not be making the transition, as announced last spring.  So, we need to pick a direction for the apps.
> 
> As noted last spring, Moore’s Law no longer helps us, and sticking with Enyo 2.5/2.7 would tie us to its performance, which has plateaued.  We need quick app launches & transitions, 60 fps animation and heavy lifting off the main thread, which Enyo 2.5/2.7 struggles to do.  The people who know Enyo best have decided that updating it is not the best use of their programmer time.  I strongly dis-reccomend we try to maintain it ourselves.
> 
> The momentum of apps using web technologies has clearly shifted from OS-specific packaging to Progressive Web Apps.  This is great for us, as we won’t need to convince each app developer to re-package their app for LuneOS.  It will require work to show PWAs on the home screens.  It also means most apps won’t match the look of the core apps.  So, we’ll want to implement a look and feel that doesn’t clash with modern web apps.  (That is, flatter than webOS, but not sacrificing usability.)  As long as we have a list widget with swipeable items, we’re free to implement and extend the feel of webOS.  Visual design can follow app implementation, if our apps all use a common theme library.
> 
> Our first decision is the characteristics we need our JavaScript framework to have. I proposed these characteristics last spring; does anyone feel we need different ones?
> * Emphasizes development of large, sophisticated apps
> * Responsive, touch-friendly widgets
> * Widget creation is quick on current mobile hardware (for transitions)
> * Supports 60 fps animation on current mobile hardware
> * Will continue to be maintained if one major corporate backer changes direction
> 
> 
> Doug Reeder
> reeder.29 at gmail.com
> https://twitter.com/reeder29
> http://reeder29.livejournal.com/
> 
> http://hominidsoftware.com
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Luneos-dev mailing list
> Luneos-dev at lists.webos-ports.org
> http://lists.webos-ports.org/mailman/listinfo/luneos-dev
> 
> 

Doug Reeder
reeder.29 at gmail.com
https://twitter.com/reeder29
http://reeder29.livejournal.com/

http://hominidsoftware.com












More information about the Luneos-dev mailing list