I know both myself and Justin were strongly against the document-per-view approach when Vivien first suggested it. But having both worked building apps around this strategy, we can now both clearly see the advantages (listed by Justin).
It's different (really different!) to the majority of approaches being used elsewhere, but for me, this is what is most exciting! We're questioning the norm and defining new patterns (not 'frameworks') to make applications on the mobile web simpler to build/update, whilst using the strengths of our platform to bring features and performance. This is *real* 'innovation' coming from Mozilla; I'm excited to be a part of it! *W I L S O N P A G E* Front-end Developer Firefox OS (Gaia) London Office Twitter: @wilsonpage IRC: wilsonpage On Wed, Nov 25, 2015 at 8:06 PM, Justin D'Arcangelo <[email protected] > wrote: > Francisco points out something that, to me, is the thing of most > significant value of NGA. Having a separate “document” for each view, while > not a new concept to the greater web, is a new concept for mobile web apps. > In the Music app, each “view” is effectively its own mini-app. Again, if > you look at the “/views” sub-folder in the Music app, you’ll see exactly > what I mean: > > https://github.com/mozilla-b2g/gaia/tree/master/apps/music/views > > Any one of those folders can be considered its own mini-app. The best > thing about this is that it inherently reduces the scope of each view > drastically. This isn’t forcing every view to be constructed in any one > way. Heck, you could even build one of your views with Angular or React if > you really wanted to and it wouldn’t impose Angular or React principles on > the rest of your application. We have also explored the possibilities of > letting each view have its own l10n .properties file for strings. This is > another inherent advantage of this particular multi-document architecture > where a localizer would also benefit from dealing with more limited scopes > (i.e., knowing exactly where each string is being used). We can also be > less concerned with polluting the global namespace when views are separated > like this as each view has its own `window`. > > But, the most powerful thing about this approach, to me, is the fact that > any one of these views (mini-apps) can be completely replaced with an > alternative implementation without affecting the rest of the app. Being > that we’ve always struggled with regressions in the past, this is of > tremendous value. I’ve stated in some earlier responses that this is what > will enable us to easily build versions of our apps for additional form > factors in the future. For instance, the “player” view in the Music app is > currently built to listen for touch events for things like the on-screen > previous/play/pause/next buttons as well as the seek-bar slider. To build a > TV version, you’d simply replace the “/views/player” folder with a new view > (mini-app) that instead listens for keyboard/remote events. To do this, all > a developer would need to do is look at the existing “player” view to see > what API calls are made to perform the necessary operations (e.g. > play/pause, seek, etc.) and ensure that their replacement view does the > same thing. > > Now, its possible that these same benefits could be had by embracing a > different architecture for separation of views. However, the “NGA” way of > separating views (multi-document) is completely natural for the web. In a > single-page application architecture, you would likely have to define some > sort of base-class or other means for defining a “view”. But since we are > using a multi-document approach, this separation means we are simply > providing an HTML file along with any JS/CSS files required by that view. > > -Justin > > > On Nov 25, 2015, at 2:39 PM, Francisco Jordano <[email protected]> > wrote: > > Hi folks, > > On 25 November 2015 at 17:41, <[email protected]> wrote: > >> The problem here is coming from un-trust. >> > >> As you said, splitting panel into iframes will force people to destruct >> the panel dependency. Isn't this just meaning: hey I don't trust you can >> develop a good application architecture with less coupling, so now please >> use NGA because you cannot couple panels anymore even you want to coupling. >> > > That's a really interesting point, why are we talking about panels, we are > writing webs, or at least that was the original idea. We as web developers, > are used to write single page apps cause it's what is suppose to work in > mobile. But again, that's not the web we used to know, it's not the web of > documents, the web we learned while pressing the 'view source code' button. > And it's in our hand to push the platform forward to make the web to work > better everywhere. > > >> >> As a web developer, I wrote less code than you all; but only thing I know >> better is: there is no best practice for Web application. People can use >> any framework, any library, and self-made frameworks to bake their >> application. There is no total solution for web application. So this is not >> a point to say NGA is good. >> > > I totally agree with this, there is not a single solution for everything, > and I think that what it's been call NGA (oh gosh, you don't know how much > I hate the name ;) ), was a set of ideas, that not all of them would make > sense to apply, that will always depend on the nature of the app. For > example, if you take a look to the retrospective [1] of the people that was > trying to apply some of this recommendations, some things worked some > things didn't. > > If by NGA we are talking about splitting the views in documents, again, > there are some of the apps that are more document oriented than others > right? > > >> >> Just like djf mentioned, mozilla knows modularity. I liked that we have >> different architecture design for each app; it makes sense because each >> application is trying to address different user stories and achieve >> different goals. So why do we need a overall one-and-all architecture? >> Even applying the NGA, people can definitely write codes which makes their >> applications looks so different.... you cannot ask people to design the >> modules inside the panels with NGA. >> > > About each app having a different architecture we could be discussing for > a while, we could have people arguing that it delays development with > developers having to get familiar with totally different ways of writing > apps, same problem for contributors, being difficult for them to try to > help in different parts. But as well I agree the beauty and freedom of each > app being shaped by the owners enrich the experience and shows what the web > is. > > Personally I don't think that writing your views in different documents > will prevent you to design your modules in one way or another, it wont > enforce you to not to write ES6 modules or use require.js or use <put your > favourite framework here (avoid react.js and angular cause they will think > we are making fun of them)>. > > For me it's an interesting proposition that allow us to be more flexible > in terms of reusing complete views, interchange them, partners being able > to customize easily, having documents that are almost independent, getting > closer to what we used to do in web development. I would suggest to get a > look to the work in music [2] and contacts [3]. Again, this is totally > subjective, perhaps for me is nicer to work in that way, but that doesn't > mean I'm right. (Oh boy, sometimes even remind me to android activities, > not our activities :)) > > >> >> Unless you invent NNGA: hey, please move every little component inside >> your panel into iframes. Make every module communication become >> asynchronous, even we don't need to do. >> >> Sounds crazy... and this was something you mentioned to me, but never >> convinced me. Yes, being async is good for cases. With promises we can >> write beauituful codes. But sometimes we just need synchronous >> communication. >> >> Also, I like the way people have their own idea about module. Even every >> one starts to use ES6 syntax to write applications, I could tell there >> would be 20 different ways to define a module across 20 different >> applications. Some of them might be inspiring, and I can learn from them. >> Some of them might be still deep coupling, and we need to fix them by >> learning from each other, instead of saying, hey use NGA or NNGA to write >> code, I am just want to help! >> >> Everyone is here to help, who is not? :) >> > > + 1000 \o/ > > >> >> At least I won't say, hey angular is popular, please rewrite your >> application with it. I am just want to help! Hey reactJS is cool, use it! >> I'm just want to help. >> > > ;) > > >> >> No, no. Framework or library won't teach you how to organize your >> application. As I said, even with ES6, I can write bad code with dirty >> module coupling. It's not what you use shape your app. It's what you think. >> It's your experience helping you. I wrote very bad code when I joined >> mozilla, but I made some effort such as read all kind of codes from others >> and did lots of refactoring. Now I have my own "feel" about modularity and >> architecture. If you ask me to follow only one way to write my code, I >> don't think I can grow up. >> > > That's totally right again, no framework or library will prevent that you > shoot yourself in the foot. Also personally I've never seen anyone inside > mozilla telling you have to code in this way, things were proposed and have > to grow within the engineers. > > >> >> I believe what shall be done is not asking people to follow your own >> "future". I think a better way is to gather people sit down to tell each >> other: >> >> 1. What's the current architecture of my application? >> 2. How do I separate my UI and data? If I don't, what's blocking me to do >> that? (Please, don't call that FE/BE. Very confusing.) >> 3. What's possible if I am asked to design an application to fit >> different devices? What would be common, and what would be device specific? >> Don't we just need to extract the data logic from the view logic? Why do we >> need to put every panel and every little component into iframes and >> increase the communication overhead? >> >> What made me sad at most, is that, people is selling NGA ideas like they >> are the sales, not an engineer. I am not the customer. It's really annoying >> to hear 'this is really wonderful' without real data. Such an advertising >> wording does not convince me. I can do the same thing to split modules >> without NGA's help. I can see that some people will still write coupling >> codes with NGA. And in the long run, it hears like: people don't how to >> lessen module coupling before we invent NGA. This is also the point that >> increases the un-trust between developers as I mentioned above. >> >> It's very "interesting" to see people say "NGA is working" and show us >> that pick contact activity now don't need to load the first page. It's not >> coming from NGA. It was a design failure that we must load the main panel >> and then the second panel. >> > > Again I think that by NGA you are talking about different documents, I > don't think the point is look an activity goes through a panel or does or > doesn't do a transition. It's about writing documents, pretty specific with > just the css, dom and js that you will need. And yes, you can get this with > several techniques, if I'm not wrong settings app for example after the > rewrite manages to do this right? Imagine that you are working for the web, > not restrictions of mobile web, you can run everywhere, wouldn't you design > pointing to an specific document? > > And why this interest for the documents? Simple, our platform, a web > browser, is very good with documents, it has a lots of built in stuff for > dealing with them, perhaps we need to push for making it even better in the > mobile web, but ei! wouldn't that be wonderful, improve the mobile web too? > > > >> There was ever an app called settings app.. Long long time ago, we need >> to load the main setting panel when we are using web activity to launch >> certain panel. But Arthur and 佳龍 did lots nice refactoring work to split >> the subpanels. Now we can directly load any subpanels. And what's most >> important, this was happening before NGA. What they use is just require-js >> and have their own design of panels. I bet that I can do the same thing >> without using requirejs. So why can we say NGA did succeed and work because >> of this result..? >> > > require-js is a fantastic tool, and I personally would say to continue > using it whenever you have multiple documents or a single one. What I would > really like is people sitting with each other showing what they manage to > do and others really wanting to give things a try. Hopefully we have > Orlando coming soon and will be fantastic if we can have office hours where > we can sit, chat, code together, prototype :). That's for me the way of > learning, growing, and finally succeeding. > > >> >> TL;DR >> 1. There is No architecture total solution for web. Each app has it own >> shape, its own target, and its own future. >> > > Agree, there is no a ring to rule them all. What has been proposed is a > list of things to take into consideration. > > 2. Force using NGA implies untrust to the devs >> > > Definitely I don't think we are going to force anyone, also using the word > untrust to devs is for me out of the scope. Should we untrust the people > that are proposing changes? I don't think so, I think we have to talk, > debate, try, help each other and be open to collaborate. > > >> 3. Web won't teach you how to coding. Web is silent. >> 4. Brainstorming and learning from each other makes dev grow. Force using >> one framework makes dev become code farmer. >> > > Yes! Let's do that! > > >> 5. When I said NGA, I am talking about "splitting views into iframes". >> Not the gaia-fast-list. Not moving heavy-load things to web worker. Some of >> the technologies are good, but made everything become iframe is not. >> > > ;) exactly let's see what kind of ideas are fitting better in each app :) > Cheers! > f. > > [1] > https://docs.google.com/document/d/1Lels5HA1CgWSrVek5JFuR9sYq--y4mmjXmpRQBWLdkU > [2] https://github.com/mozilla-b2g/gaia/tree/master/apps/music/views > [3] > https://github.com/mozilla-b2g/gaia/tree/nga/apps/communications/contacts/views > _______________________________________________ > 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
