<p dir="ltr">This is excellent news! I hope LG grants the Enyo team the resources to implement their vision.</p>
<p dir="ltr">The key takeaway is that Enyo 2 performance has plateaued, so apps will need to be rewritten to be faster (and supported, long-term).</p>
<p dir="ltr">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.</p>
<p dir="ltr">Human perception is unchanged - apps need to respond within a tenth of a second to be "instantaneous". <a href="https://www.nngroup.com/articles/response-times-3-important-limits/">https://www.nngroup.com/articles/response-times-3-important-limits/</a>  Animation needs to be about 60fps. If we close these gaps we're done forever.</p>
<p dir="ltr">We can't depend on Moore's Law to rescue us.  <a href="http://arstechnica.com/information-technology/2016/02/moores-law-really-is-dead-this-time/">http://arstechnica.com/information-technology/2016/02/moores-law-really-is-dead-this-time/</a>  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. <a href="https://github.com/DougReeder/enyo-animated">https://github.com/DougReeder/enyo-animated</a><br></p>
<p dir="ltr">Regarding UI libraries:</p>
<p dir="ltr">We will never have many apps packaged for LuneOS. Mozilla and Google plan for Progressive Web Apps to mostly displace packaged apps:  <a href="https://developers.google.com/web/progressive-web-apps?hl=en">https://developers.google.com/web/progressive-web-apps?hl=en</a><br>
This will massively increase the number of apps available and ease our app distribution.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Retaining the look of webOS (designed 2008-2011) will attract some users and push others away.</p>
<p dir="ltr">My sense is that UI lib choice and development should not delay app functionality.<br></p>
<p dir="ltr">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.</p>
<div class="gmail_quote">On Apr 11, 2016 6:54 PM, "Alan Stice" <<a href="mailto:alan@alanstice.com">alan@alanstice.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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:</div><div><br></div><div><ul><li>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.</li><ul><li>On the flip side of that coin, Enyo next-gen libraries will likely be more useful outside the context of an Enyo app.</li></ul><li>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.</li><li>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.</li></ul><div><br></div><div>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. </div><div><br></div><div>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.</div></div><div><br></div><div>I see a couple of options for the long term:</div><div><ol><li>Adopt Enyo next-gen when it is released</li><ul><li>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</li></ul><li>Adopt another major app framework</li><ul><li>Again, port/maintain Onyx or Mochi ourselves OR adopt a new UI library which would definitely not look/feel like webOS</li></ul></ol></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>- Alan</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Sat, Apr 2, 2016 at 10:43 PM, Doug Reeder <span dir="ltr"><<a href="mailto:reeder.29@gmail.com" target="_blank">reeder.29@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
<br>
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:<br>
<br>
> 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.<br>
<br>
> we think we’ll be able to adopt and adapt many pieces from the greater web development ecosystem<br>
<br>
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.<br>
<br>
Another concern is that LG has delivered a product using its own technology, then abandoned it for outside technology (the LG Watch Urbane LTE).<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
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:<br>
* Supports development of large, sophisticated apps<br>
* Apps run quickly on mobile hardware<br>
* Responsive, touch-friendly widgets<br>
* Supports 60 fps animation on mobile hardware<br>
* Will continue to be maintained if one major corporate backer changes direction<br>
<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
<br>
Doug Reeder<br>
<a href="mailto:reeder.29@gmail.com" target="_blank">reeder.29@gmail.com</a><br>
<a href="https://ello.co/dougreeder" rel="noreferrer" target="_blank">https://ello.co/dougreeder</a><br>
<a href="https://twitter.com/reeder29" rel="noreferrer" target="_blank">https://twitter.com/reeder29</a><br>
<a href="http://reeder29.livejournal.com/" rel="noreferrer" target="_blank">http://reeder29.livejournal.com/</a><br>
<br>
<a href="http://hominidsoftware.com" rel="noreferrer" target="_blank">http://hominidsoftware.com</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Luneos-dev mailing list<br>
<a href="mailto:Luneos-dev@lists.webos-ports.org" target="_blank">Luneos-dev@lists.webos-ports.org</a><br>
<a href="http://lists.webos-ports.org/mailman/listinfo/luneos-dev" rel="noreferrer" target="_blank">http://lists.webos-ports.org/mailman/listinfo/luneos-dev</a><br>
</blockquote></div><br></div></div>
<br>_______________________________________________<br>
Luneos-dev mailing list<br>
<a href="mailto:Luneos-dev@lists.webos-ports.org">Luneos-dev@lists.webos-ports.org</a><br>
<a href="http://lists.webos-ports.org/mailman/listinfo/luneos-dev" rel="noreferrer" target="_blank">http://lists.webos-ports.org/mailman/listinfo/luneos-dev</a><br>
<br></blockquote></div>