I know both myself and Justin were strongly against the document-per-view
approach when Vivien first suggested it. But having both worked building
(listed by Justin).
platform to bring features and performance.
Post by Justin D'ArcangeloFrancisco 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
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
Hi folks,
Post by a***@gmail.comThe 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.
Post by a***@gmail.comAs 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?
Post by a***@gmail.comJust 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 :))
Post by a***@gmail.comUnless 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/
Post by a***@gmail.comAt 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.
;)
Post by a***@gmail.comNo, 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.
Post by a***@gmail.comI 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
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?
Post by a***@gmail.comThere 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.
Post by a***@gmail.comTL;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.
Post by a***@gmail.com3. 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!
Post by a***@gmail.com5. 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
https://lists.mozilla.org/listinfo/dev-fxos
_______________________________________________
dev-fxos mailing list
https://lists.mozilla.org/listinfo/dev-fxos