>Easily create new RESTful API resources by just creating folders and naming functions a certain way.<p>I don't like that. Memorizing new naming conventions that affect functionality makes things harder instead of easier in my experience. Sure, you can create a cool demo effect by showing how "easy" and "quick" it's to create certain stuff. Once your application scales, things become more chaotic though, and maybe the convention starts to hit limitations. In addition, it becomes more difficult to learn the code base when you have these naming conventions that create functionality all over the place.<p>>A command-line tool for installing third party packages, using npm + bower<p>Why wouldn't I just use npm and bower? They have enough problems as it is, an additional wrapper just creates problems..
Whenever I read a project with a marketing pitch of "Some server specifically for some client side framework!" I can't help but feel the author has lost their mind.<p>The browser is just a client, people. All of the frameworks for the browser are just (supposed to be) abstractions for creating dynamic browser applications. If you need to create <i>server</i> frameworks specifically for working with a <i>client</i> framework that should be a sign to stop and think that something might be wrong.
- Preload html view on page load (saving another extra roundtrip!)<p>does this mean it serves fully formed html like rendr[1] or highbrow[2]? I'm not sure what angular does, but all client-side apps I've seen, templates are compiled into javascript and concatenated onto the app code, so they're never an extra roundtrip.<p>1: <a href="https://github.com/rendrjs/rendr" rel="nofollow">https://github.com/rendrjs/rendr</a>
2: <a href="https://github.com/wvl/highbrow" rel="nofollow">https://github.com/wvl/highbrow</a>
Doesn't this method of including dynamic data in the index.html page prevent it being served from a CDN?<p>When serving a web application, I'm generally more worried about the time it takes before the user sees a response, even if the page isn't fully hydrated yet, than the total load time.<p>Requiring a hit to the database before the index.html is served seems like a bad idea to me, even if it is 'saving' a request to the API.
I'm pretty sure this was discussed at ng-conf and it wasn't implemented by the core team after another team in Google asked them for the same functionality.<p>I see service workers and web sockets (the client) dealing with the additional overhead of SPA in future. Merging the backend and frontend would just kill it for many companies as you're dictating backend for a frontend framework.<p>Too opinionated IMO.