2

So I'm afraid I might be missing something pretty fundamental here, but I really can't get my head around this - Why? Why would we want to use those JS MVC frameworks, instead of sticking with Rails, Django, PHP and so on?

What do these JS frameworks give us that can't be achieved by the old web frameworks? I read about SPA, and there's nothing I couldn't do there with ASP.NET MVC, right?

I'm really baffled by hearing all the people at work wanting to leave our current framework for these new ones, and it's much more than just for the sake of learning something new. I am totally up for that, and I've always tried playing around with other frameworks to see what I'm missing, but perhaps these new technologies have something really big to offer that I simply cannot see?

thomas
  • 1,133
  • 1
  • 12
  • 31
  • 1
    You'd generally use both a server side and client side framework. They serve different purposes and are not replacements for one another. – zzzzBov Apr 18 '14 at 22:15

4 Answers4

3

Single page applications provide a better experience by having all page transitions be seamless. This means you never see the "page flash" between user actions, in addition to a few other user experience improvements.

Front-end frameworks also generally provide a common way to interface with APIs. So instead of writing an AJAX wrapper for every page in your site, you just say 'This page has this route (path), hooks data with this schema from that API endpoint and presents it with these templates and helpers.' There are many proponents of APIs, because there are many good reason to write you applications from a service standpoint. This talk sums up a lot of the points in favor of APIs. To summarize:

  • Orchestrating your web offerings as services makes them inherently decoupled. This means they are easily changed out. All the reasons behind strong Object Oriented design principles apply equally to the larger parts of an application. Treat each piece as an independent part, like a car, and the whole platform is more robust and healthy. That way, a defect in the headlights doesn't cause the motor to blow up.

    This is very similar to how a SOAP WSDL works, except you have the auto creation tools right out of the box.

  • Having well defined touch points for each part of your application makes it easier for others to interface with. This may not ever factor into your specific business, but a number of very successful web companies (Google/Yahoo, Amazon AWS) have created very lucrative markets on this principle. In this way, you can have multiple products supported by the same touch points, which cuts a lot of the work out of product development.

  • As other point out, the front end framework is not a replacement for the backend, server technologies. How could it be? While this may seem like a hindrance ("Great, now we have two products to support!"), it is actually a great boon. Now your front and back ends can be changed and version with much less concern over inadvertently breaking one or the other. As long as you stick to the contract, things will "Just WorkTM".

    To answer your additional question in the comment, that is exactly correct. You use a front end framework for handling all the customer interaction and a completely separate back-end technology stack to support it.

I'm forgetting a few good ones...

Community
  • 1
  • 1
Patrick M
  • 10,547
  • 9
  • 68
  • 101
  • So this isn't something that would be used standalone? It is only combined with a server side framework such as rails, django, node, and simply makes separating the model from the view easier and more correct? – thomas Apr 18 '14 at 22:40
3

Angular, Ember, and Backbone are client-side JavaScript frameworks. They could be used interchangeably with a Rails, Django, or PHP backend. These JavaScript MVCs are only responsible for organizing JavaScript code in the browser and don't really care how their data is handled or persisted server-side.

Jake McGuire
  • 304
  • 2
  • 4
  • But this is what I cannot grasp - I can get the client side done with my django templates, I still have my JS code there and can do pretty much everything I want. What is the merit of using another JS framework for my client side? – thomas Apr 18 '14 at 22:29
  • 1
    @PatrickM's answer above is excellent on this point. The page flashing when you have to load each page separately creates a janky user experience when you could seamlessly request new information through AJAX and put it into the DOM without the user ever having to request a new page and wait for it to render. And more than that, why waste your precious server resources rendering HTML and JS when you can delegate it to your users' computers? My MacBook Pro is way more powerful than the EC2 server instance that runs my AWS-hosted website, for example. – Jake McGuire Apr 18 '14 at 22:41
3

Django/Rails etc are server-side MVC frameworks. Angular/Backbone etc are client-side Javascript MVC frameworks. Django/Rails and Angular/Backbone work together - in a single-page app, usually the server-side MVC will serve the initial HTML/JS/static assets once, and then once that is done, the client-side router will take over and handle all subsequent navigations/interactions with your app.

The difference here lies in the concept of what a "single-page application" is. Think about how a "regular" web Django/Rails website works. A user enters your app, the backend fetches data and serves a page. A user clicks on a link, which triggers the server to serve a new page, which causes the entire page to reload. These traditional types of websites are basically stateless, except for things like cookies/sessions etc.

In contrast, a single-page application is a stateful Javascript application that runs in the browser and appears to act like a traditional webapp in that you can click on things and navigate around as usual, but the page never reloads, instead, specific DOM nodes have their contents refreshed according to the logic of your application. To achieve a pure Javascript client-side experience like this in a maintainable fashion really requires that you start organizing your Javascript code for the same reasons you do on the server - you have a router which takes a URL path and interacts with a controller that often contains the logic for showing/hiding views for a particular URL, you have a model which encapsulates your data (think of a model as roughly one "row" of a database result) which your views consume. And because it's Javascript there are events going on, so you can have your view listen for changes in it's associated model and automatically re-render itself when the data is updated.

Also keep in mind that you don't just have one view on the client side, there are usually many separate views that make up a page and these views are often nested, not only for organizational purposes but because we want the ability to only refresh the parts of the UI that need to be refreshed.

The intro to Backbone is probably a good starter on the topic: http://backbonejs.org/#introduction

kasceled
  • 548
  • 1
  • 6
  • 18
0

Check this article, there is well explained how a modern web application should looks like in the client side, server side and the communication between them.

By the way:

Client side -> Ember, Angular, Backbone, Knockout.

Server side -> Django, Node, Rails

jFranciscov
  • 73
  • 1
  • 1
  • 7