Hey Alive, nice to heard from you! If I understood correctly, one of the central point of your arguments are against the <iframe>(s) split ? Let me know if I misunderstood ?
If that's correct I think you are missing the core part of my argumentation when I spoke about <iframe>s and what those are offering. <iframe> are documents. A document is a core web object, which offers things that *really* framework can hardly do. It is not a new cool way of writing things for the web. It is the fundamental part of the web you are using every time you're navigating between 2 urls. But more importantly, documents are something the platform, as in the web platform, can understand. That's one of the thing I'm trying to explain since some times: If we want to build a platform, we need the platform to understand the semantic of a what is a web app. Documents is the best thing I have handy - nothing else as far as I know in the web platform can scope js, css and the dom properly. No. Web Components, can not. I would be very happy to be able to replace <iframe>s by top level document, where each panel is its own document. Then you would really think of this <iframe>s change as a no change. Many website already use navigation between pages. What NGA is not trying to define, is what is inside those web pages - since as you mentioned, there may be various way to handle your application constraints. No, IIRC one of your point is that <iframe>s seems to fit the phone in some ways, as it is mostly panel based - which is not true for tablets for example. That's true. But I guess most of your web browsing is on desktop ? And you are still navigating between documents right ? The web is not a single page - but you probably still like browsing the web. Cheers, Vivien. On Wed, Nov 25, 2015 at 6:41 PM, <[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. > > 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 >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
