Angular is an MV* javascript SPA framework... bla bla... you might have heard it a thousand times already. Me too!
Forgot : Lengthier post alert! Today its not a coffee chat. Its a Friday night & for a change, I was having beer with my buddies. And once am drunk, i talk a lot. About anything and everything under the sun..you get that?
Someone told Angular is great. There are a lot of companies hiring Angular resources.So does that mean you should use it in your next project? Does it provide a silver bullet which smashes every single problem? Is it a spiderman who comes around and saves the day of innocent people? ( webbies in this context ? )
Million dollar question : I am a beginner intermediate JavaScript - jQuery developer. Will i be able to grasp the angular concepts which requires heavy object oriented knowledge and understanding? Not really. Though if you are good at it, it helps a lot and you will scale up quickly and you will mug up less.The answer is, if i can, you definitely can..I am not an expert..more of an enthusiast who goes and gets anything which i am interested in.. To enjoy a cup of tea, one just need to know how to mix the tea dust, milk and sugar in the right proportions. We dont need to know how sugar is made or how tea leaves are being processed at the plantations. ( ചായ കുടിക്കാൻ ചായ തോട്ടം മേടിക്കേണ്ട ആവശ്യം ഇല്ല എന്ന് ...)
The key point of interest is "Web Application".. read it 10 times and store it in your mind. From my understanding, HTML4 along with CSS2.1 could go only till a point. Long back when a 980px website was all we need to look into, HTML4 was enough. When the requirement was only a handful of browsers and the question of rendering the same in a bizarre number of devices and OS where still alien, this was enough.
The problem statement was simple:
jQuery as far as i understood, its existence stemmed out of the requirement of browser inconsistencies. It was frustrating that we needed to write scripts ( or hacks ) targeting individual browsers at that time. We needed something that could be written only once and is sure to work on other devices/browsers so that we can focus more on the application and not the browser specific hacks & bugs that needs to be addressed. ( IE is a kid with a silver spoon in its mouth.. Just because its dads name is Microsoft and IE came bundled with default Microsoft, its still in the game. Yes, its improving, but there are other browsers doing better job than IE . How i see is that, IE is the son of a billionaire getting free admissions & red carpet welcome in whichever colleges it wishes to, and it gets the unfair attention coz of its dad's popularity, rather than its own merit..unlike like a Chrome or a Firefox who are the best students in the class dedication & performance wise, but sometimes get ignored by the chicks in the class coz they were busy seeing off IE. )
Professor asks : Students, have you done with your assignments?
The principal of the college still has to keep his mouth and eyes shut to these unfair demands. Why? Coz his dad is such a powerful guy and he doesn't want to invite unwanted troubles.
Coming back to why not jQuery,
The main purpose for jQuery is DOM manipulation. And it does best what it is supposed to do.
But is that good enough to create a web app? Nope.
For an application, what all do we expect?
How easier it is, if , instead of asking your spouse to pay the mobile bill, brother to pay the electricity bill, mom to do the cooking, baby sitter to change the babies diapers, daddy to wash the puppy and your best buddy to drive the car for you..
What if there is a servant called 'John Doe ' who does everything for you.. Would that be better?
Well not exactly..( John doe is a strict guy, or rather opinionated.. who has his own opinions on doing things .. )
For paying the bills, he need all the bills at his table the previous night itself. For cooking he would like only fresh veggies... For washing puppies, he certainly need a sprayer and top class shampoos, and dog food not to forget.. He makes sure that the diaper is changed, but before that, the baby is wiped properly, when it comes to driving, he always follow traffic rules! Is this a matrimony requirement for an ideal Indian hubby ?... Not really! :P )
So then, what is that which i meant by "Opinionated"?
It means, unlike a jQuery library where we are given with a ton of methods, and how to use them, or chain them to manipulate the DOM or dynamically create HTML fragments and insert them, is entirely up to the individual developers choice. It doesn't enforce anything.It doesn't say, if you don't write it this way, you may not get the results which you are expecting. But with angular,
Just as the spiderman says:
For the previously mentioned points regarding the necessary things for an application, angular has answers for each.
So whats the big deal between a jQuery based approach and an angular approach? Put that question in another way, what is Round-trip Applications and Single Page Applications?
In Round trip apps, we have an initial HTML, eg: a form, when submitted, it sends a request to a remote server, does its logic and returns a fresh HTML based on the logic. So as far as a browser is concerned, its more of a projector who just displays what is returned from individual requests.
The HTML templates and the logic is mashed together in the server and the new one is sent back.
So for web developers who is just doing front end, i guess it would have been a bit more easy! ( Lazy!.. yawns...). Anything logical. ?.. sorry, i don't handle it.. please let me know if there is anything UI specific...and the back-end dev call is disconnected! :D
In a SPA, the architecture undergoes a hammering. Rules, rules and rules everywhere. Here, its the responsibility of the client-side ( browser ) to do a fair bit of heavy lifting rather than entrusting everything on the server-side architecture. From partial templates, to one level of forms validations, everything is done on the client side, thereby making sure that only the absolute minimum is being requested for & received from the server. Only those which is required are changed in the view as well. So my dear front end dev's...wake up...you've got more trouble coming your way than it was ever before..Honestly, its becoming difficult to draw a boundary between front end and back end developer responsibilities at times. Well, that's bound to happen as we move forward..In a typical project where the usual numbers will be one or two front end developers, half a dozen back end devs along with a lead + manager, the UI ppl's hands will be full with the task of creating HTML and if it is a responsive web development project, then the headaches of browser compatibility, devices to be supported, the pain of making every higher ups understand the fact that not all browsers are equal, so exact look and feel may not be possible, what is progressive enhancement, what is graceful degradation. ( managers may not be interested in hearing it though, they just need the estimations and the completion date ). In such a case, the additional task of creating angular , although certainly possible, but unless adequate time is brought, he will struggle for time most times. Angular is an investment that reaps the benefits at a later point of time. The results may not be as instantaneous as we see in a jQuery.
In a single page app, the shell ( or the master page if you can think of it that way ) is loaded once only during the initial page load. Subsequent requests for data retrieves only those which is changed. So it uses the Ajax friend who does the task of retrieving specific info and updating the specific portion of HTML ( rather view, from here on ) without full page refresh.
The SPA principle stresses on the importance of separating your concerns.
In jQuery, your scripts are entirely based on the IDs and classes that we have referenced in the HTML. If the designer changes your class names or id names , may be because of a naming convention pattern, scripts too has to be changed accordingly. A spelling changed here or there, your scripts doesnt fire at all. All the event handling need to be handled manually by ourselves. That brings in tight coupling between your HTML and logic ( ie, View and Model ). What we ideally want is that the MVC - The Model, The View and the Controller that stands in between those two, should not depend on each other.
Call it Tom or Harry, end of the day, everything should be on its own. No dependencies on each other. If your application is something that requires a lot of RESTful calls to the server, then Angular might be a good choice. Are you having enough bandwidth and server volume to handle a lot of round trip calls and is okay with jQuery? Choose that ! End of the day, what we need is a good application. Whether angular or non angular, as long as it performs, and as long as it meets the developers and customers expectation, thats good enough!
One last point, jQuery is an element based approach. You take one element based on its ID or a class. Do DOM manipulation on that piece. So its obvious that it will be quite difficult to maintain or reuse when we take a whole large app into consideration.
Here we say, on this ID/Class , do this or do that. Upon clicking this ID, do this or that. Upon hovering this ID, do this or that.
On the other side, angular is a "Model -state" based or data oriented approach, ( if we can call it that way.. )Here, we say, when the state of the model is this, let the view be like this, and if the model is like that, let the view be like that. ( Confused? ). Take a look at the example below. NB: Please read the "Component based" heading below as "Element Based".. typo! apologies..
On a pure jquery approach, it will be something like this:
You will be referencing the ids/classes in the script file and constructing your logic based on that which brings in tight coupling between the View and the Model.
But with a data driven approach:
Here, the view doesn't need to know about the logic and the controller doesn't have any reference of any view related ids or classes.
So getting a hang of the MV* and the separation of concerns?
Shall we proceed? :)
Forgot : Lengthier post alert! Today its not a coffee chat. Its a Friday night & for a change, I was having beer with my buddies. And once am drunk, i talk a lot. About anything and everything under the sun..you get that?
Someone told Angular is great. There are a lot of companies hiring Angular resources.So does that mean you should use it in your next project? Does it provide a silver bullet which smashes every single problem? Is it a spiderman who comes around and saves the day of innocent people? ( webbies in this context ? )
Million dollar question : I am a beginner intermediate JavaScript - jQuery developer. Will i be able to grasp the angular concepts which requires heavy object oriented knowledge and understanding? Not really. Though if you are good at it, it helps a lot and you will scale up quickly and you will mug up less.The answer is, if i can, you definitely can..I am not an expert..more of an enthusiast who goes and gets anything which i am interested in.. To enjoy a cup of tea, one just need to know how to mix the tea dust, milk and sugar in the right proportions. We dont need to know how sugar is made or how tea leaves are being processed at the plantations. ( ചായ കുടിക്കാൻ ചായ തോട്ടം മേടിക്കേണ്ട ആവശ്യം ഇല്ല എന്ന് ...)
The key point of interest is "Web Application".. read it 10 times and store it in your mind. From my understanding, HTML4 along with CSS2.1 could go only till a point. Long back when a 980px website was all we need to look into, HTML4 was enough. When the requirement was only a handful of browsers and the question of rendering the same in a bizarre number of devices and OS where still alien, this was enough.
To lift a bicycle, a healthy man might be enough..Just like that, when the web turned around its axis from websites to web apps, HTML and CSS could not hold it alone and required the additional pushing hand which was offered by the Javascript. What does that mean? HTML5 was a boom and what made it stand apart from HTML5 is that, in layman terms, putting plain and simple,
To lift a truck, heavy machinery is required for sure..
HTML4 was suitable more for websites,HTML5 had the extra essence of APIs. The canvas, the local storage, application caches, geolocation, just to name a few. Yes, the application might need to store something inside, The application might need to render some graphics, the application might make use of the geolocation in your mobile. For all these requirements, HTML5 says, "Ive got you covered.. dont go around begging or relying on 3rd party libraries.. Sit back and relax..I can do that as well for you."
HTML5 is more suited for web applications
The problem statement was simple:
"I want my application to look like a desktop application. It should be fast, it should not flicker, and it should have all those performance gains that i see in a desktop app"Just that when that statement was implemented, it was like a rocket requiring countless thrust and torque to push it off the orbit.
To win a game, individual excellence is enough.For the expectation to be met, we needed more team mates to be working hand in hand.I am coming from jQuery, so why cant i use jQuery to do what angular is doing right now? jQuery is a library. Angular is a framework. ( duh? ). Its like a boxing division sometimes. feather weight, lightweight, heavyweight...one may not be in the same league as the other.
To win tournaments, you've gotta perform as a team! ..
jQuery as far as i understood, its existence stemmed out of the requirement of browser inconsistencies. It was frustrating that we needed to write scripts ( or hacks ) targeting individual browsers at that time. We needed something that could be written only once and is sure to work on other devices/browsers so that we can focus more on the application and not the browser specific hacks & bugs that needs to be addressed. ( IE is a kid with a silver spoon in its mouth.. Just because its dads name is Microsoft and IE came bundled with default Microsoft, its still in the game. Yes, its improving, but there are other browsers doing better job than IE . How i see is that, IE is the son of a billionaire getting free admissions & red carpet welcome in whichever colleges it wishes to, and it gets the unfair attention coz of its dad's popularity, rather than its own merit..unlike like a Chrome or a Firefox who are the best students in the class dedication & performance wise, but sometimes get ignored by the chicks in the class coz they were busy seeing off IE. )
Professor asks : Students, have you done with your assignments?
Chrome and firefox - Yes Maa'm!
IE ( Especially the IE8 and IE9 ) - Nope, It doesnt work out like that for me am afraid!..
I need special care. Get me someone to write it for me. Send me some burgers in between, a couple of beers as well.. An evening massage by a cheerleader would be awesome!
The principal of the college still has to keep his mouth and eyes shut to these unfair demands. Why? Coz his dad is such a powerful guy and he doesn't want to invite unwanted troubles.
Coming back to why not jQuery,
The main purpose for jQuery is DOM manipulation. And it does best what it is supposed to do.
But is that good enough to create a web app? Nope.
For an application, what all do we expect?
- There will certainly be DOM manipulation. ( Yes, jQuery can be used)
- We will require templates ( Handlebar templates / mustaches ? )
- We would like to use the back and forth arrows for navigation inside the app ( History JS? )
- Data binding for sure! ( KnockoutJS, whole sole purpose is the same! )
- Am i doing Ajax based calls to retrieve some data from a remote server? ( Again, jQuery? )
- So what about maintaining some sort of structure to the app?
- What about testing them if we need to?
How easier it is, if , instead of asking your spouse to pay the mobile bill, brother to pay the electricity bill, mom to do the cooking, baby sitter to change the babies diapers, daddy to wash the puppy and your best buddy to drive the car for you..
What if there is a servant called 'John Doe ' who does everything for you.. Would that be better?
And that John Doe is conveniently called AngularJS in our context!Is that it? :) If i call John Doe, will he do everything for us?
Well not exactly..( John doe is a strict guy, or rather opinionated.. who has his own opinions on doing things .. )
For paying the bills, he need all the bills at his table the previous night itself. For cooking he would like only fresh veggies... For washing puppies, he certainly need a sprayer and top class shampoos, and dog food not to forget.. He makes sure that the diaper is changed, but before that, the baby is wiped properly, when it comes to driving, he always follow traffic rules! Is this a matrimony requirement for an ideal Indian hubby ?... Not really! :P )
So then, what is that which i meant by "Opinionated"?
It means, unlike a jQuery library where we are given with a ton of methods, and how to use them, or chain them to manipulate the DOM or dynamically create HTML fragments and insert them, is entirely up to the individual developers choice. It doesn't enforce anything.It doesn't say, if you don't write it this way, you may not get the results which you are expecting. But with angular,
Just as the spiderman says:
With Power, comes responsibilities...It is our responsibility to follow the recommendations by angular if we need to leverage the maximum from it. Angular suggests a lot of things, for eg: DOM manipulations should be done only inside a directive, controller should be light and should not be doing DOM manipulations, We need to create a module on to which we need to attach the rest of the controllers, filters, services, directives etc, reusable logic should be moved out of the controller to a service... (just to name a few points)
For the previously mentioned points regarding the necessary things for an application, angular has answers for each.
- Does it provide DOM manipulation ? Of course yes, via directives.!
- It has its own templating built in. So no need to rely on 3rd party templates.
- History? Oh yes, the browser navigation history is maintained by angular itself.
- Data binding? Of course, one way, two way, you name it!
- Ajax calls? ( The $http, $resource is angular built in modules that helps for async server calls for fetching data and sending it back and reflecting the same at a later point in time.
- Structure? Angular provides modules and a flexible way of creating your app structure.
- Testing - This is the icing on the cake...every single component is testable ( Karma is the test suite and Jasmine is the one with which we write test cases )
So whats the big deal between a jQuery based approach and an angular approach? Put that question in another way, what is Round-trip Applications and Single Page Applications?
In Round trip apps, we have an initial HTML, eg: a form, when submitted, it sends a request to a remote server, does its logic and returns a fresh HTML based on the logic. So as far as a browser is concerned, its more of a projector who just displays what is returned from individual requests.
The HTML templates and the logic is mashed together in the server and the new one is sent back.
So for web developers who is just doing front end, i guess it would have been a bit more easy! ( Lazy!.. yawns...). Anything logical. ?.. sorry, i don't handle it.. please let me know if there is anything UI specific...and the back-end dev call is disconnected! :D
In a SPA, the architecture undergoes a hammering. Rules, rules and rules everywhere. Here, its the responsibility of the client-side ( browser ) to do a fair bit of heavy lifting rather than entrusting everything on the server-side architecture. From partial templates, to one level of forms validations, everything is done on the client side, thereby making sure that only the absolute minimum is being requested for & received from the server. Only those which is required are changed in the view as well. So my dear front end dev's...wake up...you've got more trouble coming your way than it was ever before..Honestly, its becoming difficult to draw a boundary between front end and back end developer responsibilities at times. Well, that's bound to happen as we move forward..In a typical project where the usual numbers will be one or two front end developers, half a dozen back end devs along with a lead + manager, the UI ppl's hands will be full with the task of creating HTML and if it is a responsive web development project, then the headaches of browser compatibility, devices to be supported, the pain of making every higher ups understand the fact that not all browsers are equal, so exact look and feel may not be possible, what is progressive enhancement, what is graceful degradation. ( managers may not be interested in hearing it though, they just need the estimations and the completion date ). In such a case, the additional task of creating angular , although certainly possible, but unless adequate time is brought, he will struggle for time most times. Angular is an investment that reaps the benefits at a later point of time. The results may not be as instantaneous as we see in a jQuery.
In a single page app, the shell ( or the master page if you can think of it that way ) is loaded once only during the initial page load. Subsequent requests for data retrieves only those which is changed. So it uses the Ajax friend who does the task of retrieving specific info and updating the specific portion of HTML ( rather view, from here on ) without full page refresh.
The SPA principle stresses on the importance of separating your concerns.
In jQuery, your scripts are entirely based on the IDs and classes that we have referenced in the HTML. If the designer changes your class names or id names , may be because of a naming convention pattern, scripts too has to be changed accordingly. A spelling changed here or there, your scripts doesnt fire at all. All the event handling need to be handled manually by ourselves. That brings in tight coupling between your HTML and logic ( ie, View and Model ). What we ideally want is that the MVC - The Model, The View and the Controller that stands in between those two, should not depend on each other.
I give you a task, you do it, that simple...dont care or dont worry about the task i have given it to your friend..Some call the architecture MVC since the C stands for Controller. Some call it as MVVM arguing that the Individual view needs individual controllers, so in effect the "controller" is the model for that view, so lets call it "ViewModel", ( especially the WPF folks )
Call it Tom or Harry, end of the day, everything should be on its own. No dependencies on each other. If your application is something that requires a lot of RESTful calls to the server, then Angular might be a good choice. Are you having enough bandwidth and server volume to handle a lot of round trip calls and is okay with jQuery? Choose that ! End of the day, what we need is a good application. Whether angular or non angular, as long as it performs, and as long as it meets the developers and customers expectation, thats good enough!
One last point, jQuery is an element based approach. You take one element based on its ID or a class. Do DOM manipulation on that piece. So its obvious that it will be quite difficult to maintain or reuse when we take a whole large app into consideration.
Here we say, on this ID/Class , do this or do that. Upon clicking this ID, do this or that. Upon hovering this ID, do this or that.
On the other side, angular is a "Model -state" based or data oriented approach, ( if we can call it that way.. )Here, we say, when the state of the model is this, let the view be like this, and if the model is like that, let the view be like that. ( Confused? ). Take a look at the example below. NB: Please read the "Component based" heading below as "Element Based".. typo! apologies..
You will be referencing the ids/classes in the script file and constructing your logic based on that which brings in tight coupling between the View and the Model.
But with a data driven approach:
Here, the view doesn't need to know about the logic and the controller doesn't have any reference of any view related ids or classes.
So getting a hang of the MV* and the separation of concerns?
Shall we proceed? :)
No comments:
Post a Comment