@robotlolita frameworks are a cluster of modules that want a single instance of all deps, not dups of shared dependencies.
-
-
Replying to @wycats
@wycats@robotlolita why must a framework rely on shared state to be a framework?1 reply 0 retweets 2 likes -
Replying to @ljharb
@ljharb@robotlolita Frameworks often deal with genuinely global state, like the DOM.2 replies 0 retweets 0 likes -
Replying to @wycats
@wycats@robotlolita sure, but you’re not npm installing the DOM1 reply 0 retweets 0 likes -
Replying to @ljharb
@ljharb@robotlolita Sure, but you may have multiple duplicate libraries interacting with it.1 reply 0 retweets 0 likes -
Replying to @wycats
@wycats@robotlolita so, the state is shared in the DOM. Why do your modules need state, ie, need to rely on there being a require cache?3 replies 0 retweets 0 likes -
Replying to @ljharb
@ljharb@robotlolita Example: Ember generates object guids on the hot path by incrementing IDs. They end up in DOM and are used for lookups.1 reply 0 retweets 0 likes -
Replying to @wycats
@wycats@robotlolita good example. would document.guid++ work without these complications tho?1 reply 0 retweets 0 likes -
Replying to @ljharb
@ljharb@robotlolita possibly. We'd have to audit all of Ember and be very careful about top-level state. Not super-idiomatic :/1 reply 0 retweets 0 likes -
Replying to @wycats
@wycats@robotlolita true. Tho if a single module abstracted away that knowledge, that’d be the only code path that had to worry about it.2 replies 0 retweets 0 likes
@ljharb @robotlolita Would have to bench -- document.emberGuid++ might be orders of magnitude slower.
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.