I'm confused by the "componentization" of the web UI. If I have a need for a component, should I write my own jquery-ui plugin or should I write, if I use Backbone.Marionette, a MarionetteComponent ?
Both are be reusable, isolated unit of view and behaviour. So they are conceptually fighting and compete at same level.
So I don't actually see when to create one or the other. jQuery seems to be more universal, but developers tends to write MarionetteViews/Component.
If you want to use your ui component in most possible situations you could do your component without coupling with neither jquery-ui or backbone view.
If you want to make your component more future proof (yes I'm a dreamer) you can do it generic, and you can try to implement it with AMD, CommonJS or ES6 Module syntax. check for example https://medium.com/#brianleroux/es6-modules-amd-and-commonjs-c1acefbe6fc0
The advantage of this is that anyone can use it with React, Angular, [put here other future framework] or vanilla JS.
And if you want to make easier for others to implement, you can add as well the code that wraps your component to integrate with those frameworks, libraries, etc.
I am not very familiar with Backbone but as I remember this is architectural framework which should give you guidelines how to structure your code into views, controllers, components and other useful services.
On the other side there is jquery library which main purpose is to abstract the operations on the DOM so that the browser specifics can be hidden and easier interface is provided. Of course jquery has a lot more useful primitives but it doesn't say how to structure your code.
If you have decided to use Backbone you should write your components as MarioneteComponents so that they fit nicely into Backbone. Even if you write it as jquery component (or you need to use already existing component) you can create wrapper for Backbone but this is additional work.
If you want to make truly reusable component you should write it using vanilla js. After that everyone can make wrapper which will adapt it for the specific framework.
Hope this helps.
I was full time java developers, now I also work on JavaScript. couple of years back when I started learning JavaScript, first library I tried was jquery like most of the people. But it made my life harder, and after sometime I started writing fairly large JavaScript app. It wasn't coming together for me using jquery. I had huge codebase without much of a structure. It was method blocks updating HTML blocks using selectors.
Then I tried mootools and obliviously as a java developer it appealed to me a lot. And I was able to write managible web apps having huge code base.
As per my understanding Mootools is not considered a preferred way to write JavaScript because it mimic conventional OO over default prototype-based OO language. So now to really understand javascript and desire of walking with the world, i decided to try other approaches, so again I turned back to jquery, and realise that only jquery is not enough. So started looking at current trending frameworks like backbone, spine, ember.js, sprouteCore. Strangly I found that these frameworks at their core tries to mimic conventional OO like mootools only by having constructors and creating a object of class and reusing this class object to create instance objects. So
Am I missing something?
Is mootools way really wrong?
Mootools project is very alive and releases new versions/features, but I don't
see many people talking about it on Internet, also there are no comparisions vs backbone/spine etc.
As per my understanding Mootools is not considered a preferred way to write JavaScript because it mimic conventional OO over default prototype-based OO language.
Where do you get that from? The greatest thing about javascript is that is so loosely typed (see what I did there) - you can write the same thing in a platitude of ways. There are also so many ways to abstract it and repackage it - and this applies from a simple new Array() vs [] to how you structure your app.
If you love JavaScript (or just know it and secretly hate it), you will be fine with MooTools. The API is mostly either native js or ES5 spec or - rarely - an extra utility that also feels 'natural'. The notable exception that stands out is Class. And the fact that you can abstract having to deal with prototypical inheritance by passing an object to a special constructor Type function that returns your instance is ... oh wait. It looks different but what it does pretty much sounds like normal javascript. Only easier -- why wouldn't you prefer that?
A lot is being made these days of the clientside MVC boom and this 'new way of developing apps'. Suddenly, jQuery folks were given the luxury of tap water! I have spoken to a lot of MooTools developers over this and (un)surprisingly discovered that most think MooTools rarely needs anything like that. I tend to agree with them. The only gaping hole is a view controller with templating but there are a fair few solutions.
The thing is, you cannot directly compare a MVC framework with MooTools, it is not the same. At all. You can compare the so called Model constructors vs Classes.
I have now spent a while researching various MVC framework solutions and patterns to see if our new app can be moulded into a 'best practice' shape.
Basically, I tried backbone.js (with and w/o a mootools adapter) and found it awkward to use after MooTools - it felt like a step back. When I say use I don't mean I can't use it but it feels awkward to extend and build on. I am sure it's just down to experience, though, have yet to read all the backbone patterns examples out there.
Typical issue I run into - wanted to have a special Model property that tells it to use localStorage to fetch/save. Not obvious how - examples tend to show you can either route Backbone.sync to one or the other but not both at the same time. I had to actually decorate the function and extend it, keeping the original referenced in case the model did not require localStorage. NOT the best / most obvious pattern to maintain and leaves me dependent on their changes not breaking my code.
In MooTools, I would have just extended my Model class and could have defined a custom Class Mutator property (like Binds or Implements). Done. Write what you know, they say, and not for nothing...
Another issue - it's tightly coupled with data and you cannot reuse models like classes - eg, a User model loads a user and renders through a User Edit view. You then want to create a new customer and suddenly, you cannot reuse the old object that easily and just render the same view but with empty values. I think it will also be down to inexperience on my part or bad architecture.
Ember.js I found slightly more moo-ish as an interface though It did not quite click either. Frankly, backbone was less trouble to setup.
There are other attempts. Composer is one - once again for mootools but it tries too hard to be backbone and is written by people that are relatively new to the framework so I would not call it mature. Knockout etc etc. There's a new one every day, literally.
Garrick Cheung released a framework called Neuro which has huge potential.
I wrote Epitome - a full MVP implementation based upon classes and events and wrapped in AMD modules, feel free to check it out. It also comes with a builder, documentation builder and many little goodies to get you started.
SeanMonstar released Shipyard, which is used by Mozilla Flight Deck - http://seanmonstar.github.com/Shipyard/. Whereas it's not native mootools, it's mootools-ish with mootools class etc - only w/o extending natives, so a great alternative.
BTW, try irc.freenode.net #mootools or the mail list and you will always get a good answer.
Anyway, enough on MVC. The points about MooTools have been made countless of times. Haters will be haters. Those that love it don't look back. If you are a programmer from an OOP background or are looking for something that renders itself well to patterns, do yourself a favour and stick with it. Exciting times are ahead. Roadmap for 1.5: AMD, for 2.0 (aka, Prime) Host object prototyping optional. These have been the two biggest talking-down points in the eyes of critics. No more 'dirty' prototypes so people can get on with using for ... in loops incorrectly on non-objects and without hasOwnProperty checks. Anyway...
Other things to worry about may be of importance. Like, the size of the 'community'. I think having a healthy community is a great thing but even if you look at jquery, the amount of actual contributors vs users is low. The ratio of quality CODE vs good looking effects is bad. The plugins you can use - a lot are not well written or dead and unsupported. When you draw the line, it's a lot less glamorous than you'd think!
I am not saying that mootools or other frameworks don't have these problems. It is fair to say MooTools people and especially the core devs are fairly private and less vocal about what they do. It may send the wrong impressions, I don't know. It certainly is no jQuery.
Ultimately - if you have the resources and the know-how, use what works best and what will scale. There are even these that use coffeescript and swear by it. Who am I to judge...
In the interests of full disclosure - you will find it MUCH harder to find a decent mootools dev when you recruit. Cannot be ignored...
So I have a problem with my jquery applications entirely. When the application is small it's cool. But when it is quite large it is such a mess.. Nested functions, ajax calls, selectors, dom manipulations. Seems like it's non-containable at all, especially when it has a complex logic.
The functional approach does not help me out much. And I don't see how to use classes and inheritance here in practice. How to organize the code? I have read a lot of articles about prototypical and pseudo classical inheritance but they just explain how things works, like how you can inherit 'Person' from 'Human' or something like this. How can I actually use it in real life?
I find two things that really help organize javascript. One use objects for encapsulation ( http://www.dustindiaz.com/namespace-your-javascript ), and two, write a library for common tasks. The normal refactoring strategies work for javascript, extract functions, commonize, if you have 4 functions doing nearly the same thing, change them to a single function which can handle all four cases.
When planning a large jQuery application that I'm currently working on, I found this post by Addy Osmani very useful.
Full disclosure, though: we ended up hanging most of our application backbone off of a YUI3 core. All our "controller" code is written in jQuery, but the frontend data model is YUI3.
Compared with Java/C#/C/C++ projects, we often see web frontend projects (html/css/javascript) are too complex to read and maintain. So, can we summarize some best practices for web frontend projects? The goal is readability, modularization, easy to maintain.
Accomplishing this takes a mix of good patterns and knowing what fights not to fight.
CSS is best if it's factored out, efficient, and cleanly formatted. No overthinking necessary here, CSS is a beautiful language, I like to keep it simple. For example see my answer here: MVC 3, CSS, Razor and Visual Studio 2010
Javascript can definitely be organized by using some kind of object based pattern: http://www.klauskomenda.com/code/javascript-programming-patterns/. I use something close to "Custom Objects" from that link. With YUI we have built in namespaces, with jQuery we can add them: Is it possible to create a namespace in jQuery?. As far as separating out content, separate objects and related functionality in their own javascript files and include them on the pages where they're needed. For optimization, you can compile all the scripts on any page down into one script. YUI 3 has a great dependency loading mechanism - use that. For jQuery, you can use one of the many dependency loaders: Javascript loaders with jQuery
As far as HTML, I think MVC is the most popular patter these days. Using any modern mvc framework will lay things out for you well. (Ex. rails, any java ones, asp.net mvc, pylons, etc.)
Well, for now, web development has many approaches and there's no standard way of doing things.
By the way, since JavaScript doesn't support some OOP features like actual classes or namespacing, but prototyping, you need to know that this isn't a good start for crearting good and large moduralized front-end Web projects.
Although there're limitations, you can use prototyping in order to leverage some kind of pseudo-OOP design. That's you can create a component-oriented user interface based on inheritance of some abstract hierarchy defining common behaviors and visualizations.
Keeping in mind one of most important points in any modern development is reuse and scalability, I think using pseudo-OOP with prototyping should be fine to avoid bad practices and enforce maintainibility, readability and moduralization.
For example, you can simulate namespacing with prototypes. This is achieved by creating anonymous objects where their members are anonymous functions acting as getters (properties) where their return type is the prototype of some actual "class" - there're other ways to achieve this same result -:
http://www.codeproject.com/KB/scripting/jsnamespaces.aspx
Or you can simulate polymorphism:
http://www.codeproject.com/KB/scripting/edujini_007_JavaScript_OO.aspx
I could add more references, but I believe you got it: it's more like trying to export actual OOP approaches to JavaScript and use same design patterns that have been in the ground for a lot of years!
Another point should be you can get this moduralization by extending existing JavaScript frameworks like jQuery, Prototype, MooTools, Microsoft AJAX (this is a good start because it has many built-in OOP features like namespaces, inheritance, polymorphism...).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Are there any client-side JavaScript MVC (micro-)frameworks?
I have a rather complicated HTML form, and it would benefit from the MVC pattern.
I imagine a good solution would provide the following:
Model and View update the Controller when values change (Observer pattern)
Populate the model from the form data when the page loads
Populate the form from the model when the model changes
Ajax, comet, JSONP and all that jazz are serious overkill.
Backbone is a great light-weight framework. Give it a try:
http://backbonejs.org/
JavaScriptMVC is an excellent solution. It's everything is a plugin approach enables you to select only the features you need. As of 2.0, it's based on jQuery.
On progressively enhancing your website, that's left up to the user as JMVC provides just a middle layer for development - it's up to you to make that design choice yourself.
However, JavaScriptMVC is simply the best general purpose JavaScriptMVC library because of its powerful event delegation based controllers.
Event delegation lets you escape having to attach event handlers, and simply create rules for your page.
Finally, JMVC is much more than a MVC architecture. It has all parts of the development cycle covered with:
Code Generators
Selenium and Env.js integrated testing
Documentation Engine
Automatic Concat+Compress
Error detection and reporting
Spine has an API similar to Backbone but it's a lot smaller. It features prototypal inheritance.
AngularJS works well together with jQuery and will help you a lot with MVC structure and strict separation of concerns.
Full testing environment and Dependency Injection included...
Check it out at http://angularjs.org
Indeed there is: http://www.javascriptmvc.com/
I think you will find this sufficient!
I think this one looks like something you should check out: http://knockoutjs.com/
(As a silverlight / wpf programmer this was the library that made me finally start learning javascript. It is based on the Model-View-View-Model (MVVM) pattern, as for me right now seems like a good choise!)
Ember.js
These are the three features that make Ember a joy to use:
Bindings
Computed properties
Auto-updating templates
Bindings
Use bindings to keep properties between two different objects in sync. You just declare a binding once, and Ember will make sure changes get propagated in either direction.
Here's how you create a binding between two objects:
MyApp.president = Ember.Object.create({
name: "Barack Obama"
});
MyApp.country = Ember.Object.create({
// Ending a property with 'Binding' tells Ember to
// create a binding to the presidentName property.
presidentNameBinding: 'MyApp.president.name'
});
MyApp.country.get('presidentName');
// "Barack Obama"
Bindings allow you to architect your application using the MVC (Model-View-Controller) pattern, then rest easy knowing that data will always flow correctly from layer to layer.
Computed Properties
Computed properties allow you to treat a function like a property.
Computed properties are useful because they can work with bindings, just like any other property.
Auto-updating Templates
Ember uses Handlebars, a semantic templating library. To take data from your JavaScript application and put it into the DOM, create a tag and put it into your HTML, wherever you'd like the value to appear:
<script type="text/x-handlebars">
The President of the United States is {{MyApp.president.fullName}}.
</script>
Stapes.js
Full disclosure: i'm the author of this library :)
If you're looking for something really tiny (1.5kb minified / gzipped) have a look, and tell me if you like it.
There is the popular Backbone.js
If your requirements are really simple, you could write your own simple MVC like Alex Netkachov did.
His examples are built on dojo (Note: they don't work for me on his page because of a missing dojo.js file), but you could follow the pattern in plain Javascript.
It's probably overkill for what you need, but SproutCore is an MVC framework, and it doesn't look any more heavyweight than JavaScriptMVC or TrimPath's Junction.
Unfortunately, none of these seem to be built on the principle of progressive enhancement.
The popular ActionScript MVC framework PureMVC was recently ported to JavaScript. I haven't had a chance to try it out yet, but I am confident it's good.
UPDATE 2016: Sammy.js seems to be abandoned.
Have a look at Sammy.js
Text from the site:
A small webframework with class.
SMALL Sammy's core is only 16K compressed and 5.2K compressed and gzipped
MODULAR Sammy is built on a system of plugins and adapters . Only include the code you need. It's also easy to extract your own code into reusable plugins.
CLEAN The entire API was designed to be easy to understand and read. Sammy tries to encourage good encapsulation and application design.
FUN What's the real point of development if its not enjoyable. Sammy tries to follow the MATZ approach. It is optimized for developer happiness.
Please also checkout jquery-claypool.
jquery-claypool is a small, fast, railable mvc framework built on jquery, based on my experience with django, rails, spring etc. Its very light weight and runs on both on the client and in server environments.
it provides a routing framework for clean mvc, category logging, filters (aop), lazy creation of controllers, inversion of control, convention-over-configuration and not much more by design.
it doesn't do anything jquery already does, feels like jquery, and works like a good framework should: simply.
jquery-claypool
Hope you check it out.
Jamal is the lightweightest I've seen. It's also based on jQuery (bonus). Have not used.
http://jamal-mvc.com/
If you want to keep things under control and quite simple, you may don't need a framework, but just implement your own mvc pattern.
Just check this article: Model-View-Controller (MVC) with JavaScript by Alex Netkachov on 2006.
Here is a list of all open-source JavaScript Frameworks known to mankind.
http://getopensource.info/explore/javascript/framework/
Or only MVC frameworks
http://getopensource.info/explore/javascript/mvc/
Disclosure: I'm the developer of this website.
Try kitty. It is only 1.4KB and its only dependency is EJS.
I wouldn't call this a micro-framework, but it sure looks interesting: Cappuccino Web Framework
CorMVC, easy to understand and to start with, jquery based and does not depend on any server technology
I have developed a very simple Javascript MVC framework called MCV. It does not do exactly what you ask for, but it is easily extensible with helpers. Anyway, it is definitely micro (1,9kb packed).
It works more or less like Jamal, but I decided to roll my own for two reasons:
remove the jQuery dependency (although I use it together with jQuery most of the time)
making it extensible with helpers. These are analog to CakePHP behaviors, components and helpers.
Just to make the list a little more complete:
ActiveJS
I upvoted the AngularJS (full disclosure, I'm involved in a limited way with the angular dev effort) and am very excited about it. I did a side-by-side comparison taking one feature for an internal project (sorry don't have signoff to share it) and implementing it in both AngularJS and Backbone. It was a great exercise and in the end, I'm very much leaning towards Angular. The core developers are great about answering questions and they've done a really nice job with builtin databinding, unit/e2e testing and documentation. Its still in beta with 1.0 coming out in near future. The beta is very stable.
There is a bit of a paradigm shift, and they use a fairly different approach than most. Integrating your favorite jquery plugins takes a bit of effort but is doable and has been done (angular-contrib on github).
I will say (and this is a problem for most js-centric frameworks), make sure to investigate how to make your content SEO-friendly (if its important to you). Since joining the angular community in June, I've noticed the interest is growing and a number of people are making posts saying that they've looked at Backbone and others but really like what they are seeing in Angular.
Maverick is a small JavaScript MVC framework — http://maverick.round.ee
I'm going to pipe up here too - AFrameJS works with jQuery, MooTools and Prototype.
Another one: MooTools-MVC
There was a key-value binding JavaScript framework called "Coherent", which was inspired by Apple's Cocoa Bindings. The framework has been bought by Apple, but there is still an old copy at http://github.com/trek/coherentjs/tree/master.
Try this jQuery based javascript MVC framework.
One more, lightweight and tiny: http://jqnano.oleksiy.pro/
Can.js has everything you need and weighs in at just 8 KB. It's taken the best bits from JavaScriptMVC and distilled it into one small, yet kickass framework with observers, widgets, binding, the works. It is compatible with major frameworks (jQuery, Dojo Toolkit, MooTools, etc.). Documentation is excellent and authors are responsive. It is definitely worth a look.