Enyo 2.7.0 Released
57 views
Skip to first unread message
Pre101
Mar 31, 2016, 8:53:23 PM3/31/16
to Enyo Development
Those of you who've been paying attention to our GitHub account should know by now that we've been working on polishing up the 2.7.0 public release. I'm happy to announce that Enyo 2.7.0 has hit the streets. Its little brother enyo-dev has also reached its 1.0.0 milestone and is available on npm.
I encourage you to read the post in our forum if you want to see how to get started.
Now that Enyo 2.7 is out the door, we’re focusing on the future. You should go now and read this blog post about our future direction. We look forward to engaging with you here in the group about the content of that post and your ideas for things we should consider.
Cage Sarin
Apr 2, 2016, 4:56:49 PM4/2/16
to Enyo Development
Looks great! Thanks for all the hard work on this and making it available to the community. Looking forward to seeing what's in store for the next generation!
Doug Reeder
May 21, 2016, 1:46:53 PM5/21/16
to enyo-dev...@googlegroups.com
1. Design for JavaScript will be, not where it is
A. Accept and return Promises, Generators, Web Workers, Service Workers, Web Components, etc. wherever it makes sense. New browser APIs use Promises extensively. Web workers and Service Workers are key to better performance. Web Components are a source of widgets from outside the Enyo community.
i. As a first step, make enyo.Async a “thenable” (https://promisesaplus.com/) in Enyo 2.7.1, for interoperability with Promises. [I’d implement this myself, but my next open slot is probably in 2017.]
B. Polyfill on older browsers instead of creating new APIs. Seek out and get onboard with proposals that look to become standards, like Promises/A+ did.
2. Target 0.1s response times, 60fps animation, on mobile hardware, without help from Moore’s Law.
A. 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. Once these gaps are closed, web apps feel like native - there’s no more catching up to do.
B. 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 core widgets like Panels to use CSS Transitions, the Animation API, and/or Web Workers as core technologies, not just widgets at the fringes like my enyo-animated: https://github.com/DougReeder/enyo-animated
3. Speed up app launch by allowing asynchronous component setup. Complicated setup could proceed in multiple threads.
A. Examples include a app-specific facade/DAO for a client-side DB ( http://searchablenotes.hominidsoftware.com/ ) and Components that load configuration from a local file or a Service Worker.
B. Components could return a Promise or undefined (as they do now) from the create() method. Their parent would return Promise.all() on an array of the child return values. This promise will resolve when all of the child Promises resolve (Promise.all() works properly with regular values like undefined.) The parent component returns the Promise.all() promise, and can also take action when it resolves. (Is render() the next lifecycle method?)
4. Retain a List with swipeable, drag-to-rearrange items, like enyo.List. (enyo.DataList doesn’t currently offer that.) See http://webos-ports.org/wiki/Swipe_UI for why this builds on the legacy of webOS.
On Mar 31, 2016, at 8:53 PM, Pre101 <pre10...@gmail.com> wrote:
> Now that Enyo 2.7 is out the door, we’re focusing on the future. You should go now and read this blog post about our future direction. We look forward to engaging with you here in the group about the content of that post and your ideas for things we should consider.
Doug Reeder
reed...@gmail.com
https://ello.co/dougreeder
https://twitter.com/reeder29
http://reeder29.livejournal.com/
http://hominidsoftware.com
A. Accept and return Promises, Generators, Web Workers, Service Workers, Web Components, etc. wherever it makes sense. New browser APIs use Promises extensively. Web workers and Service Workers are key to better performance. Web Components are a source of widgets from outside the Enyo community.
i. As a first step, make enyo.Async a “thenable” (https://promisesaplus.com/) in Enyo 2.7.1, for interoperability with Promises. [I’d implement this myself, but my next open slot is probably in 2017.]
B. Polyfill on older browsers instead of creating new APIs. Seek out and get onboard with proposals that look to become standards, like Promises/A+ did.
2. Target 0.1s response times, 60fps animation, on mobile hardware, without help from Moore’s Law.
A. 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. Once these gaps are closed, web apps feel like native - there’s no more catching up to do.
B. 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 core widgets like Panels to use CSS Transitions, the Animation API, and/or Web Workers as core technologies, not just widgets at the fringes like my enyo-animated: https://github.com/DougReeder/enyo-animated
3. Speed up app launch by allowing asynchronous component setup. Complicated setup could proceed in multiple threads.
A. Examples include a app-specific facade/DAO for a client-side DB ( http://searchablenotes.hominidsoftware.com/ ) and Components that load configuration from a local file or a Service Worker.
B. Components could return a Promise or undefined (as they do now) from the create() method. Their parent would return Promise.all() on an array of the child return values. This promise will resolve when all of the child Promises resolve (Promise.all() works properly with regular values like undefined.) The parent component returns the Promise.all() promise, and can also take action when it resolves. (Is render() the next lifecycle method?)
4. Retain a List with swipeable, drag-to-rearrange items, like enyo.List. (enyo.DataList doesn’t currently offer that.) See http://webos-ports.org/wiki/Swipe_UI for why this builds on the legacy of webOS.
On Mar 31, 2016, at 8:53 PM, Pre101 <pre10...@gmail.com> wrote:
> Now that Enyo 2.7 is out the door, we’re focusing on the future. You should go now and read this blog post about our future direction. We look forward to engaging with you here in the group about the content of that post and your ideas for things we should consider.
reed...@gmail.com
https://ello.co/dougreeder
https://twitter.com/reeder29
http://reeder29.livejournal.com/
http://hominidsoftware.com
ryan.duffy
Jun 21, 2016, 4:44:10 PM6/21/16
to enyo-dev...@googlegroups.com
First off, thanks for the detailed feedback. Sorry it¹s taken us so long
to respond. We¹re all very focused on the next gen work so this slipped
through.
1. We¹re definitely looking to take advantage of the latest ES features
where they make sense. We¹re also much more open to using third-party
libraries to fill gaps and provide polyfills. We want to make sure we¹re
focusing on the areas where we can add the most value and leverage
existing, proven libraries where they exist.
2. Performance is a big focus for us. That was a key driver for the
changes in 2.7 and continues to be a primary discussion point during the
design and development of features in next gen. We definitely appreciate
the need for Enyo apps to perform at a high level on low-power hardware
and are already testing the early code on those platforms.
3. This goes hand in hand with the above but I hadn¹t considered a
Promise-based creation scheme. That¹s an interesting idea and I can see
how that help decouple the loading. We haven¹t gotten into that detail yet
but I¹ll definitely keep this in mind. Thanks!!
4. I hope that we¹ll be able to merge our data-driven concepts with the
features of List. Those touch-centric features are less core to the TV
experience but are still an important capability. Good to hear that
they¹re wanted to help us manage the priorities.
Feel free to keep the ideas coming. I¹ll try to be more responsive next
time!
Ryan
ryan....@lge.com
On 5/21/16, 12:47 PM, "enyo-dev...@googlegroups.com on behalf of Doug
Reeder" <enyo-dev...@googlegroups.com on behalf of
>--
>You received this message because you are subscribed to the Google Groups
>"Enyo Development" group.
>To unsubscribe from this group and stop receiving emails from it, send an
>email to enyo-developme...@googlegroups.com.
>To post to this group, send email to enyo-dev...@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/enyo-development/7F3D8E0A-BFCF-43EA-9D1B
>-D020C6C16614%40gmail.com.
>For more options, visit https://groups.google.com/d/optout.
to respond. We¹re all very focused on the next gen work so this slipped
through.
1. We¹re definitely looking to take advantage of the latest ES features
where they make sense. We¹re also much more open to using third-party
libraries to fill gaps and provide polyfills. We want to make sure we¹re
focusing on the areas where we can add the most value and leverage
existing, proven libraries where they exist.
2. Performance is a big focus for us. That was a key driver for the
changes in 2.7 and continues to be a primary discussion point during the
design and development of features in next gen. We definitely appreciate
the need for Enyo apps to perform at a high level on low-power hardware
and are already testing the early code on those platforms.
3. This goes hand in hand with the above but I hadn¹t considered a
Promise-based creation scheme. That¹s an interesting idea and I can see
how that help decouple the loading. We haven¹t gotten into that detail yet
but I¹ll definitely keep this in mind. Thanks!!
4. I hope that we¹ll be able to merge our data-driven concepts with the
features of List. Those touch-centric features are less core to the TV
experience but are still an important capability. Good to hear that
they¹re wanted to help us manage the priorities.
Feel free to keep the ideas coming. I¹ll try to be more responsive next
time!
Ryan
ryan....@lge.com
On 5/21/16, 12:47 PM, "enyo-dev...@googlegroups.com on behalf of Doug
Reeder" <enyo-dev...@googlegroups.com on behalf of
>You received this message because you are subscribed to the Google Groups
>"Enyo Development" group.
>To unsubscribe from this group and stop receiving emails from it, send an
>email to enyo-developme...@googlegroups.com.
>To post to this group, send email to enyo-dev...@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/enyo-development/7F3D8E0A-BFCF-43EA-9D1B
>-D020C6C16614%40gmail.com.
>For more options, visit https://groups.google.com/d/optout.
Ruben Vreeken
Jun 22, 2016, 4:54:21 PM6/22/16
to Enyo Development
Just a sort of thinking-out-loud 2ct contribution:
One of the biggest gripes I have currently with the way the data layer works is that the datastore changed to become a singleton.
It'd be so much more powerful if you could instantiate stores and use them as repositories.
One of the biggest gripes I have currently with the way the data layer works is that the datastore changed to become a singleton.
It'd be so much more powerful if you could instantiate stores and use them as repositories.
Also, there are a few quite unique things about enyo and it's handling of interactions like touch.
Things like being able to preview dom events and the way the entire event handling is abstracted away from the dom to become a first-class citizen in enyo's component-based architecture.
Things like being able to preview dom events and the way the entire event handling is abstracted away from the dom to become a first-class citizen in enyo's component-based architecture.
I hope these will remain in the next generation as they truly add some unique value, despite the fact that tv's are not all that touch-centric. (besides, other types of gestures might well become more important in the future)
Is there any work done towards virtualizing the dom? Or perhaps something like this: https://medium.com/@jayphelps/lazydom-an-experiment-to-bring-virtual-dom-to-the-browser-natively-6a2f47096aca#.q1qhnoys3
Taking full control over DOM interactions when it comes to rendering, layout, flow/reflow etc could open up a lot of interesting opportunities in terms of performance
Is there any work done towards virtualizing the dom? Or perhaps something like this: https://medium.com/@jayphelps/lazydom-an-experiment-to-bring-virtual-dom-to-the-browser-natively-6a2f47096aca#.q1qhnoys3
Taking full control over DOM interactions when it comes to rendering, layout, flow/reflow etc could open up a lot of interesting opportunities in terms of performance
--
Ruben
Reply all
Reply to author
Forward
0 new messages