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 <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] > <mailto:[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 > > <https://docs.google.com/document/d/1Lels5HA1CgWSrVek5JFuR9sYq--y4mmjXmpRQBWLdkU> > [2] https://github.com/mozilla-b2g/gaia/tree/master/apps/music/views > <https://github.com/mozilla-b2g/gaia/tree/master/apps/music/views> > [3] > https://github.com/mozilla-b2g/gaia/tree/nga/apps/communications/contacts/views > > <https://github.com/mozilla-b2g/gaia/tree/nga/apps/communications/contacts/views>_______________________________________________ > dev-fxos mailing list > [email protected] <mailto:[email protected]> > https://lists.mozilla.org/listinfo/dev-fxos > <https://lists.mozilla.org/listinfo/dev-fxos>
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
