LebGeeks

DanyM

Member

JavaScript Client-Side Frameworks

I've been digging into various client-side JavaScript frameworks for the last months mainly: BackBone, EmberJS & AngularJS.
I came to the below conclusion, but it would be nice to see it from another perspective especially that i haven't created any major applications using any of them.

BackboneJS:
It's more like a Library than it is a framework, i didn't get the MVC part of it, it has Routers rather than controllers.
It looks good and nice until you try to create something, you'll have the feeling that it lacks a lot, you need to deal deep with its dependencies: requireJS, underscore and many more...

EmberJS:
It does offer a solution, it is an MVC framework, it's quite confusing in my opinion and it's a bit rigid such as losing so many benefits if you don't use handlebars.I didn't get to try its performance, it did a good job for a small application, however i didn't feel much comfortable in it.

AngularJS:
It also offers a full solution, it's an MVC framework, two way data binding.
It may seem scary with all those unusual terms such as: directive, factory, providers or it would take you sometime to get familiar with dependency injection if you haven't before.
However, sooner than you expect, after learning the meaning behind those terms that it's a simple and nice framework.
I don't know if it's because it shares a lot of concepts with Symfony2 PHP framework such as dependency injection, filters in Twig Template. Furthermore, it makes you feel better to know that it's supported by Google.

Again, the above is my personal brief opinion I haven't tested any of them deeply yet other than creating a small mobile application using AngularJS with Cordova / PhoneGap.

I'm looking forward to read other opinions about the above.

Cheers,

Last edited by DanyM (June 15 2013)

Kassem

Member

Re: JavaScript Client-Side Frameworks

I've tried KnockoutJS and AngularJS. I've used both in production. The former in two Single Page Applications (one of which is pretty big), and the latter in building a UI framework. Given my experience with both, I would choose AngularJS and I wouldn't even bother looking for alternatives. I strongly doubt we could've built a framework with reusable components if it weren't for angular's directives. It does have a steeper curve than that of KnockoutJS, but the benefits are definitely worth it.

rolf

Member

Re: JavaScript Client-Side Frameworks

Thanks. The good words about AngularJS are well noted, but I am quite anti-symphony, so I am not sure what to think of all that!
What is your overall impression when working with client-side JavaScript framework as opposed to server-side PHP frameworks? A good part of functionality which used to be implemented in PHP can and is (and should?) be moved to the client side.

DanyM

Member

Re: JavaScript Client-Side Frameworks

Thanks for your replies guys, i'm looking forward to reading more opinions about this topic.
I just noticed that the first post has some flaws, i didn't have the time to revise it, i was late to family dinner...

What is your overall impression when working with client-side JavaScript framework as opposed to server-side PHP frameworks?

Server side languages and frameworks have been there for ages, they have big communities and endless libraries.
PHP in particular was not a real language until it reached puberty with PHP 5+ and maturity at 5.3+, it missed so many important concepts and features, but not anymore.

Thus, every PHP framework that is not based on the new version is lacking by nature.
Symfony2 is significantly the most advanced PHP framework around and popular CMSes such as Drupal 8, phpBB4 will be using Symfony2 full stack or many of its components such as Doctrine ORM. [We can discuss it further in a separate thread].

On the other hand, JavaScript is the only client-side language in town.
Fortunately, JavaScript is a powerful language and quite fast (Thanks for the V8 engine) but very unusual for being:
Asynchronous, event-driven, and prototype-based language.

JavaScript frameworks started to shine with jQuery & MooTools back in 2005-2006 with the universal adaptation of new technologies such XHR / AJAX, JSON... then HTML5 APIs then REST-based web services started to gain ground [...] making things even more complex.
jQuery is great for DOM manipulation and does not offer a real neat solution nor structure when dealing with data CRUD and the increased client-side complexity. A pattern was needed, be it MVC or else, it was needed, badly!

And this is how BackBone, AngularJS and many JavaScript frameworks came to life recently.
Unlike server-side languages, none of the above libraries is mature enough yet, but they're certainly on the right track trying to solve the same problem. Everyone is waiting eyes open for something to excel like jQuery did in its own department.

Bottom line, when it comes to server side, many frameworks offer stable long term solutions such as Symfony2 with PHP or RoR with Ruby. This is not the case with JavaScript since none of the current available frameworks has reached puberty yet.

This is also why i opened this thread, i am also eager to find the best candidate to adopt for my company (Coddict).
There's no time and no point of creating our own framework since many are already rising.

A good part of functionality which used to be implemented in PHP can and is (and should?) be moved to the client side.

This is true, it's always better to reduce the load from your servers and server-side applications and distribute it to the client's.
such as template rendering, calculations and others especially with various APIs HTML5 offers like offline storage.

However, this depends on the type and size of the application you're creating, in this case you also need to consider a solution for SEO and avoid unnecessarily complexity, you can always use caching mechanisms and tools on the server side to achieve that such as Varnish & Memcached in certain cases.

Cheers,

Last edited by DanyM (June 15 2013)

ramiraz

Member

Re: JavaScript Client-Side Frameworks

I've used both Backbone and Ember. I agree with what you said about Backbone, it's barely 1500 lines of code and doesn't really compare to the others. Ember is what we're currently using at work, so here's my two cents:

- If you're a Rails developer, you'll love it! It promotes convention over configuration and plays nice with Active Model Serializers as a RESTful backend. Most of the founders and core team members have a strong rails background and were clearly influenced by many of its philosophies.

- It has a steep learning curve but it doesn't get much harder after that. In Angular, you can quickly learn how to make a small app but it gets harder the larger the app grows.

- Ember uses getters and setters to fire bindings and observers. For Example:

person = Ember.Object.create({
 firstName: 'John',
 lastName: 'Doe',
 fullName: function(){
  return this.get('firstName') + '  ' + this.get('lastName'); 
 }.property('firstName', 'lastName')
});
person.set('firstName', 'Jane');
console.log(person.get('fullName')); //will return Jane Doe

The above example also illustrates the concept of computed properties. Note that Angular uses dirty checking to fire bindings which has a huge performance impact on large apps.

- You need to check Ember Data! It's basically an ORM for the client and saves you a lot of time.

- One of the things that make Ember hard to learn but rewarding when understood is that it does many "magical" things for you to eliminate boilerplate. It lazily creates instances of the objects needed even if you didn't write them. For example if you have a PeopleRoute route, it automatically creates instances peopleController, peopleRoute, peopleView and assigns to it the template people.index

- The strongest feature in Ember is that it forces you to think in certain way: You start with the route (the bigger picture) and then you build the components. I find it hard to explain this but it basically makes you structure your code in the way web apps are supposed to be structured. This would make it a lot easier for you and other developers to read and understand your code.

I'm pretty sure I barely scratched the surface of what Ember can do, so I really recommend you give it an honest chance on your next project.

Last edited by ramiraz (June 17 2013)

tUrG0n

Member

Re: JavaScript Client-Side Frameworks

I started using backbone a year and half ago. Made the switch to marionette.js (Basically, its on top of backbone and removes boilerplate).
A week ago, I checked out angularjs, 4 days later, not only did I understand most of it, but I moved all of my app to it. It was THAT easy.
I found a shitload of documentation out there. There are more than one pro for angular:

1. Modular. PLEASE. This is godsend. You can just plug and play a module from github by bower installing it, then injecting it as a dependency. wow!

2. No models/collections/views whatsoever. This is awkward taken into account that its an MVC. But after fidling with it, boy I love not having to worry abwt creating a model. It just works.

3. Testable by default. Karma is such a great tool created by the angular team for automatic testing. And every single doc out there, has a test coming with it. Those guys are test heavy.

4. Bindings are magickal. I simply never ever want to write jquery without encapsulating it in a clean directive.

5. Popular like hell. Just check its repo on github. more starts, forks, issues, PR and contributors than any other framework. Forget google being behind it. There's a huge community behind it.

I plan on writing a detailed blog post about this at some point.
Now, regarding ember, I can't say anything for I never used it myself. But looking at Ramiraz's example, I can have an idea of how angular can kick ember's ass.

1. you'd 'declare' the model inside of your html as a ``ng-model`` tag, for instance 

   input(ng-model="firstName")

2. This model will be available inside of your controller. The equivalent of what Rami wrote would be:

   $scope.firstName = "John";
   $scope.firstName = "Doe";
   $scope.fullName = $scope.firstName + $scope.lastName;

Lemme take the magick further. Let's say that you have a div that contains:

<div> {{fullName}} </div>

Now, whenever you type something in the input above, that div's content will change on its own.  See this example for a live demo. Oh and, running a query/search on ur 'collection', is insanely easy! No need to use Listjs anymore!

So basically, our wrote 3 lines of code, and added one markup to your code. That's it!

As for ember-data, I'd say the competitor in angular world is Restangular which is rumored to be soon included in the angular core.

rolf

Member

Re: JavaScript Client-Side Frameworks

I'm not sure I understood your example, but would it not be equivalent to this in plain JavaScript, functionality-wise?

Somewhere in the HTML:

<input id="firstName" value="">
..
<div id="output"></div>

JS:

document.getElementById('firstName').onChange = function(e){
    document.getElementById('output').innerHtml = e.target.getAttrribute('value');
}