- From: Brian Leroux <brianl@adobe.com>
- Date: Sun, 10 Mar 2013 11:24:30 -0700
- To: Marcos Caceres <w3c@marcosc.com>
- CC: "public-closingthegap@w3.org" <public-closingthegap@w3.org>
I'm still collecting my thoughts but the general pattern we're seeing is phonegap apps constructed with asset pipelines (like Jekyll on the easy end, and on the more complex side tools like Bower and Volo). The issue is that apps have dependencies, independently versioned, and those dependencies are collections of static assets. For example, the humble button could be CSS, an icon image, perhaps a font, a JS polyfill for fast-click, and a JS shim for touch events (but only for IE based environments). Traditional web stack bundles all this junk. Web components think about the context once these assets are already loaded but otherwise follow the traditional web model of script/img/link, etc. Taking a hit on latency to load assets for IE in non-IE environments is not optimal. Build tooling is the only reasonable answer today. (Grunt, or Yeoman perhaps.) We see conditional compilation happens in phonegap since we know the env at build time in phonegap based apps. Ideally the assets themselves could be packaged, thus could be lazy loaded collectively, while discreetly versioned, and exist in an independent DOM. Developers know this, and in particular the NodeJS community is cooking up compelling solutions: Component and Browserfy. It is not unreasonable to expect many apps in the future with an index.html continuing a single <script> tag that leaving the rest up to these frameworks solve. There's a great article called 'building the next soundcloud" which describes a home rolled version of the same. I am aware that shadow dom/web components are in the works to fix this. Just highlighting the issue from our perspective. On 3/10/13 5:41 AM, "Marcos Caceres" <w3c@marcosc.com> wrote: >Hi Brian, > >On Saturday, 9 March 2013 at 22:13, Brian Leroux wrote: >> - asset loading (script, img, and link simply do not cut it for more >> complex apps that require dependency resolution) > >If possible, could you please elaborate on this? Is there other solutions >you've seen on other platforms that perhaps we could look at? I'd like to >understand the problem further. > >-- >Marcos Caceres >http://datadriven.com.au > > >
Received on Sunday, 10 March 2013 18:24:59 UTC