

Synth – A Node.js web framework designed for AngularJS - jchesters
http://www.synthjs.com/

======
nawitus
>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..

------
rubiquity
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.

~~~
jonny_eh
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.

~~~
pessimizer
>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.

But you really shouldn't.

------
bryanlarsen
\- 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.

1: [https://github.com/rendrjs/rendr](https://github.com/rendrjs/rendr) 2:
[https://github.com/wvl/highbrow](https://github.com/wvl/highbrow)

~~~
SDGT
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.

~~~
KaoruAoiShiho
Your response to someone making an amazing optimization is if you need
optimizations your app is done wrong... seriously?

You're seriously underestimating the difference this makes. If this is rendr
for angular it is a breakthrough for the angular community.

~~~
benaiah
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.

~~~
KaoruAoiShiho
That's true I don't see any examples of server side rendering though the
developer says it works...
[https://github.com/JonAbrams/synth/issues/35](https://github.com/JonAbrams/synth/issues/35)

------
jmstout
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.

~~~
SDGT
> 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.

------
justif
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.

Too opinionated IMO.

~~~
Kiro
> 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?

------
woah
How did Angular become synonymous with frontend JS apps? It's one of the
clumsier frameworks out there.

~~~
coev
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.

~~~
woah
Take a look at Vue.js

