975548 - make MV* infrastructure choice

Status: RESOLVED FIXED

(Hello (Loop) :: Client, defect, P1)

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

Niko has summarized the Talkilla stuff and various pros and cons at <https://webrtc-apps.etherpad.mozilla.org/109>.

We're going to talk to James Lal (a Gaia dev) Monday morning.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

Just had a long call with tofumatt, who's working in the apps team, and whose current focus is something like "work out best practices for web app development across mobile & desktop for recommendation both for the Mozilla community and the web at large.  It was long and super helpful.  If I don't get a chance to brain dump that info here before Monday, I'll do it then.

Comment 3

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

My personal opinion is that as we're doing an MLP first, any choice we make now could be easily reconsidered after we land it anyway.

So as most part of the frontend team is comfortable & productive using Backbone already, I'd keep it for now; maybe just switching from jQuery to Zepto and from underscore to lodash, to minimize weight and increases performances. Backbone.Native involves underscore and mocks a fake jQuery object which exposes an uncompatible API with jQuery, so I wouldn't personally vote for taking that path. 

Keeping using the tooling we already know, we'll feel "at home", take less risks and will be most likely to meet our deadline. After that, we'll obviously keep challenging that choice with feedback from real world, which is kinda really good if you ask me.

The only remaining question is the required security review for all these tools, which could take a bunch of time & could defeat the whole purpose of that strategy; though I have no idea how long this proccess can take, so any input is welcome here.

Comment 4

[Florian Quèze [:florian]]

(In reply to Nicolas Perriault (:NiKo`) from comment #3)
> as we're doing an MLP first, any choice we make
> now could be easily reconsidered after we land it anyway.

I would challenge this. If you start without framework, it's easy to add one later if the need becomes obvious. On the other hand, if you include a framework for the first landing and then want to stop using it, you may have to rewrite most of the rest of the code to work without the framework.

Also, how much UI is needed for the MLP? IIRC text chat is out of the scope for now, so it seems you need only 2 <video> tags and a few buttons. How would using an existing MV* solution help for this?

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to Florian Quèze [:florian] [:flo] from comment #4)
>

> I would challenge this. If you start without framework, it's easy to add one
> later if the need becomes obvious. On the other hand, if you include a
> framework for the first landing and then want to stop using it, you may have
> to rewrite most of the rest of the code to work without the framework.

My experience quite agrees with the above statement when it comes to libraries or frameworks that are designed to be mixed in (e.g. CSS, jQuery)

It’s also been my experience that other sorts of libraries have different characteristics.  Particularly germaine to this case, libraries that make non-trivial assertions about  code-structure and organization (Backbone is one example, Dojo is a more extreme one) don’t seem to work quite the same way.  If you start without them and then add them in later, it can be easy to make the code more confusing and hard to follow.

> Also, how much UI is needed for the MLP? IIRC text chat is out of the scope
> for now, so it seems you need only 2 <video> tags and a few buttons. How
> would using an existing MV* solution help for this?

I do see the point that MLP itself is somewhat oversimplified.  I suspect that that actually works for us in combination with the above.  What I mean is that I’d expect it to be able to be fairly similar amounts of work to either pull in an MVC framework or get rid of one: e.g. a code-refactoring or re-org that would require some work.  My gut says that because of the simplicity here, that work wouldn’t be trivial, but it wouldn’t be overly huge either.

While it's possible that my gut is leading me astray, MLP is just the sort of place where we want to fail our proposals fast, rather than finding out problems much later.

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

Niko and I had a super helpful discussion with James Lal (a long-time Gaia dev, and a long-time web dev before that), which yielded a whole variety of info.  I'll file a few more bugs on the non-MVC-related stuff early next week.

The main MVC takeaway from that discussion other was this: There's no particular standard for code organization in Gaia apps. Some stuff tries to roll its own MVC, other apps do other things.  One of the things that James mentioned felt significantly missing from not having real MVC setus was event emitters.

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to Dan Mosedale (:dmose) from comment #2)
> Just had a long call with tofumatt, who's working in the apps team, and
> whose current focus is something like "work out best practices for web app
> development across mobile & desktop for recommendation both for the Mozilla
> community and the web at large.  It was long and super helpful.

Some key points from that discussion:

He's written multiple apps in Backbone (with lodash and zepto)for mobile.  The most substantial of these was a foursquare app (which is a bit buggy, but can be played with at http://around.vegan.com/).  His experiences included

* backbone appears to perform as well or better than gaia apps on FirefoxOS 1.1 running on a very low-end phone
* zepto and lodash seem to work fine on Firefox (a concern Niko had expressed, so I asked)
* on an iPhone 5s, his app was faster to start and faster to use than the iOS native app

After discussing our constraints with him for awhile, his suggestion was just to go with either Backbone or something hand-rolled (we talked about a bunch of other frameworks, but narrowed it down these).

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

Make no mistake, I think there is more risk around this choice than around most of the other ones, but given our constraints of "get something this group can move fast" and "has a decent chance of proving suitable to propose for uplift", this choice has the best shot from what I can see.

Note that one thing that will need to be figured out pretty quickly is how webl10n is likely to interact with any lodash templating that we want to do here.  Probably worth a short spike of somebody's time early this weekend.

Comment 9

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

> so it seems you need only 2 <video> tags and a few buttons

Are you sure we don't actually need a bit more than that?

Comment 10

[Florian Quèze [:florian]]

(In reply to Nicolas Perriault (:NiKo`) from comment #9)
> > so it seems you need only 2 <video> tags and a few buttons
> 
> Are you sure we don't actually need a bit more than that?

Do you have the mockup of the UI you are going to implement?

Comment 11

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

The only unofficial piece I had access to is this: http://people.mozilla.org/~jboriss/temp/instant_sharing_drafts/interface_parts_and_share_0_4.png

But it still misses a bunch of pieces (eg. incoming call window, etc.)
I'd be happy to have the full list of the expected UI components, layouts and view states in order to make a decision.

Comment 12

[Adam Roach [:abr]]

In the interest of getting something stood up this weekend, we're going to stick with Dan's suggestions (backbone, zepto, lodash). If it turns out that our reliance on an MVC library isn't as necessary as we think at this time, we can revisit that decision.

Comment 13

[aleth [:aleth]]

I hesitated to comment as I'm just an interested observer and not working on Talkilla myself. But I was surprised at the prospect of frameworks and libraries landing on mozilla-central. 

Shouldn't mozilla code demonstrate by example the power of web standards? Landing frameworks rather undermines the claim that you can do what you need with standard JS and HTML.

Comment 14

[Adam Roach [:abr]]

Attachment: Minimal framework libraries

Comment 15

[Florian Quèze [:florian]]

Some of the files included in this pull request seem to have custom licenses:

Lo-Dash 2.4.1 (Custom Build) lodash.com/license | Underscore.js 1.5.2 underscorejs.org/LICENSE

/* Zepto v1.1.3 - zepto event ajax form ie - zeptojs.com/license */

Comment 16

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

Comment on attachment 8384151 [details] [review]
Minimal framework libraries

Looks good to me

Comment 17

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

Sorry Florian your comment went while I was writing mine. Both seem to be MIT, I can see any problem but maybe I'm missing something?

Comment 18

[Adam Roach [:abr]]

(In reply to Florian Quèze [:florian] [:flo] from comment #15)
> Some of the files included in this pull request seem to have custom licenses:
> 
> Lo-Dash 2.4.1 (Custom Build) lodash.com/license | Underscore.js 1.5.2
> underscorejs.org/LICENSE
> 
> /* Zepto v1.1.3 - zepto event ajax form ie - zeptojs.com/license */

Thanks for the heads up. I'll ping Gerv for review, but all three of those are stock MIT licenses, so I don't anticipate any issues.

Gerv: can you comment on the importation of javascript code under the MIT licenses cited above?

Comment 19

[Maire Reavy [:mreavy]]

Adam/Dan -- I expect the three of us to make this decision together, but I wanted this bug to have an owner since so much depends on this decision.

Comment 20

[Gervase Markham [:gerv]]

http://zeptojs.com/license and http://underscorejs.org/LICENSE are both fine. 

Gerv

Comment 21

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

Zepto actually behaves quite differently from jQuery when it comes to DOM events, and some bits are not 100% compatible when combined with Backbone, so I had to switch to regular jQuery (2.10 stable). 

jQuery license information is available here: https://jquery.org/license/ (MIT). Gerv, can you confirm it's okay?

Comment 22

[Gervase Markham [:gerv]]

If this code is going into Firefox, the different MIT licenses used need to be added to about:license. That goes for jQuery too if it's not already there.

Gerv

Comment 23

[Mark Banner (:standard8)]

https://hg.mozilla.org/projects/elm/rev/8ce423bdfca3

Comment 24

[Adam Roach [:abr]]

I'm closing this bug, based on the fact that we clearly have our first cut at the MVC setup, and the corresponding libraries are now all landed on elm. For clarity, they are:

  * Backbone
  * jQuery
  * Lodash

Comment 25

[Mark Banner (:standard8)]

https://hg.mozilla.org/mozilla-central/rev/8ce423bdfca3

Comment 26

[u279076]

Untracking for QA. Please needinfo me to request specific testing.