What is AngularJS?
AngularJS is hardly anything new but it still remains a “cool kid”. Designed by Google in 2009, Angular is a JavaScript MVC framework that brings all of the functionality of single page applications (SPAs) into a simple, easy-to-use package.
It contains everything you need to create SPAs: routing, two-way data binding, unit testing, rendering of HTML, event-handling and composability.
Even if you are not creating a SPA, I have heard of numerous developers who use AngularJS for the jQuery-ish DOM manipulation abilities of the library and nothing else.
The great part about AngularJS is that you do not need to use all of the library’s features immediately. You can pick and choose what to use and “grow” your application when there is a need.
Quite often I have been asked whether it is convenient to use Angular. I would say that it really depends on what you have in mind.
If you are thinking of building fully-fledged SPAs, Angular might be worth it, but then again Ember, React, Meteor or Aurelia may represent a viable alternative, particularly considering that some of them gained lot of popularity after the initial release of Angular.
If you’re thinking about fairly ‘simple’ applications, such as JavaScript forms with persistence or static pages with some lightweight interactivity, then perhaps Knockout would be a better framework to look at. It has quite a shallow learning curve and works well for producing JS-powered widgets and interactive forms.
Should I use Angular JS or jQuery?
Both Angular and jQuery address web development problems, but they do this with two different approaches. This is most likely because jQuery is much older and had different problems to address at the time it was invented.
In fact, the main objective of jQuery is to manipulate the DOM (Document Object Model). In plain words this means that it allows you to control the look and feel of a website.
As time passed by and more people adopted the jQuery language to create attractive, snappy websites a new challenge arose; code maintenance (I will not be surprised if you have seen tons of walls of jQuery spaghetti code by now).
Angular addressed this problem by introducing the concept of a framework. Although Angular is “marketed” as a solution for making SPA applications, the real value in using a framework is separating the view layer, from the logic, from the controller, thus creating code that is much more maintainable and scalable.
By using a framework you’re welcome to write code in plain JavaScript, or add in an existing library of common functions to drastically reduce the code needed to accomplish most things.
Good frameworks can help build more robust code so that it is modular (therefore reusable), readable, performant and secure. In a nutshell, a framework can offer:
- Templating
- Data-binding
- Routing (single page app)
- Clean, modular, reusable architecture
- Security
- Additional functions/features for convenience
Is it SEO safe using Angular, jQuery or JavaScript?
Back in 1998 when Google was initially put together, there was very little JavaScript or CSS out there and so less to worry about. A lot has changed since then and today the web is full of rich, dynamic, amazing websites that make heavy use of JavaScript.
Because of this, search engines have become much more confident in interpreting and rendering richer websites, meaning they can see content in the same way as modern web browsers do.
We have noticed such behaviour predominantly on Google, but Bing also seems to be making similar advances. Unfortunately, this may not be the case for other local search engines. For instance, we have found that Yandex and Baidu struggle to digest the JavaScript language in general as well as jQuery.
Therefore, I believe the best answer here is to evaluate your circumstances and understand which markets your website will be targeted towards. Only then can you decide which solution to use.
jQuery is not necessarily as bad as you may think. For instance, it is quite useful for techniques like parallax scrolling. Hence I won’t dismiss the idea of using a framework or JavaScript library unless there are specific counter indications for your particular project.
How Angular is evolving
A new version, 2.0, has been announced for release at some point in 2015, and the developer previews released over time suggest the new framework is going to be a big departure from Angular 1.0, though the difference is mainly related to syntax – not concepts.
That said, Angular 2.0 won’t be backwards compatible. If you are willing to improve your learning curve, perhaps sticking on version 1.3 may not be your best bet.
However, should you be in the position to commence writing a new SPA application/site today, it’s your time to choose whether to remain anchored to the past, with an already-tested framework that comes with plenty of examples available on the net, or to go for something new which may not come with the best level of support during the first few months.
What are the SEO challenges in using AngularJS?
I believe the most time consuming challenge comes from a technical perspective. There is no standard technology available to crawl such sites.
In that respect, depending on how the site is built, it may be difficult to assess everything that falls under the on-site SEO structure (e.g. link depth, canonicalization, etc.), as well as measure key technical factors such as page load times.
From an offsite perspective, depending on the URL structure, there could be challenges in the future whilst securing links to specific pages.
Despite some difficulties with the optimisation process, I cannot ignore the benefits of making single page web apps. With the right support, these sites can become fantastic content delivery vehicles, capable of showcasing compelling content that makes users want to engage and share.
The clean back-end restful interface. The load times as the user navigates from page to page. All the logic is in one place instead of split (or even duplicated) across both the client and server and this carries significant benefits for the user, even if it’s only perceived by a quicker, slicker experience.
Although SPA can be layered on top of a CMS, building such a site is not going to be any faster. A dynamic site, with content rendered as static html on the server-side, would achieve the same level of efficiency as a SPA.
For this reason, I would recommend using sufficient technical precautions during the discovery phase and assessing the project in its entirety, thus adopting fail-safe measures to minimize any potential risk.
