Code organization

[ascott1]

Something I've often struggled with is how to organize my code when I'm not using a framework. Frameworks like Backbone can really help with this by forcing you to organize code into models, collections, and views, but it can be more challenging when working with just vanilla JavaScript or jQuery.

A few months ago I worked through the Udacity course JavaScript Design Patterns, which really helped guide my thinking around this. If anyone is remotely interested in this topic, I highly recommend it (at least the first two chapters - before Knockout.js is introduced).

Would this be a good topic for a future front-end meeting? Or even something we want to provide guidance on? In my mind it is related to #55 by @imuchnik.

[sebworks]

I think trying to understand the underpinnings of Backbone, Angular, and React can help in architecting Javascript applications.

Model, View, and Controller (MVC) architecture didn't originate with Backbone but was designed as a convention to separate various responsibilities as GUIs became popular. It's been around for a long time and is still in use for good reason (Django, Rails, Express). This is a great article on the subject by Martin Fowler http://martinfowler.com/eaaDev/uiArchs.html.

Same thing with Dependency Injection and Declarative Programming in Angular. http://martinfowler.com/articles/injection.html http://latentflip.com/imperative-vs-declarative/

We don't have to use the libraries but it may make sense to use the conventions in some cases.

[ascott1]

:heavy_plus_sign: :100: @sebworks (and those articles are great).

We don't have to use the libraries but it may make sense to use the conventions in some cases.

This is precisely what I'm driving at. I think doing this can make us (more or less) framework agnostic and free to choose the right tool for a project, while making sure that code is organized and reasonably easy to maintain.

[ascott1]

This front-end masters course looks like another great resource.

[mistergone]

I do like the "Model-View-Octopus" philosophy put forth in the course Adam linked. Not just because it involves an Octopus, but also because I think "Controller" is a poor word. Of course, part of that also has to do with how Controllers are defined by some frameworks, and that might relate, personally, to some specific PHP frameworks about which I am bitter.

:1234: :heavy_minus_sign: :computer: :heavy_minus_sign: :octopus:

Anyway, that approach lets us have some shared definition of "Model" and "View" without confusion over the controversial third part.

[ascott1]

I think, what I'm trying to get at is that...

1. When using a framework, we should follow the best practices and paradigms set forth by the framework.
2. When not using a framework, we should still aim to organize our JavaScript according to an existing paradigm (MVWhatever).

From what I've seen, there's a tendency to do the first, but maybe not the second. I think we can aim to do the second without being overbearing about how to structure our applications. I'd be curious what others think...

[sebworks]

I hope we are including jQuery in the architecture discussion. We shouldn't build whole our architecture around jQuery plugins.

[ascott1]

I hope we are including jQuery in the architecture discussion. We shouldn't build whole our architecture around jQuery plugins.

+1, though I don't think we're having that conversation tbh. Should we move that to it's own issue? Either here or with the Software Architecture Group?

[sebworks]

yep, I would say the Software Architecture Group.

[djdrisco]

This book is might be similar to the course , it is free (open sourced), http://addyosmani.com/resources/essentialjsdesignpatterns/book/