The problem with Angular

Re:The problem with Angular by pmontra on Wednesday January 14, 2015 @09:35AM (#8886442)

This is basically what I do sometimes in Rails apps backing some light jQuery frontend. They are traditional web apps with a few pages doing many front end tasks (think about adding, editing, deleting entries in an address book). They are done by sending $.ajax calls to the server. Some of them get JSON responses but some of them just get HTML and replace the DOM of some elements. That HTML is rendered using the very same partials used to generate the page when it was loaded first (think about the <tr>s in that address book's <table>). This is DRY. Obviously having all the templates in the client would be also DRY but I don't want to have some templates in the client and some on the server. It's either all or nothing and, at least for me, it's just easier to do some of those things on the server.

[ Parent | on HN ]

Re:The problem with Angular by riles01 on Wednesday January 14, 2015 @10:47AM (#8886932)

Doing these things on the server also allows you to take advantage of server-side caching. For some applications, you cannot do this as they are too tightly tied to the current user. However, most applications have at least some sections that can be rendered and cached across user segments.

[ Parent | on HN ]

Re:The problem with Angular by fixermark on Wednesday January 14, 2015 @11:07AM (#8887090)

Does this require clients of your server to all support HTML so that they can screen-scrape partials to understand the results of their operations, or does your server support two output formats?

Two output formats is a reasonable solution, but one that you don't have to maintain if you go with a framework (such as Angular) that can render JSON back into HTML. It really boils down to whether you want to support a more complicated server or a more complicated client (or drop support for any clients that aren't yours).

[ Parent | on HN ]

Re:The problem with Angular by pmontra on Wednesday January 14, 2015 @11:58AM (#8887446)

It's a traditional web app, so it works with HTML. We don't plan to have anything else any time soon so the priority was on the time to have the HTML ready to go.

I did a Rails app serving JSON exactly one year ago, to a small Angular front end. It's was a little disheartening to see an empty page loading and then making JSON calls and thinking that by then a server rendered page would have been already fully loaded. That's why I said that it's all or nothing: either a single page app or many html pages. A few single app pages don't do well, unless they are preloaded with server rendered content.

[ Parent | on HN ]