Aura V1 about aura HOT 53 CLOSED

I agree and love every one of the ideas listed above. I'd add that we could do a few more things:

• Rename the project to just "Aura", since backbone is not really a dependency.
• Re-structure the project (again), so we have:
  • A new extensions directory to hold Aura extensions such as backbone, requirejs, less, etc. (the list will grow quickly, I'm sure).
  • An apps directory where demo and any apps we intend to develop will live, since in really large websites you may have several different applications.
  • Have the widgets directory on the root, separate from the apps, so widgets can be easily reused by different apps.

In practice, widgets and apps have the same sort of code structure (they're all modules), so the difference is more conceptual than anything. But this separation — with widgets as small blocks of functionality, and apps as interface boxes that hold widgets together — can be really helpful when you have a seriously large system with many apps that needs to run in different devices.

• After creating all these files, we may also want the build to combine and minify widgets and apps javascript files into one file per widget/app (let's call those as modules?). Meaning that, for each module, we'd have collections+models+view (maybe + rendered/cached templates) as a single module.js file.

Although some people may want to have the entire project combined in only one file at all, I think keeping the modules separate (although with its files combined as one) would be a better approach for really big projects.

Food for thought!?

from aura.

@addyosmani

Should Aura be framework agnostic? Now that we've split up the demo into Aura, a Backbone extension and the demo I'm wondering whether we should put effort into getting Aura working with other frameworks.

Yes. Building a framework is tough but I think the more we try to get it to work with other frameworks, the better it will become. Also, helps to increase adoption.

Remove AMD dependency for Aura itself? I'm wondering whether the core Aura library (mediator, facade etc) should be offered as a non-AMD script that contains all three components that can just be dropped into a project. We can continue demonstrating the demo project with AMD but would just have Aura pulled in once rather than in three parts.

I've been thinking about how to package frameworks a lot lately. I don't think Aura will be as useful if it is just a set of AMD modules. A lot of folks still use globals, so we'd probably need to include the core modules under one object, e.g. Aura (just like Backbone), but also export a global. Problem in doing this is that you lose some of the implicit safety of only including the facade.

from aura.

@gersongoulart

• I think renaming the project to Aura makes a great deal of sense. I don't think that we'll initially demonstrate it using other frameworks, but the groundwork will be there for it to work with more than just Backbone for sure.
• I completely agree with about the extensions directory. One thing I'm less clear on is why we would have less etc in there - just dependencies? (it's been mentioned we should work with other tools, just wondering the best way to go about that). I like the idea of widgets being reusable. Perhaps we should come up with a list of widgets we should try to demonstrate with the project out of the box?
• The point about wrapping each widget/module into a single module.js file makes sense to me. I think it would be great to demonstrate both dynamic module loading as well as module loading from a compiled group of module files.

from aura.

@dustinboston I think the globals approach would work fine and we could expose the three major components through Aura.Mediator, Aura.Facade and Aura.Permissions or Aura.Core, Aura.Sandbox and Aura.Permissions. Perhaps the latter makes sense as I think people who are using the project are a little familiar of Zakas' work and these concepts.

I'm more than okay with us demonstrating the rest of the project using AMD as I would probably be using it anyway if I wanted to write an Aura application. Its just nice having a single dependency someone could drop into a project and use if they wanted to benefit from the mediator and facade etc.

from aura.

How easy should it be to switch to another framework once you've
started using e.g backbone-aura in your app?
Of course the answer is to make it as easy as possible, but how
many/what kinds of features should be abstracted through aura?
The reason you would switch to another framework, is most likely
because you'd need it's unique features.

Say you start of using backbone, and after a while you figure out that
ember.js would be a better match for your app. How would you in
reality do that switch? You'd want to use embers unique features, so
your app would of course need to know that it's actually using ember.

So I guess what I'm saying is that aura itself can be framework
agnostic, by abstracting away the most common features of the MVCish
frameworks out there, but in reality your app wouldn't.

Aura needs to provide something more than a basic regexp
search/replace would do in such a situation, otherwise abstracting
away the framework itself through aura is not really a point.

I'd love to hear your thoughts around this.

Peter

On 13. juli 2012, at 23:54, Dustin Boston
[email protected]
wrote:

@addyosmani

Should Aura be framework agnostic? Now that we've split up the demo into Aura, a Backbone extension and the demo I'm wondering whether we should put effort into getting Aura working with other frameworks.

Yes. Building a framework is tough but I think the more we try to get it to work with other frameworks, the better it will become. Also, helps to increase adoption.

Remove AMD dependency for Aura itself? I'm wondering whether the core Aura library (mediator, facade etc) should be offered as a non-AMD script that contains all three components that can just be dropped into a project. We can continue demonstrating the demo project with AMD but would just have Aura pulled in once rather than in three parts.

I've been thinking about how to package frameworks a lot lately. I don't think Aura will be as useful if it is just a set of AMD modules. A lot of folks still use globals, so we'd probably need to include the core modules under one object, e.g. Aura (just like Backbone), but also export a global. Problem in doing this is that you lose some of the implicit safety of only including the facade.

---

Reply to this email directly or view it on GitHub:
https://github.com/addyosmani/backbone-aura/issues/47#issuecomment-6976361

from aura.

@addyosmani

• I think memory management is a stretch goal. V2. IMO it needs more thought to pull it off well.
• I know I was initially in favor of including LESS, but I think it would be better to limit the scope of Aura.

from aura.

@rudolfrck I see this being something we tackle with the Aura extensions. If you want to switch from Backbone to Ember, switch the Aura extension to use the Ember one (we'd need to write this). Imo, it would be possible to demonstrate this at a basic level, but switchability is perhaps something more easy when we're talking about:

• DOM manipulation
• Storage (localStorage, sync)
• Templating

libraries. With the MVC ones you'll almost always have your widgets interacting with framework specific code and concepts and it can be difficult normalizing this behaviour. I'd almost say, we can offer Aura extensions that work with other frameworks, but encourage people try to use library switching at a lower level for utilities moreso than the MVC framework.

from aura.

@dustinboston I agree with that.

from aura.

@addyosmani Ok here's a crazy thought (I know it's a little late in the game, but better late than never).

There's obviously been a lot of work that has gone into making Aura use Zepto. To me, this is an indicator of a pain point.

I just keep wondering if there's a better way. How many of the helper methods in the mediator are actually required to make the core function? Should anything else be included as an extension? Can we remove jQuery and Underscore as dependencies altogether and simply provide extensions that have interesting combinations (like jQuery/Underscore/Backbone)? Would it be worth coding our own versions of the absolutely required core functions? Or do we get really opinionated about it and just go with one, letting others fork and add their libraries of choice?

@rudolfrck, @gersongoulart, @addyosmani - Feel free to shoot this down, it just doesn't seem like we have a really solid solution yet.

from aura.

@dustinboston Really interesting concept!

I'm still thinking about this idea and how much of it we should explore for V1.The challenge with us implementing the combinations ourselves vs. making it easy enough for others to do this without a great effort is that we could end up having to support and create combinations of quite a lot of different packages. My worry is this would mean more focus on just extensions long-term.

I'd almost rather see if we can make it as easy as possible, either through a small set of sample extensions or actual improvements to the API to help people solve these problems on their own. Perhaps we should experiment with the extensions idea further in branch and see how it goes. Maybe extensions that let you switch between jQuery/Backbone/Underscore and Lo-dash/Backbone/Zepto would be a start?

from aura.

Stretch idea (and maybe a V2 if at all useful): I'm wondering if it would help for us to have something like grunt-bbb or a brunch skeleton (basically a command-line option) for creating new Aura widgets easily.

The idea would be this would allow you to get setup with an initial boilerplate set of files and maybe even commented out code for kick-starting a new widget, communicating with modules and so on without needing to copy/clear or write from scratch yourself.

Useful at all?

from aura.

@dustinboston if you agree with the change, I'd like to rename the project Aura. The only downside is that there are a few other projects that share the same name, but nothing similar to what we do: https://www.google.co.uk/search?sugexp=chrome,mod=7&sourceid=chrome&ie=UTF-8&q=github+aura

from aura.

@addyosmani Perfect, here's a recap:

I'd almost rather see if we can make it as easy as possible, either through a small set of sample extensions or actual improvements to the API to help people solve these problems on their own.

I completely agree - I think it would be best to avoid building out lots of extensions. It definitely seems like a better option to make improvements to the API. V2

Stretch idea (and maybe a V2 if at all useful): I'm wondering if it would help for us to have something like grunt-bbb or a brunch skeleton (basically a command-line option) for creating new Aura widgets easily.

Yeah I like this idea. Maybe we could set it up in NPM? I don't have any experience with this process, though. V2

I'd like to rename the project Aura.

I think this is a great move. V1

Regarding globals:

Using Aura.Core, Aura.Sandbox and Aura.Permissions is fine. V1

BTW I love where this is headed.

from aura.

@addyosmani,
guys,

I did a re-structure of the project files following the suggestion below. I did not do a pull request yet because I'd like you to have a look on it and see how you like it. I believe this structure will make projects easier to grow and maintain. Tell me if you like it so I can do a pull:

https://github.com/gersongoulart/backbone-aura/tree/ReStructure

Cheers

from aura.

Hey @gersongoulart,

The permissions.js in src/extensions/backbone seems out of place here, it's refering to the widgets that are in src/widgets which are in turn used by src/apps/demo. Shouldn't it be in the demo folder ?

from aura.

@rumpl my friend, you're right! I think it now makes more sense to have the permissions file contained in the app folder instead.

from aura.

What about calling it aura.js?
Makes it a bit more distinct.

Peter

On 14. juli 2012, at 22:41, Addy Osmani
[email protected]
wrote:

@dustinboston if you agree with the change, I'd like to rename the project Aura. The only downside is that there are a few other projects that share the same name, but nothing similar to what we do: https://www.google.co.uk/search?sugexp=chrome,mod=7&sourceid=chrome&ie=UTF-8&q=github+aura

---

Reply to this email directly or view it on GitHub:
https://github.com/addyosmani/backbone-aura/issues/47#issuecomment-6986465

from aura.

@rudolfrck addyosmani/backbone-aura@4a233fc :)

Work is going slow, but getting there.

from aura.

@addyosmani - /me bows Wow. There's some really great stuff in there! Love it!

from aura.

@addyosmani

Great :-)
I seem to a bit out of the loop! Good work.

from aura.

Not any all. I think this was needed. Glad others agree with the general direction :)

from aura.

I have a small team building a prototype app using this project as a framework. We'd really like to have a clean way to switch out pub/sub implementations as our app is currently using PubSubJS (https://github.com/mroderick/PubSubJS). At this point we have placed this code in our extensions to facade and mediator. We have not yet reimplemented mediator.stop since we aren't unloading modules yet...but it seems that stop is coupled a bit tightly to pub/sub functionality.

Any thoughts on whether this would be a desirable feature to have in aura itself or would we be better off just sticking with our extension implementation? I was planning to work on this on DrillingInfo/backbone-aura soon and wanted to know if it seemed worthwhile.

from aura.

@clark-archer I was thinking about this the other day and I do think it makes sense for the PubSub implementation to be swappable. @gersongoulart @dustinboston what do you think about Aura just tying together a PubSub extension and a Mediator extension, which as long as they matched what was needed by the Facade could easily be configurable?

I see this as something which would be easier to do as a part of the re-write for what we have in master, but which could get trickier if we're moving towards a single Aura.js file (mostly that I don't want people to have to download the library and then provide an override).

from aura.

The only down side that I see with PubSub implementation being swappable is Aura.js having external dependencies (since we talked about making Aura independent of RequireJs and Underscore exactly to avoid this — making PubSub swappable would be going in the opposite direction).

I'll research more about the subject, but I believe that using requirejs to combine files and grunt uglify task with remove dead code flag set true should be enough to get rid of duplicated code keeping the built Aura with extension lean. In this cas it wouldn't be a problem to have the new PubSub implementation as an extension... I'll get back to it.

from aura.

Hey all,

I'm currently planning out the projects I'd like to get a V1 out the door for this quarter and it would be great if Aura could be one of them. If you're still interested in the project, or in contributing to the project, the first thing I'd like to do is finalize whether we're opting for a single-file library approach or are okay with the existing modular approach we've taken.

Basically: Do you need a single-file Aura? If yes, please justify. If no, that's great.

I'd like to begin focusing on what this project can do better and narrow it down to a list of issues that we can tackle within a few weeks so that anything offered is well documented too.

Thoughts? :)

Edit: some of the points made in this thread have thankfully already been implemented. There are however still ideas we can use beyond this and in other tickets.

from aura.

Hey all,

This is a really bad timing for me, I'm on vacation and don't have a computer around. If my vote counts I am all for a single-file Aura. Will have more time to explain starting the 20th of August.

Hope everyone is having a nice summertime.

Sent from mobile - please excuse tone and brevity

On 8 août 2012, at 01:17, Addy Osmani [email protected] wrote:

Hey all,

I'm currently planning out the projects I'd like to get a V1 out the door for this quarter and it would be great if Aura could be one of them. If you're still interested in the project, or in contributing to the project, the first thing I'd like to do is finalize whether we're opting for a single-file library approach or are okay with the existing modular approach we've taken.

Basically: Do you need a single-file Aura? If yes, please justify. If no, that's great.

I'd like to begin focusing on what this project can do better and narrow it down to a list of issues that we can tackle within a few weeks so that anything offered is well documented too.

Thoughts? :)

Addy

—
Reply to this email directly or view it on GitHub.

from aura.

Same here. I'm in Disneyland, Anaheim, CA. :)

Sent from my iPhone

On Aug 7, 2012, at 6:14 PM, Djordje Lukic [email protected] wrote:

Hey all,

This is a really bad timing for me, I'm on vacation and don't have a
computer around. If my vote counts I am all for a single-file Aura. Will
have more time to explain starting the 20th of August.

Hope everyone is having a nice summertime.

Sent from mobile - please excuse tone and brevity

On 8 août 2012, at 01:17, Addy Osmani [email protected] wrote:

Hey all,

I'm currently planning out the projects I'd like to get a V1 out the door
for this quarter and it would be great if Aura could be one of them. If
you're still interested in the project, or in contributing to the project,
the first thing I'd like to do is finalize whether we're opting for a
single-file library approach or are okay with the existing modular approach
we've taken.

Basically: Do you need a single-file Aura? If yes, please justify. If no,
that's great.

I'd like to begin focusing on what this project can do better and narrow
it down to a list of issues that we can tackle within a few weeks so that
anything offered is well documented too.

Thoughts? :)

Addy

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on
GitHubhttps://github.com/addyosmani/backbone-aura/issues/47#issuecomment-7572334.

from aura.

I prefer a modular approach as this keeps the pieces simpler. I would think that any large scale application would require a build step for assembling the JavaScript into an optimized single file anyway. I guess I'm missing what is the benefit of a single file?

-Clark

On Aug 7, 2012, at 6:17 PM, Addy Osmani <[email protected]mailto:[email protected]> wrote:

Hey all,

I'm currently planning out the projects I'd like to get a V1 out the door for this quarter and it would be great if Aura could be one of them. If you're still interested in the project, or in contributing to the project, the first thing I'd like to do is finalize whether we're opting for a single-file library approach or are okay with the existing modular approach we've taken.

Basically: Do you need a single-file Aura? If yes, please justify. If no, that's great.

I'd like to begin focusing on what this project can do better and narrow it down to a list of issues that we can tackle within a few weeks so that anything offered is well documented too.

Thoughts? :)

Addy

—
Reply to this email directly or view it on GitHubhttps://github.com/addyosmani/backbone-aura/issues/47#issuecomment-7570183.

from aura.

@addyosmani I'm still in. I'd like for us to nail down some specific items that need to be completed. I'm in favor of single file. Justification: it's easier to distribute and easier to use in a project. The other reason is that I think it will force us to focus on the very core functionality. I would really like to see pluggable architecture that doesn't require the dev to go changing dependency paths everywhere.

from aura.

Hey Guys! I'm still in as well. I got side-tracked with a couple new projects at work but should have time to work on Aura weekends. I'm also in favor of the single file. The reason is because most people would benefit from the ability of managing modules in an application of any size, regardless of working with AMD. I was following the changes in the aura-rewrite brunch and I think the aura.js file is the way to go...

from aura.

I'm in favor of the single-file approach.
I'll try to use it in my latest project and see how it goes!

from aura.

Today I learned that apparently Aura is now the most popular architecture to work with on top of Backbone (ahead of Marionette and a number of similar projects). This is quite interesting because we're very much still in beta. With that in mind, I would love for us to go full steam ahead with the aura-rewrite branch.

From the looks of it, whilst I currently feel like a modular approach to the library via AMD would be better, as the rest of the team seem to strongly prefer the direction of single-file, let's go with that. I'm sure I can be convinced of its merits ;)

I think we all agree that we still want a level of modularity, however I believe this can be easily achieved just using the build process properly. Similar to the way projects like jQuery have multiple modules they compile into a single file, we can do the same.

The next question I have is how we should structure the project around a single file. I'm very open to ideas here. We want:

• a base library of some sort that can help us glue everything together
• the ability to easily swap out implementations for other libraries
• one thing I like about our current approach is that its easy to see where I'd drop zepto for jQuery or replace say, the mediator with something else. I'd like for us to continue being able to do something similar.

So, out of the box aura.js in distributed form can either be a single compiled file which contains the mediator implementation, the facade (do people need to be able to replace this implementation? its really just API glue) and the permissions, which are really just config.

We have a dependency on there being some sort of DOM manipulation library available, similar to Backbone. We should make it clear how to easily swap whatever we include by default with our downloads out for something else.

Other ideas?

from aura.

I'm against the single-file approach:
In my opinion the idea behind Aura is/was to implement a (large scale) javascript application architecture with decoupled, reusable, AMD modules. So why should someone pull Aura in for a non-AMD environment? Aura is not a pub/sub or DOM lib nor MV*.
I can see some points of @dustinboston's argumentation: It will be easier to distribute und use in a project. But shouldn't developers on this level know the idea behind AMD and why there are more than one files and how to pull those in?
I would also prefer focusing on 3 or more small and looser coupled files rather than on one huge thightly coupled file which is much more complex to understand, maintain and extend.

Anyway, it doesn't matter how Aura will continue - it's a great project and I would like to help making it even better.

from aura.

I agree that someone pulling in Aura will likely use it in an AMD environment. If you're not, I think you'd be missing out on part of what makes the architecture nice to work with. If we're going with single-file, the way I see it working is having a base library with loosely coupled extensions forming the other parts of the architecture. I really don't want to end up with one huge monolithic library file. It wouldn't be very maintainable :)

from aura.

Pulled in the questions from issue #62:

Make Aura's templating, pub/sub, MVC, base lib switchable is no problem if it happens before widgets are created based on these libs. After is much harder. Which of these components do you want to have switchable before/after?

from aura.

There is definitely a point where as much as we abstract its not going to be enough, but the idea is that where possible, a widget is defined with references to our facade APIs in such a way that we can change say, the templating, the DOM manipulation and the utility libraries without much effort. I think, although we try to do this with Backbone and MVC frameworks, its impossible to abstract them all out in such a way that its likely you're going to change your MVC lib later on. We just make it a little easier and I'm okay with that.

So to answer your question:

• DOM manip library
• Templating
• Other utilities (e.g pub/sub etc)

from aura.

That makes sense to me.

from aura.

Today I learned that apparently Aura is now the most popular architecture to work with on top of Backbone (ahead of Marionette and a number of similar projects). This is quite interesting because we're very much still in beta.

That's awesome!

The next question I have is how we should structure the project around a single file. I'm very open to ideas here. We want:

If we do this right there should be no reason that mvc, dom, templating, ajax, pub/sub, even the loader (require, almond, etc) are all replaceable.

With that said... @addyosmani Something finished is better than perpetual beta. I say we go with your gut, and I'll back it up. It's got us this far. :-)

from aura.

@dustinboston Well it depends. You can replace everything - of course - but when you allready have module/widget code relying on the facade api it won't be possible if you don't abstract those components in the mediator/facade. Also, it's no benefit of the single file approach: In AMD all components are replaceable too.

from aura.

I've been working with Aura since the first preview and been following the development close. The end product is a webapplication that serves on-demand music, movies and television.
The Aura project caught my attention with the load/unload isolated widgets/components and it was nice to see a working example of the mediator and facade pattern written by one who talks a lot about it.

Regarding performance i'm still not convinced that a small payload plus more server request is better/faster than a single payload - and what about disposing widgets in IE8 etc? How large should a "large-scale-application" have to be before it benefits from this? More statistics would be nice - maybe the options to choose?

Reading the latest post, I beleive that this project wants to many things. In my opinion the focus should be put on the mediator, file stucture, cli tools and grunt for distribution - plus some great examples for easy deployment.

A couple of examples:
Facade:

• Keep it small and simple - it is mostly just glue :-)

Mediator:

• Focus on starting/stopping widgets.
• Memory use when getting rid of widgets (extensive testing in ie8+, chrome, firefox).
• Creating widget unload helpers (mediator.publish('unload', 'widget') etc.)

Grunt:

• App gets packed into a single file.
• Widgets gets packed into single files.
• Option to choose.

Commandline tools:

• Create parts of a/a complete widget skeleton.

Just my thoughts and i'm absolutely positive about Aura - I would love to help and contribute more code to the project.

from aura.

@henrikkok Thanks for trying it out and for the great comments.
@ndersh Agreed, I tend lose my pragmatism in favor of theoretical ideals sometimes. You and @addyosmani keep my head on my shoulders ;-)

from aura.

@henrikkok Thanks for the invaluable feedback. It's always useful to get input from someone who's been actively using the project. On your comments:

• Payloads: In GMail and apps such as Google Docs, we almost always prefer a single initial payload (or bootstrap) with the features most users are going to use, using dynamic loading for those that a small population may end up opting for. In Aura, I guess this is something we could help with using clearer r.js build profiles as there are a number of options possible for whether you want to include all scripts or simply those not requiring dynamic loading.
• Focus: I think you make a good point with respect to the project goals. We definitely need to get more focused and your suggestions certainly cover many of the areas I'd like for us to work more on.
• Facade: agree. Is there anything specific about the current implementation you feel could be made more simple?
• Mediator: I really want us to improve our memory management. We had more tickets in to do with this and how we handle the destruction/unbinding of event handlers than anything else. We do of course currently have start/stop/unload features, but they should be improved.
• Grunt: When you say option to choose, could you expand on what you mean here?
• Command-line tools: I'm currently working on http://yeoman.io, which we hope to launch in the next few weeks. Once it's out, we'll switch Aura over to using it (it's built on top of grunt) and we can write a scaffold/skeleton generator with it that achieves what you were after.

Out of curiosity, what are your thoughts on the single-file/multi-file discussion? Do you think it makes a difference?

The reason I'm pushing for a consensus on it is so we can get any architecture work needed for it out of the way in order to complete improvements on the features you listed.

All: To be honest, if we're to get out a solid V1, maybe we should concentrate on improving our existing features with the current architecture and say that we'll attempt to do single-file in V2. This would give us the chance to:

• Clean-up the unit tests which I think @joelhooks will be able to assist with greatly
• Really work on improving our memory issues surrounding stop/start/unload
• Make it dead simple to swap out utility implementations being used
• Establish if there are other small or free wins we can get before launching a solid V1

If you can think about the types of architecture issues you regularly run into and feel might fit in well with what Aura is trying to achieve, we could certainly review those.

@dustinboston etc. thoughts on holding off the single file for V2?

from aura.

@addyosmani

• Payloads: I like the multi-file solution and it makes sense in my opinion. Roundtrips are expensive! But I don't like sending 80 widgets upfront in one file - most users will never use all of them. It is difficult to investigate and debug memory consumption - more data on this subject would be great!
• Facade: I only find it odd to include jQueryUI here (it is also mentioned in the comments), we had to include a couple of jQuery plugins here as well.
• Grunt: the option to those between single-file/multiple files.
• Commandline tool/Yeoman: Been waiting for Yeoman since Google I/O - so that sounds perfect :-)

General issues:
Not being able to reuse code from other widgets. It is fixable with some simple low-level solutions like symlinks. I ended up with a very simple requirejs plugin called "shared" - r.js will include the shared ressource in the widget when it compiles. It would be great with a better solution - maybe a more intelligent mediator.unload solution.

from aura.

@addyosmani I agree leaving the single-file discussion for a V2 toatlly makes sense. Let's work to get a final V1 that delivers what we need the most...

from aura.

@gersongoulart sounds good to me!

@henrikkok I completely agree on a smarter unload solution and I'm working on what we can do to handle this in #35 if you're interested in getting in on the discussion :) Basically, there are two problems I see with the 0.8 version of the implementation:

1. it didn't properly handle event unbinding of descendants, which I believe is fixed now

2. undef(), event with my modifications to improve it is actually still quite limited. We don't do any analysis to see if other modules have modules being unloaded as a dependency. The issue here is that undef() won't actually do anything in this situation, whilst we might want to do some further dependency chain analysis, unload anything with a dependency also being unloaded and so on. This requires more thought.

from aura.

@addyosmani Yeah lets hold off on the single file and focus our efforts on getting V1 finished.

from aura.

Back from vacation and I'm ready for action. I'm also not in favor of going the single file route ( at least not in V1). I can't see benefit of it.

from aura.

Glad to see we're in agreement about holding off on major architectural rewrites until V2 :)

@robertd would love to get your thoughts on #22 and whether there are any changes you think we should consider to make unit testing easier. At the moment @joelhooks is running into some trouble with multiple instances of the mediator and shared state as a result of this.

from aura.

I'm currently in the design phase for building a chat app for a client and was inclined to go with Marionette because I really like it. But after going through all the issues and comments here on Github Aura is shaping to be a better solution in the long run.

Which brings me to my actual question: should I invest my time on learning Aura now and use it for this project or stick with Marionette and have a go with it when V1 is released? Am I expected to do some major refactors between 0.8 and 1.0 ?

from aura.

@datiecher So that we're not biased, what drew you to Marionette and is there something particular you liked about the direction we're taking in Aura that makes you feel it would be a better choice? :)

In terms of how our API/the project might change between 0.8 and 1.0, there's only one major change we're considering at the moment (#22) but much of the rest of our tweaks should occur silently behind the API without breaking anything.

from aura.

@addyosmani first of all, Marionette is a great piece of software and I use it since its 0.4 version, but keeping with the changes between releases was really a pain point for me. Another issue I have is that even though the momentum around it was built, it still is mostly maintained by Derick and the changes and feature additions he implements are not always discussed with the community.

Aura on the other hand has involved the community in the development and review process since the beginning, which can slow the pace of development, but really helps you seing the big picture and stress the limits of your architecture and proposed solution. It's a more open and inviting way of doing Open Source.

Your concern in creating easy entry points in the API for swapping libs is another strong point for Aura, the JS ecosystem is big and diverse and being opinionated is not always the best choice IMHO.

Aura's sandbox model, permission layer and the use of AMD modules are other nice features to have when you are working with more involving web apps, as well.

Oh, and the effort you guys put towards documentation is something to brag about. Specially you Andy, you fucking documentation maniac! Always wanting to share the knowledge with other devs. =)
Not everyone on my team for example like to thinker with the source code the learn how to do things, so great documentation is a must have.

But the biggest thing for me is really the great response you had from the Backbone community, which can make or break projects like Aura. Building awareness for your project is not an easy thing to do, but with such kick ass core devs, I can't really see you not being able to exceed my expectations. ;)

I guess that's about it. Sorry for the not so well written response as I was kinda just dumping some thoughts I had in favor of Aura while enjoying a nice cup of tea.

from aura.

@datiecher I can't really speak to Marionette because I haven't used it, but I wanted to say thank you for your kind words.

from aura.

As we're solving many of these issues with the work being done in master, closing for now.

from aura.