908951 - [Email] Consider having DOM nodes imported from standalone files.

Status: RESOLVED INVALID

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Kevin Grandon :kgrandon]

E-mail currently has a nice way of separating HTML pieces in different files. It should be trivial to use the new import polyfill if we'd like to standardize implementation. Performance should also be around the same.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

The current AMD/require/r.js usage lets the HTML snippet(s) be inlined into concatenated/optimized JS (as strings) "layers" that are only loaded on demand.

For this bug, I assume you're referring to the changes made in https://github.com/mozilla-b2g/gaia/pull/11674.  It appears that webapp-optimize.js is putting all of the lazy-loaded HTML inside comments in the settings app style.  That seems like it would be a performance regression.

If we didn't use the optimization step and instead used WebComponents.populate(), loading the files separately outside of a concatenation seems like it would be slower too.

My broader issue with making such a change is that r.js is a well-documented toolchain used by other projects with a mailing list and stackoverflow tags and the like.  There are some minor custom bits, but those are using the documented r.js/AMD plugin mechanism.  Relevant docs:
http://requirejs.org/docs/optimization.html
http://requirejs.org/docs/plugins.html

I understand the desire to keep most apps in gaia using the same stuff, but we run into the problem that Gaia is using a home-brew lazy loader with minimal docs (although the module is small enough and straight forward that it's not a major problem for gaia hackers) and a home-brew optimizer with minimal docs.  (https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Platform/Gaia/Hacking#Script_compression_and_optimization only contains "(TBA)".)


As such, I think this is probably WONTFIX for the time being and medium future[1], but I'm interested in hearing your thoughts and :lightsofapollo's thoughts on what you think we could specifically integrate.


1: Namely, I don't think the native WebComponents or Harmony Module stuff is going to obviate the need for explicit application control of lazy loading until our baseline hardware improves greatly.  The HTML Imports spec implies that we need to dynamically create our imports to avoid the imports being marked as blocking.  And we have enough potential total imports that we need to worry about the pre-fetching starving out our app startup logic.  So we'd still need something managing lazy loading, and it still seems like the require/AMD standard with its bells and whistles is still a net win.  Same deal with Harmony Modules where we will want to avail ourselves of its dynamic loader support.

Comment 2

[Kevin Grandon :kgrandon]

I think it would be at least worth profiling and seeing the impact between the various solutions. We need to consider both initial load time and responsiveness of the application. It seems that both solutions would have their own pros and cons.

My desire is to simply use the most performant solution possible. Should AMD/r.js be the winner, I would have absolutely no problem porting all of the existing apps that use lazy loader or lazy dom to use r.js.

I guess the action item here is to compare implementations, and gather performance statistics. I do think there is a strong benefit to having apps technically aligned, but as you are the module owner, I would defer all final email implementation choices to you.

Comment 3

[James Burke [:jrburke]]

I would love to see how web components could work with a module system as I think this is an important piece of feedback to give for the Web Components people. 

In particular, my concerns are that HTML Imports relies on URLs, where modules, even in ES6, as currently spec'ed, use logical IDs that are mapped to paths. It is also unclear to me how a module system would work with Web Components.

Using ES6 Module Loader hooks (which can be simulated today via the AMD loader plugin approach) could be a way to resolve the disparity, but in that model, it could be that HTML Imports spec to may want to allow for a moduleid="" instead of using an URL path. 

We should also verify the ES6 Module Loader API will have the right hooks to do this: the loader hook will want an HTML parser for example, and want resolution of those HTML Imports before evaluating the current component. I think it may work out, but needs a test run/implementation to know for sure.

I am also concerned that the Web Components work is just not stable enough to build upon as I believe they have now talked about moving away from the "element" tag.

But this could be a great opportunity for us to inform the Web Component specs if we can work out the rough areas with using an ES6 type of module loader, even using an AMD loader plugin in the meantime to prove out the concept. And I am happy to give feedback to the ES folks about any changes their module loader API may need. I just have not had time yet to dig into it. 

If we think it is important to sort out more immediately for Gaia to move forward, perhaps I can set it higher on my work list for next sprint. That, or just happy to give feedback if kgrandon wants to dig into it.

I do feel that long term, for web apps, that JS will be the loading entry point, not HTML, so it would be good to verify that Web Components work well in that situation. In particular, I expect further optimization strategies to be based on dependency tracing in JS dependency IDs (which could also include HTML Imports dependencies via Loader hooks).

Comment 4

[Kevin Grandon :kgrandon]

This looks to be done now, and we should focus on haida which will solve the same thing.