What is AngularJS?
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.
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.
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.
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:
- Routing (single page app)
- Clean, modular, reusable architecture
- Additional functions/features for convenience
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.
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.
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.