I did this on a client project recently, but ended up moving away from it. I Found it falls down when you have different devs working on the same features from different ends. Instead, I used JSON files that the back end would just serve from the routes I expected.
Firstly, it provides a clearer and more obvious contract with the back end, one that you can see in the network traffic.
Also, when the endpoint is actually implemented on the API, it all Just Works. There's no intermediate step of pulling out the mocks and letting the real data flow through. It also provides a simple smoke test path during development of the endpoint.
And I would respond to GET and simulate POST/PUT/DELETE in memory. While I was working on the backend proper, my teammate could just assume that the backend was 'working'. Then when I was ready, I wired in the real implementation.
The advantages I found of doing this server side instead of client side (like in the article) was that the network round-trips were real, thus we'd know when there was something too inefficient going on. Plus, we would work on the same domain objects (captured in the JSON) so there was no hurdle when I wired the real implementation. Finally, I used the JSON files to stub some fake data into the database when we wanted to test it out.
Ideally, I think something like this is good, but for prototyping, I think $httpBackend is a good solution. I'm on a mid-sized project currently where I implemented a mock backend with $httpBackend, and use a fetch node script to pull all of the json we want from our daily build for development locally. When we need to compile our assets and prepare it for deploys for testing on the daily server, we have a nice grunt script to do that and test things out on the daily build.
When a frontend dev is rapidly building out features though, he/she shouldn't be concerned with the performance of the backend - having a full stack dev server to accompany a mock backend for local development or some sort of local solution is ideal.
I've been doing this for well over a year now on my html5/js apps.
I have a custom data access layer that returns a promise.
The data access layer mocks RESTful services.
I have a databootstrap.js that gets put in local storage on app start, and hey presto a fully functional prototype....
Its definitely a great way to work, it really engages your client/end user and the feedback loop becomes smaller.
Once your done, your client side is mostly finished.
I've done this for a couple of apps now - it is an excellent way to prototype when you know what the data from the api endpoints will look like, but you don't have a real backend to test against. It lets you rapidly build a frontend without worrying about the backend.
However, it isn't the best solution for everything. It's possible to have your workflow bogged down by refactoring logic if the api for the endpoints are in flux.
Maybe I'm looking at this the wrong way, but the emphasis on certain languages and frameworks for "rapid prototyping" strikes me as short-sighted.
Sure, if you learn them well, you can build a proof of concept quickly. But unless you currently do everything in C... shouldn't you already be able to do this with whatever technology/ies you're already the most proficient with?
Depends what "whatever technology you're already most proficient with" is.
I think that any of Angular, Backbone, React, JQuery, Django, Rails, Node.js, PHP, and many others are fine for prototyping. Use whatever you're most familiar with.
However, if all you use is Java, or C++, or Google Closure - you're probably gonna have a bad time. Some technologies are built for mature projects with dozens to hundreds of developers. They pay a large tax to manage the complexities of large projects. If you're just starting out, you'll be paying that tax even though your codebase doesn't require it.
As far as I understand, the point of the article is to simulate a working backend in order to concentrate only in the frontend, the choice of AngularJS is contingent, you could do it with another framework (or none) but they chose this one. They aren't saying "Hey, Angular is the best for prototyping" but "Hey, not worrying about the backend is great for prototyping, and we do it in this way with Angular".
The interesting part is that you don't have to worry about web servers, server software, databases, scalability or server deployment; just simulate what kind of responses you'd get with the complete web application and iterate from there until you are happy with your frontend. This is particularly useful if your development process is driven by UX.
I'm minded to prototype in angular but I'd rather use a generic data backend like firebase (or roll my own any-path-works rest api using dataset) than mock http calls.
Firstly, it provides a clearer and more obvious contract with the back end, one that you can see in the network traffic.
Also, when the endpoint is actually implemented on the API, it all Just Works. There's no intermediate step of pulling out the mocks and letting the real data flow through. It also provides a simple smoke test path during development of the endpoint.