On 11/20/2015 05:03 PM, Justin D'Arcangelo wrote: > While much of the NGA plan includes parts of the platform that are > not quite 100% ready to go yet (e.g. ServiceWorkers), we should not > exclude them from our designs.
True, but neither should we include them in places where they don't provide significant value. If Service Workers don't help make an app better in some concrete way, we can defer adding them for the time being. A well-designed app should have no trouble converting to use Service Workers farther in the future, since it's essentially a middleman between the front-end and the back-end. This is already what the Music app does, and given the relative simplicity of our "HTTP" routing, it would be entirely reasonable to use bridge.js directly unless and until we decide that we actually *need* Service Workers for something[1]. In short, we should follow the "You Ain't Gonna Need It" principle when it comes to NGA-ifying apps. > We are building for the future. In my experience, building for the future has about a 50% chance of just adding more plumbing that we have to rip out later anyway. It's extremely difficult to predict exactly what we'll need several years down the line. That's why I advocate for keeping things simple; at least that way, there's less stuff to rip out. > If the app owners cannot agree to follow the architecture that the > NGA group has spent many months defining and validating, then I > really don’t know how we’ll ever scale FxOS up to meet our future > needs. Arguably, I'm in the "NGA group" as well, so not even the NGA group can agree on the architecture. >:D - Jim [1] Of course, we don't *need* Service Workers for anything in the Music app (proof: we're not using them), but I was ok with creating an HTTP-like API for our backend because NGAifying Music was an *experiment*. We shouldn't expect everything from an experiment to be a resounding success. Instead, let's evaluate each piece on its own merits for each place it could be used. _______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
