it is not, an Isapi filter, WCF is a pretty amazing piece of software I know really well, I developed tons of WCF services, it has amazing extensions points and an amazing server and client pipeline. At a certain point someone has thought that since rest is coming back to life WCF must support also rest/Json but is is not intended to do that, that's why now we have WebAPI in the asp.net stack. The first implementation of the rest/Json stack in WCF, via the infamous WebHttpBehavior, was a PITA, that's it. Luckily after that failure someone has thought that creating a brand new stack is a good choice instead of trying to built something on top of WCF.
.m Sent from Windows RT From: Kevin MacDonald<mailto:[email protected]> Sent: Monday, February 24, 2014 8:10 PM To: [email protected]<mailto:[email protected]> It's also really hard to figure out what WCF is doing because it is (I believe) an ISAPI filter, and most of it is running deep under the covers below where .NET has access to it. I abandoned WCF because it was producing mangled JSON which I could not fix or debug, and it turned out months later that there was a known bug where when logging is turned on in certain situations this bug occurs. Service Stack is much cleaner, and is designed specifically for web services, unlike WCF which in the Microsoft tradition seems to be designed to be everything for everybody Kevin On Mon, Feb 24, 2014 at 9:14 AM, Mauro Servienti <[email protected]<mailto:[email protected]>> wrote: WCF is everything other then buggy, it simply really hard to access it via JavaScript, a PITA. Sent from my Amazing Yellow Lumia, typos are guaranteed ;-) ________________________________ From: Kevin MacDonald<mailto:[email protected]> Sent: 24/02/2014 17.59 To: [email protected]<mailto:[email protected]> Subject: Re: [AngularJS] Is AngularJS good choice for my project with WCF, SQL Server On a slightly different note I suggest considering Service Stack over WCF for server-side web services. WCF is bloated and buggy. On Sunday, February 23, 2014 8:14:20 PM UTC-8, Luke Kende wrote: You asked about developing a web application. When we talk about web "apps" these days we tend to mean an SPA. Using angular just for javascript functionality and delivering each page from the server can work, but I believe defeats the purpose of it's design. I agree with Mario in terms of "context" and having multiple SPAs where needed, but an SPA is superior when you are writing a very specific interface, like say Gmail, or a spreadsheet UI, or maybe a social network like Facebook. These cases are when the app doesn't need to have the complete page redrawn, only certain areas change, like switching from a list of emails to showing one specific message. (Can you imagine Facebook or Gmail loading a new page for every view switch?) Using angular creates a separation between the generating the view (client side) and generating the data needed for the view (server-side). The server does not need to know about html and and html has no sprinkling of C#, PHP, or other servers-side language. I find this to be a superior way to write html personally. It even abstracts the the back-end such that page doesn't care where it gets its data as along as the ajax call returns the json data needed. In terms of performance, the app doesn't load everything, only the index.html file with css and javascript resources, then your home page specifies a view and only that template is loaded (a small html file typically). Once an action causes a change in view only then is a new template loaded via XHR. The only added time is if the data must be retrieved to populate the view, but if the app already has it in javascript then this much quicker than loading it from the server (especially if someone has a slow connection). In summary, if you have a focused context for an application and want to use a browser as the UI, then an SPA (and Angular) have benefits for the UX, speed, and code organization. On Sun, Feb 23, 2014 at 10:35 AM, Mauro Servienti <[email protected]> wrote: IMHO it is not superior at all, they are 2 face of the same medal, in the end as the application become larger and larger you end app with multiple single page applications generally divided by context. Dividing by context is acceptable because for the user it acceptable to reload everything when changing context. Never, IMHO, approach a problem thinking in term of performances, use cases and the user mental model are much more important for the success of the application, performances tweaks comes after. .m -- (no keyboard keys have been killed due to the really annoying OSX spell checker) On 23/feb/2014, at 18:05, Arshad Nazeer <[email protected]> wrote: How is Single Page Application superior than Multi Page Application when both are developed using AngularJS? In SPA complete page is loaded at once but in MPA only a page that the user needs is loaded. This reduces page size and the page gets loaded quickly. -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/kam-jeAACSQ/unsubscribe. To unsubscribe from this group and all its topics, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:angular%[email protected]>. To post to this group, send email to [email protected]<mailto:[email protected]>. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/kam-jeAACSQ/unsubscribe. To unsubscribe from this group and all its topics, send an email to [email protected]<mailto:angular%[email protected]>. To post to this group, send email to [email protected]<mailto:[email protected]>. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/groups/opt_out.
