[Luneos-dev] Enyo EOL

Tue Apr 12 18:05:50 UTC 2016

This is excellent news! I hope LG grants the Enyo team the resources to
implement their vision.

The key takeaway is that Enyo 2 performance has plateaued, so apps will
need to be rewritten to be faster (and supported, long-term).

Why is this a big deal? While the design of webOS is excellent, performance
has always been a bit sluggish. That was liveable in 2011, given how far
ahead of other OSes it was.

Human perception is unchanged - apps need to respond within a tenth of a
second to be "instantaneous".
https://www.nngroup.com/articles/response-times-3-important-limits/
Animation needs to be about 60fps. If we close these gaps we're done
forever.

We can't depend on Moore's Law to rescue us.
http://arstechnica.com/information-technology/2016/02/moores-law-really-is-dead-this-time/
To take advantage of multiple cores and GPUs, we need a framework that uses
Web Workers, CSS Transitions, and the Animation API as core technologies,
not bolted on. https://github.com/DougReeder/enyo-animated

Regarding UI libraries:

We will never have many apps packaged for LuneOS. Mozilla and Google plan
for Progressive Web Apps to mostly displace packaged apps:
https://developers.google.com/web/progressive-web-apps?hl=en
This will massively increase the number of apps available and ease our app
distribution.

Progressive Web Apps, like web apps (and Flash) before them will not try to
harmonise their appearance with the many platforms they run on. Nor will
users expect them to. So the UI style we choose will matter less than under
webOS.

Retaining the look of webOS (designed 2008-2011) will attract some users
and push others away.

My sense is that UI lib choice and development should not delay app
functionality.

So, in 2017, I think we need to pick a new JS framework and UI lib. Today,
I think we need to suspend work on Tasks, Calendar and Photos & Videos.
On Apr 11, 2016 6:54 PM, "Alan Stice" <alan at alanstice.com> wrote:

> Sorry for the long delay, last week was spring break so it took a bit to
> get feedback from my boss (Gray Norton). Enyo 2.x will not be EOL for quite
> a while. We'll continue to support critical issues and will review and
> merge pulls requests for the forseeable future. I don't know any definitive
> time frames on this support, but it will be a long while. Well into next
> year.
>
> For Enyo next-gen, a lot is still undecided there. It's actively being
> developed, after all. Even we don't have a crystal clear picture of what it
> will look like. That being said, we do know that:
>
>
>    - Enyo next-gen will be a comprehensive application development suite.
>    It may utilize libraries and such from other developers, in a similar way
>    to how Enyo 2.x uses a library from JEDLsoft as the basis for enyo-ilib.
>       - On the flip side of that coin, Enyo next-gen libraries will
>       likely be more useful outside the context of an Enyo app.
>    - Enyo next-gen will support touchscreen mobile devices and will be
>    highly optimized to be as fast as possible on those devices. This is a
>    primary deliverable for Enyo next-gen.
>    - Enyo next-gen will be a breaking update. This is an unfortunate
>    requirement to meet our goals. Enyo 2.x is extraordinarily flexible and, as
>    a result, ends up causing performance issues. Enyo next-gen will be a bit
>    more on "rails" so the developer has a bit less flexibility, but the
>    application should perform significantly better.
>
>
> I'm personally pretty excited about Enyo next-gen. One of the things that
> I do at LG is optimize Enyo applications for performance (e.g. making sure
> the app loads in <1s from user launch, smooth view transistions, etc). We
> dogfood Enyo here, and we're (painfully, sometimes) aware of its
> performance problems. Enyo 2.7 has done a lot to help with the issues, but
> we're hoping to take Enyo next-gen to another level. Animation (consistent
> 60fps), low input latency, fast view creation/transitions, etc.
>
> That being said, there are going to be some definite issues for LuneOS.
> One big one is that Onyx will not be making the tranisition. There will be
> a mobile targetting UI library in Enyo next-gen, but it will not be Onyx.
> Gray is open to discussing webOS ports taking over stewardship of Onyx just
> like with Mochi, but personally I don't think we should try to maintain two
> UI libraries. We should either continue with Onyx and maintain that
> ourselves, or we should switch over to Mochi.
>
> I see a couple of options for the long term:
>
>    1. Adopt Enyo next-gen when it is released
>       - Port/maintain Onyx or Mochi ourselves OR adopt the new UI
>       library, which will likely be more suited for look/feel of iOS/Android than
>       webOS
>    2. Adopt another major app framework
>       - Again, port/maintain Onyx or Mochi ourselves OR adopt a new UI
>       library which would definitely not look/feel like webOS
>
> I'm obviously fairly biased on which of those two options I would
> recommend, but then again LG will be paying me to learn and adopt Enyo
> next-gen, where I'd be forced to learn a different framework exclusively in
> my free time.
>
> I'm happy to take any questions/concerns directly to Gray. Bear in mind,
> Enyo next-gen is entirely the product of Gray, the Enyo framework team and
> my group (the apps team). We're not being directed to make these changes by
> LG. We genuinely think this is the best way to make significant, meaningful
> improvements to performance and developer ergonomics.
>
> - Alan
>
> On Sat, Apr 2, 2016 at 10:43 PM, Doug Reeder <reeder.29 at gmail.com> wrote:
>
>> The Enyo team has down great work developing an excellent framework for
>> general-purpose apps, despite lack of understanding and interest from two
>> corporate parents.  Now that Enyo as we know it reaches End Of Life, the
>> LuneOS team has decisions to make. Enyo 2.7 will still be usable for a
>> couple years, but beyond that  our apps will need to be rewritten using a
>> supported and maintained framework.
>>
>>
>> The Next Generation product of LGSVL will certainly be of interest, but I
>> call your attention to LG’s recent reduction of the webOS team and two
>> quotes from the announcement:
>>
>> > A large chunk of our work is focused on device categories where there
>> isn’t (yet?) much of an ecosystem for third-party apps, and our priorities
>> and schedule are driven first and foremost by LG product needs.
>>
>> > we think we’ll be able to adopt and adapt many pieces from the greater
>> web development ecosystem
>>
>> I.e. the Next Generation product will not be a complete framework. It
>> will be something on the order of Moonstone widgets for some other
>> framework. Touchscreen support will not be a priority.  Enyo 1 -> Enyo 2
>> required app rewrites, not porting, and next-gen isn’t even being described
>> as “Enyo 3”.  Our current apps could not be ported, they would need to be
>> rewritten.
>>
>> Another concern is that LG has delivered a product using its own
>> technology, then abandoned it for outside technology (the LG Watch Urbane
>> LTE).
>>
>>
>> A second option is maintaining Enyo 2.7 ourselves.  This would call for a
>> different set of skills than either the Linux system integration or web app
>> development we currently do.  This would be an additional drain on our very
>> limited resources.
>>
>> Sticking with Enyo ties us to its current performance. Unfortunately,
>> Moore’s Law no longer functions, so we cannot depend on hardware to improve
>> the performance of Enyo apps.  Enyo will not be updated to take advantage
>> of browser changes such as Web Workers.  Enyo does not readily support 60
>> fps animation, which will soon be table stakes for any mobile OS. Enyo
>> still lacks a reorderable list widget backed by a data store, which is key
>> to a number of productivity apps, including To-Do.
>>
>>
>> A third option is one (or a stack) of the modern, high-performance
>> JavaScript frameworks.  There are many good frameworks, and any choice
>> would be contentious.  We should nail down our requirements before talking
>> specific frameworks.  Our key requirements would appear to include:
>> * Supports development of large, sophisticated apps
>> * Apps run quickly on mobile hardware
>> * Responsive, touch-friendly widgets
>> * Supports 60 fps animation on mobile hardware
>> * Will continue to be maintained if one major corporate backer changes
>> direction
>>
>>
>> These options are not completely mutually exclusive - we can complete
>> apps written in Enyo 2, but rewrite half-written ones in either next-gen or
>> another framework.
>>
>>
>> These decisions will take time, so I recommend suspending development,
>> until we have a new direction, on Enyo 2 apps which are not yet mostly
>> functional.  The two apps that appear to fall in this category are Calendar
>> and Photos & Videos.
>>
>>
>> Doug Reeder
>> reeder.29 at gmail.com
>> https://ello.co/dougreeder
>> 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
>>
>
>
> _______________________________________________
> Luneos-dev mailing list
> Luneos-dev at lists.webos-ports.org
> http://lists.webos-ports.org/mailman/listinfo/luneos-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webos-ports.org/pipermail/luneos-dev/attachments/20160412/e9554361/attachment.html>