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.
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. 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. 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? :) 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. 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. 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..? TL;DR 1. There is No architecture total solution for web. Each app has it own shape, its own target, and its own future. 2. Force using NGA implies untrust to the devs 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. 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. -Alive Vivien Nicolas於 2015年11月23日星期一 UTC+8下午8時46分43秒寫道： > On Fri, Nov 20, 2015 at 5:38 AM, 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. > > > > > "At this moment we don't know what those products will be". > > > This sentence is extremely important to me. It should have been the first > thing I noticed. As far as I know, this is correct. Nobody knows. > > Am I wrong to say this is true since last December ? > > > But...based on Wilfred initial email, there are some hints. Various form > factors. List of most wanted apps. The need for different views for those > apps. > > > This is something we can address. Ensuring the FE and the BE are properly > splitted, with clear and documented APIs, will be helpful, to make it easier > to write various views. My point is that this work should happens first. > > > Once it has happens, you can parallelize work. Some people can work on > transforming the front-end to use a components system, while some other may > work on making the backend more pleasant, more abstract, more performant and > add some new features. > > > Also, once a lot of the business logic has been clearly separated, it would > be much easier to have others helping the front-end of any apps. > > > Concerning point #2. The idea is that porting all the front-end in once is > hard. It is also hard to get many people working on various panels at the > same time. Splitting things into multiple isolated contexts, may let many > people working at the same time on a dedicated view, and limit the possible > area of conflicts. > > One can argue that this can be more or less achieved using the right > framework and beeing very cautious. This is likely. But once the team starts > to be under heavy constraints this is something very hard to keep running. > While strong isolations of views, prevent some changes to leak in other > views, helping developers and reviewers in their daily job. If everybody rush > into web components now, are we sure we will not beeing asked to ship > something before everything has been converted ? And if so, do you really > want to ends up in the same situation than one of two years ago ? > > > I'm less confident in #3 if we want to do it at Gecko level. So far, and as > you mentioned, we lack some platform features to do it properly. Hopefully, > once we have #2 it can be emulated partly at the toolkit level (you will be > happy there is a web component for that). > > > Basically Web Components will help to write views faster, with globally a > more unified experience across the target. But if you want more manpower from > people out of your team in order to move very quickly, you will need to have > a clearly isolated backends with clear APIs, ensure the work of one, will not > conflict nor regress the work of an other, and have a incremental way to > migrate. > > > Also, Web Components will help a lot for the UI paradigm. But this part is > undefined so far. > > Even by assuming all apps has been able to migrate to use components > everywhere before the next rush - we may be in front of a target device that > use completely a completely different metaphor. > Yes, components will have clean the (UI) code base, and it sounds easier to > replace just a component. But you will again have to fix all the app (UI) at > once, working with the limited set of people that knows the app business > logic and constraints, trying to avoid regressions abd collisions. > Sound scary to me. Not saying #1 and #2 will fix everything. But they are > trying to help at least. > > > Vivien. > > > > > 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
