I think a single backend with many, light, replaceable front-end parts is critical to us building a portable OS.
(Web) Components will help us to: - Ensure visual consistency across our core apps - Abstract away complexity to allow app peers to get on with their business logic - Optimize UI performance once and benefit everywhere - Provide a starting block for third-party developers to compose fast, polished web-applications - Prototype new ideas quickly Arguable we could use a JS framework (eg. React) instead of the built-in browser APIs, but: - Frameworks come and go. What's next year's trendy framework? Should we wait for that? - Components can't be used unless the user is happy to load the framework dependency too (React > 300KB) [1] - Browser APIs will tend to be/become faster than a JS framework equivalent. - We're Mozilla, we should be supporting the platform we're building :) --- In Summary: *We need both :)*[1] https://aerotwist.com/blog/the-cost-of-frameworks/ *W I L S O N P A G E* Front-end Developer Firefox OS (Gaia) London Office Twitter: @wilsonpage IRC: wilsonpage On Fri, Nov 20, 2015 at 10:18 AM, Vivien Nicolas <[email protected]> wrote: > On Fri, Nov 20, 2015 at 6:19 AM, Justin D'Arcangelo < > [email protected]> wrote: > >> First off, I agree with David that we should be focusing on web >> components. Having worked with them extensively over the past few months, >> they add tremendous value in terms of code reuse and general code >> cleanliness and encapsulation. >> > > It is not a big surprise that I agree with many things Justin says. But I > want to pile a bit on Web Components beeing a magic answer. > > As stated in the Architecture Proposal > <https://wiki.mozilla.org/Gaia/Architecture_Proposal#Disclaimers> since > the beginning: > > "This model is not about using x, y or z. It is technology agnostic and > uses very basic primitives of the Web. Various technologies can be put on > top of that (module UI, React, Web Components, etc.) and can actually be > benchmarked with real data from users using Telemetry." > > The goal of the architectural changes which are proposed is *not* to > enforce a UI solution. So it sounds strange to be able to replace all the > proposal, which is a set of different pieces (aka Service Workers, Data > Sync, Telemetry, ...) by a single answer. Especially one that is so highly > UI related. > > Now if we want to dive in the UI world, yes, a component system is > definitively something we should all be looking at for *consistency*, > *maintainability* and *performance*. > > What this component system should be, is not part of the proposal, > specifically to avoid the confusion between what components are used for, > and what the proposal is about. > > Now, it is understandable that Web Components is the default choice of > many Gaia developers as a component mechanism. > I would even validate the choice, if we do have dedicated raptor tests to > validate their performance and ensure they do not regress over time (which > is often the fate of a code that starts small and slowly by slowly get more > features). > Without raptor test it could not be proven that they will answer the > *performance* criteria over time. > > Having a dedicated set of people that works on it, is definitively part of > the plan that nobody knows but is the companion of the new architecture > proposal: Architecture Transition Plan > <https://wiki.mozilla.org/Gaia/Architecture_Transition_Proposal#Toolkit_Team> > > But it would be a shame to focus all our efforts in something that a third > party may not even consider. > > If someone wants to ship a FirefoxOS powered device, it may rewrite all > the UI, or just some parts, to please itself or its own UI/UX team. This > custom solution may use a completely different framework, like React for > example. If all our efforts has been focused on Web Components, all our > work will basically be garbage for them (even for us if one day someone > prove that a new UI framework is way more modular and performant). > > This is why defining a clear backend API that can be easily documented is > important. Beeing able to prove that the backend is not tied to the UI at > all is important too (this is one of the reason of beeing able to run it in > a Worker, you can prove it does not rely on DOM apis or front-end specific > logic). > > This is why offering caching APIs via Service Worker, not tied to a > specific UI framework too, is important as well. To ensure that whatever > framework is choosen, people can benefit from caching to help performance. > > This is why Data Sync is important. Whatever UI framework is used, users > will get their datas. > > Etc... > > Vivien. > > >> >> However, web components only solve our problems on the surface in the UI >> of our apps. The Gaia apps contain an enormous amount of complexity and >> business logic that is not in the UI. For instance, the Music app needs to >> use a complex metadata parser in conjunction with DeviceStorage and >> IndexedDB to scan and store the contents of a user’s music library. What >> NGA brings to the table, in this regard, is the ability to craft an >> easy-to-consume developer API for the app. When we talk about separating >> the front-end from the back-end in terms of “NGA”, we are really talking >> about defining this developer API for the back-end and exposing it via an >> HTTP API. This allows a traditional web developer, who is used to working >> with server-side HTTP APIs, to jump right in and get up and running. >> >> In the case of the Music app, you can see the full list of HTTP APIs here: >> >> >> https://github.com/mozilla-b2g/gaia/blob/master/apps/music/js/view.js#L10-L54 >> >> As for the front-end of things with NGA, our “views” are simply mini-apps >> themselves. A single “view", at the very least, is just an HTML file to >> define the view’s markup end a JS file to wire up the DOM and call the HTTP >> API in the back-end. >> >> This past week I started experimenting with adapting the Music app to >> work on TV. Within an hour, I was able to just drop in a couple new “views” >> that were TV-friendly versions of what we have in the regular phone version >> of the app. Specifically, the Music app normally launches to the “tiles” >> view and is obviously reliant on touch events for tapping on albums to >> start playing them. This needed to be wired up a little differently for TV >> because we needed to be able to use the arrow keys on the TV remote to move >> the highlighting “cursor” around from album-to-album. In a very simplified >> nutshell, here’s what the “tiles” view needs to do: >> >> - Perform an HTTP request to the back-end URL “/api/albums” >> - Loop over the response from the back-end and generate the HTML >> - Attach an “onclick” event handler for the tiles to start playing the >> album >> - To play the album, we perform an HTTP request to the back-end URL >> “/api/queue/album/{album_id}" >> >> As you can see, these look very much like things your average web >> developer would be familiar with. So, to do a TV version of this “tiles” >> view, I simply created a copy of the phone “tiles” view into another folder >> called “tiles-tv”. For the TV version of the “tiles” view, the operations I >> needed to do were very similar: >> >> - Perform an HTTP request to the back-end URL “/api/albums” >> - Loop over the response from the back-end and generate the HTML >> - Attach a “keydown” event handler for moving the focus highlighting >> around between tiles >> - When the user presses [Enter], we perform an HTTP request to the >> back-end URL “/api/queue/album/{album_id}” >> >> I was also able to provide a completely different CSS stylesheet for my >> TV-optimized “tiles” view. This was also extraordinarily easy because the >> regular phone version of the “tiles” view has its own CSS file that only >> deals with styles related to just that one view. >> >> The key takeaway here is that defining a clear and easy-to-use HTTP >> back-end for our apps is extremely helpful in achieving a very clear >> separation of logic between front-end and back-end. It also provides a way >> for regular web developers to jump in and customize the front-ends of our >> apps without having to understand all the complexity that we deal with in >> the back-end. The other important point to note is that the NGA method of >> separating our “views” in the front-end allows us to swap out entire >> screens in our apps wholesale. Our “views” are really just simple >> “mini-apps” themselves and because of this, I firmly believe that this >> architecture will help us take on unknown form factors in the future. >> >> -Justin >> >> >> On Nov 19, 2015, at 11:38 PM, David Flanagan <[email protected]> >> wrote: >> >> I've been thinking a lot about this thread in the context of Ari's talk >> at the All Hands meeting yesterday. We're working on an OS that has to run >> on smartphones, smart tv's and other form factors tbd. Ari asked us to >> focus on portability, and that obviously will be key to our ability to run >> on different form factors. >> >> I had something of an epiphany today: In the future, teams inside and >> outside of Mozilla will build devices that run FirefoxOS and will create >> products that provide true user value and delight. At this moment we don't >> know what those products will be. So for core FirefoxOS developers, our >> users are these future product development teams. We need to be building an >> OS that is so fast and flexible, so portable and performant that product >> developers will feel delight using our platform. >> >> With that in mind, I'd like to suggest that we'd be better served by >> focusing on web components than by working on NGA. >> >> Converting our building blocks to web components and then refactoring our >> apps to use those components and to be based on higher-level web components >> will give us much of the modularity and portability that we're seeking from >> NGA, but at the same time, it will also create a high-quality library of >> reusable UI components that third party app authors (including those who >> are embedding FirefoxOS in new products) can use to more easily create apps. >> >> David >> >> On Fri, Nov 13, 2015 at 9:40 AM, Wilfred Mathanaraj <[email protected]> >> wrote: >> >>> Hi all, >>> >>> Given the Music app splitting we have done in time for 2.5 we want to >>> move ahead - I think it makes sense to be executed in a “train model” >>> fashion. >>> We should start from the top of the list and work through the list. >>> >>> When I say splitting of the apps, we are looking for the following >>> activities to be done: >>> 1. FE/BE split >>> 2. Split views >>> 3. Page transition >>> >>> Why did I choose the priority below? - for now we have 2 products that >>> we work on: smartphone and TV, but moving forward we need to investigate >>> what are the products that make sense for us and when we enter the >>> connected devices market 3rd party developers need to be able to develop >>> differing views for our core apps. >>> >>> With this is mind we went through some exercise to define a priority for >>> the apps to be ported to the updated architecture. >>> >>> Priority list: >>> >>> - *Settings* - this is a key app for any product mozilla may be >>> planning to release; different apps will have different needs to display >>> information to the user in the settings >>> - *Camera *- again a key app for a lot of the modern devices >>> - *Contacts* - everyone wants to have contacts on their devices - >>> but they need different level of information - creating differing views >>> is >>> going to key here >>> - *Calendar* - as with contacts its critical to have differing views >>> but not as high priority as contacts >>> - *Gallery* - another core app that every connected device may need >>> to have >>> - *E-mail* - typing emails on smaller devices will be a problem and >>> therefore creating readable email view may be needed for some connected >>> deviceds >>> - *Calculator *- table stake app >>> - *Clock *- table stake app >>> - *Browser *- one of core mozilla apps but a table stake app for >>> some of the connected devices >>> >>> >>> Some of the engineering teams, who have already worked on this split, >>> will be reaching out in smaller teams to discuss best practices and quick >>> wins for this activity. >>> >>> BR >>> Wilfred >>> >>> --- >>> FxOS Product Management >>> Mozilla Corp., UK >>> >>> >>> >>> >>> >>> _______________________________________________ >>> dev-fxos mailing list >>> [email protected] >>> https://lists.mozilla.org/listinfo/dev-fxos >>> >>> >> >> > > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos > >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
