1/ Instead of https://github.com/PolymerLabs/IMD , avoid HTML dep system based on less flexible paths & use a full module system
-
-
Replying to @jrburke
2/ w/modules can define elements/templates w/ loader plugins, name vs path separation & you are using a JS module system anyway, right?
1 reply 0 retweets 2 likes -
Replying to @jrburke
3/ See https://github.com/jrburke/element for thoughts in that direction. Used in a shipping app
1 reply 1 retweet 2 likes -
Replying to @jrburke
4/4 HTML Imports will always fundamentally fight with a module system. I suggest picking one or the other
1 reply 1 retweet 4 likes -
Replying to @justinfagnani
@justinfagnani@jrburke: I've got similar questions. I want more control over *all* loading in the platform, but that's different.1 reply 0 retweets 0 likes -
Replying to @slightlylate
@justinfagnani@jrburke: i.e., if some JS loading strategy is "more flexible" but gives up perf, it means we're missing a primitive.2 replies 0 retweets 0 likes -
Replying to @slightlylate
@slightlylate@jrburke In this case the primitive is the ES module loader. I want HTML imports to go through that so you can import by name.2 replies 0 retweets 0 likes -
Replying to @justinfagnani
@slightlylate@jrburke but the loader needs to be spec'ed first :)3 replies 0 retweets 0 likes
@justinfagnani: I'm actually pretty disappointed that the JS community doesn't grok this more deeply. THREADS PEOPLE, THREADS
/cc @jrburke
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.