Does it set a bad example to use angular for this website itself?

[andybak]

angular is the perfect tool for creating single page apps etc - but aren't you encouraging misuse using it for a content site that would be much better suited to largely server-side rendering (or an unobtrusive approach such as pjax)

[levibotelho]

From the very start I knew that for UX reasons I wanted LearnAngular to be a single page app. Looking back, I think that this was the right design choice to make.

Completely unrelated to this is the fact that LearnAngular contains its fair share of client side code, notably to run the code editors. Data binding is essential to make this code simple and easy to maintain.

While Angular is not the only framework which is capable of fulfilling these requirements, it does the job quite nicely. The $location API is superb, the Ajax method abstractions are easy to use and the data binding works beautifully. In short, Angular fits the bill for the app.

I definitely would not consider this to be "misuse".

[andybak]

OK - but is it possible to implement 'real' urls for every page?

i.e. Issuing a normal GET to any URL should return the expected content. There are so many benefits to this (at least for content sites) in terms of accessibility, SEO, accessibility, caching that it's not something that should be discarded lightly.

[levibotelho]

Those are good points, but both issues that you bring up are taken care of in LearnAngular.

Caching on the client side is handled no problem. You can see this when switching back and forth between pages. The first switch entails a delay; subsequent switches are for all intents and purposes instantaneous. On the server side, caching is enabled for all Ajax endpoints and is handled in the exact same way as it would be for a request demanding an entire page. As far as it is concerned, there is no functional difference between a GET request to mysite.com/mypage and a GET request made to mysite.com/content?url=mypage, which is essentially what is being done here.

SEO is handled using Google's escaped_fragment protocol, which provides a way for SPAs to communicate their content to search engines. Implementing escaped_fragment compliance does indeed require a small amount of additional work, however I make use of an open source library that I wrote which does the heavy lifting for me. Google therefore indexes the real content of each page and not just the HTML which is the same for each URL.

[andybak]

There's a lot more to caching than just the client.

And 'escaped_fragment' is bit of a hacky workaround.

Single page apps that require javascript are not a problem but if we end up in a place where normal content pages requires a javascript interpreter then we have broken one of the fundamental building blocks of the web.

And there is no need to do this. We have the tools and the techniques to get all the benefits of partial page loading and dynamic content without re-rendering AND still maintain a clean GETable web.

It's a now basically a philosophical disagreement and the arguments against a javascript-only web are many and complex. I have a feeling we will not reach an agreement on this in a Github ticket. It's a shame though.

[levibotelho]

I think that we're going to have to agree to disagree regarding caching/SEO 😄. As I said, caching is handled both on the client and server side quite effectively (I think it shows in the final result) and Google's done a great job indexing the site using escaped_fragment.

You are absolutely correct though, it is a philosophical discussion, and there's nothing wrong with that! Angular itself has its fair share of detractors for the reasons you outlined. I wrote the site to be an aid for those attempting to grasp Angular's steep learning curve. It was never intended to be an advertisement for the product and hope that people won't take it as such. 😄