There are some exceptions to the sweeping statement I am about to make but I am growing tired of seeing the same mistake being made when choosing a technology stack for a multi-page web application implementation…
So… What’s Wrong With AngularJS?
AngularJS is a fantastic JavaScript framework and an excellent technology choice when building a web application with a single page architecture. There is nothing inherently wrong with it that should exclude it from consideration if you are building a dashboard style application that you want to be interactive and are looking to mimic a native application user experience.
Can I use it for a website implementation?
You can, but before you do you should ask yourself some questions:
- Does your implementation have more than one page?
- Does progressive enhancement give you everything that a SPA would offer?
- Do I care about SEO?
If you answer ‘yes’ to any of the above questions, you should seriously consider an alternative approach.
My web application DOES have more than 1 page
If you are building a web application to serve requests for different pages of content then a single page architecture is counter intuitive and akin to forcing a square peg into a round hole.
You are going to invest time and resources into producing a web application that might look fantastic but falls over completely without JavaScript enabled.
Neither hash bangs (#!) or HTML’s history API have provided a solution to the problems when trying to implement a multi-page web application using a single page architecture JavaScript framework.
How can progressive enhancement help?
Despite all the advances in crawler technology, a server-side technology is still far superior at serving multi-page content. Server-side technologies are far more mature than the emerging JavaScript frameworks and the total cost of ownership for equivalent solutions are much lower.
The primary reason I hear for wanting to use AngularJS or any of the other SPA JavaScript frameworks is to have a native app feel by removing the visible loading of a page when browsing pages on the web application.
This can very easily be achieved without the bloat that comes with a framework such as AngularJS. You can use JavaScript to override the default behavior of a hyperlink so that you request the page via ajax, parse the content from an inner DOM container, and drop it onto the current page.
Alternatively, you can expose CaaS so that the initial page load is rendered server-side with subsequent updates being fetched via Ajax. This is different to an SPA implementation in that the content is still rendered on the server-side before being injected into the page by JavaScript.
What about SEO?
If you serve a single page architecture that takes over the routing of your website you give your visitors a different browsing experience than the search engine crawlers that will visit you.
The usual proposed solution to this is to detect crawlers and serve a different page that can be effectively crawled so now you have two implementations to maintain instead of just the one.
You can use the HTML5 history API and push state to modify the url as you navigate SPA implementation but unless this url is stateless and would present the same page and state as you currently have it isn’t a consistent experience. The same consideration applies when considering social sharing. A url should be stateless so that when you share a url it reflects the content you initially shared rather than contextual content based on the journey you took to arrive at that url.
The far better approach is to have a multi-page web application that can serve the appropriate content by url using hyperlinks and other HTML standard features. Then, using custom JavaScript or a lightweight JavaScript framework, introduce progressive enhancement for those visitors that have it enabled.
This will give you a consistent experience for crawlers and visitors whilst only maintaining a single implementation. You’ll also be able to achieve exactly the same user experience that a SPA JavaScript framework can provide but at a far lower total cost of ownership.
So SPA is great, but not for multi-page websites
Another benefit is that, with the business logic and rendering primarily on the server-side you do not need to come up with the solution to problems that have already been solved beforehand in areas such as security, state, social etc.
It’s a shame to use the wrong technology stack just because you failed to ask the right questions before investing time and resources into a new web application implementation. Especially if the only reason for using the wrong technology was because it is new and trendy or because the CEO heard good things about it.
Vouzamo's Blog 