Synth – A Node.js web framework designed for AngularJS
synthjs.com
synthjs.com
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..
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.
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.
But you really shouldn't.
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.
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.
1: https://github.com/rendrjs/rendr 2: https://github.com/wvl/highbrow
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.
You're seriously underestimating the difference this makes. If this is rendr for angular it is a breakthrough for the angular community.
<script type='text/ng-template' id='hackernews.html'> </script>
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.
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.
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.
Dynamic templating is a pretty old-fashioned way to build websites. The practise originates from cgi and PHP.
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.
Too opinionated IMO.
What functionality are you referring to specifically?