>Easily create new RESTful API resources by just creating folders and naming functions a certain way.
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.
>A command-line tool for installing third party packages, using npm + bower
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.
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 server frameworks specifically for working with a client framework that should be a sign to stop and think that something might be wrong.
Synth author here. I do realize the idea is crazy. In fact I call it a crazy idea in the video embedded on the page there. I love crazy ideas. Crazier the better!
But I will disagree on the point that the browser is just a client. It can be treated like that, if you want, but you can take advantage of the fact that the client code is serveable from the same server that has access to the app's data. And that's what Synth was designed for.
Consider that on projects where the domain problem is simple yet the user requirements are complex, it may make more sense to optimize speed of development of the client.
a webmail client would be a great example of this. The server side is really a small problem, excepting for performance. However, getting the client right is why people still use gmail.
- Preload html view on page load (saving another extra roundtrip!)
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.
Depends on how you're using angular to inject views.
Vanilla angular views are requested, parsed, bindings added, and then presented. It's one request for the html, all the rest happens in browser.
angular ui views may be different, but according to my network panel on chrome its still one request for the template and whatever assets it brings with it.
I'm going to guess the guys meant they will preload the first view based on page state, which does indeed save a single round trip, but means nothing for any state changes that would occur after the fact. I would argue that an app which needs to micro optimize like this might not be built correctly from the get go, as you're really only saving 1 request and whatever small byte size of the content.
That's not what he said. He said it probably wasn't rendr for
angular. I'm pretty sure he's saying they preload the initial viewing
template (not a prefilled template) based on app state - stuff like
clientside routing and such. The browser still has to render the
template, but it doesn't have to be fetched by a separate request.
And you can call one view with your usual "templateUrl: 'hackernews.html'"
Especially if I have many directives with more than a few lines of html. That way you can embed them in your main html or in a separate cacheable file.
Doesn't this method of including dynamic data in the index.html page prevent it being served from a CDN?
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.
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.
> Doesn't this method of including dynamic data in the index.html page prevent it being served from a CDN?
if your cdn is serving static html pages then yeah probably. If it's just serving assets like images/js/css/fonts, it shouldn't be an issue since those would all be extra reqs anyway, and not "compiled" into the html.
I serve up all my angular view templates as static files (ui-router), use ng-include for dumb stuff like footer text that never changes, and rely on the API (hmac) for populating content.
Perhaps this is over opinionated, but angular seems to me to be designed so that you don't have to do ANY view templating bullshit on the server. I don't have a single angular app that hits the app server for an html template compiled by code. In fact the only thing I do serverside templating in now is drupal.
I agree. These days static templating is preferred over dynamic templating. The static files, like index.html and of course other resources like images and stylesheets are cached and served by a CDN very quickly. Dynamic content is fetched using a HTTP or a WebSocket api.
Dynamic templating is a pretty old-fashioned way to build websites. The practise originates from cgi and PHP.
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.
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.
> 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.
What functionality are you referring to specifically?
Which smoother alternatives do you recommend? I've used Angular and Backbone in various projects and both have their benefits and warts, so something new to look at would be useful.
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.
>A command-line tool for installing third party packages, using npm + bower
Why wouldn't I just use npm and bower? They have enough problems as it is, an additional wrapper just creates problems..