
Why we left AngularJS - route66
https://sourcegraph.com/blog/switching-from-angularjs-to-server-side-html
======
dchuk
A lot of people seem to think that Single Page App frameworks like
Angular/Ember are suitable for use on the public facing client side. I've
always believed that SPAs are meant to be behind a login, where you don't have
to also deal with spiders and other sub-optimal browsing devices, and you have
a little bit more wriggle room when it comes to routing and web history.

Just look at Blogger...their client-side rendering is annoying as all get out.
It's just a blog post, render it server side and give me the content, then
sprinkle on some gracefully degrading JS on top to spice it up.

I say this as a huge proponent of Angular who uses it for all his web app
projects who also wouldn't ever use it on a public facing application.

~~~
EC1
What would you use for a public facing application?

~~~
uptown
I recommend PJAX. It degrades gracefully for search engine indexing.

~~~
andybak
Yep. PJAX and it's ilk are wonderfully simple, degrade well and fit in with
many existing approaches.

We added PJAX rendering to a Django site in under an hour. All the benefits of
SPA's and few of the downsides.

------
neya
I had the opportunity to work for a million dollar budget client project,
about a year ago. (Obviously I'm bound by an NDA, so I won't go into
specifics). You can think of this site like an oDesk/Freelancer competitor,
but with some social features.

We also had another team from California working on this project, who
consistently insisted that we go with Angular for a project of such
complexity. Back then, on HN, everybody was writing about how awesome Angular
is, and how you must use it for your next project and so on. It reminded me of
the early MongoDB days here.

I was under constant pressure from my client too, since he was also reading a
lot about Angular everywhere and the Californian company had him almost
brainwashed in favor of angular. After already falling trap for the MongoDB
buzz (I used MongoDB for the wrong use-case and suffered the consequences), I
decided to carefully evaluate the decision to go with Angular for the project.

After about 6 months of using Angular for a different medium-scale project, I
decided against it for my client. I realized that Angular is the all powerful
Battle Tank. It can do everything you want it to. But it's very tempting to
choose a battle tank when all you need is a sedan to get you from home to
office.

Angular has it's own use-cases, but for the most part what I observed was that
you could get a lot of mileage without using Angular, with just plain
Jquery+Knockout (or any other similar framework of your choice) for most of
the front-end.

In a simple calculation that I made (to pitch to my client), I estimated about
easily 25% of time (and thus money) savings by not going with Angular for our
project. (YMMV)

Usually I tend not to open my mouth about/against angular here because most
HNers seem to like Angular a lot and they downvote without a reason just for
having a different opinion. But, I am really glad someone wrote a blog post
about this.

~~~
electrotype
Don't be afraid of a downvote from me. Personal opinion, with content, like
yours is _the_ main reason why I read Hacker News.

~~~
neya
Thank you for your kind words =)

------
randomdrake
This mayaswell be titled: "Why we're paying for re-discovering client-heavy
apps are hard or bad." Angular, or <insert hot new JavaScript framework>
doesn't particularly matter.

Twitter learned it[1].

Lots of us learned it when we were experimenting as Web 2.0 was being born.
Things were far more obvious, far more quickly then, as bandwidth and
resources weren't anywhere near what they are today. Back then, we quickly
realized that just a couple of delayed asynchronous calls could cause your app
to slow to a halt and feel sluggish.

That's not to say it can't be done[2], it's just to say that, thus far for the
most part, folks end up discovering reasons why they didn't "do it right" too
late over and over. I could be wrong, but I feel like there's been a few posts
to Hacker News within the past couple months with similar sentiment.

When people start suggesting client-side rendering, I usually ask something
along these lines:

Why on earth would you leave something as simple as textual document model
creation up to the client's 5 year old machine that is busy playing a movie, a
song, downloading a torrent, doing a Skype call, and running 15 other tabs,
when your server is sitting around twiddling it's thumbs with it's 8 cores,
scalable, SSD and memory-heavy architecture?

[1] - [https://blog.twitter.com/2012/improving-performance-on-
twitt...](https://blog.twitter.com/2012/improving-performance-on-twittercom)

[2] - [http://www.quora.com/Web-Development/What-are-the-
tradeoffs-...](http://www.quora.com/Web-Development/What-are-the-tradeoffs-of-
client-side-rendering-vs-server-side-rendering/)

~~~
lifeisstillgood
That Quora link is behind a sign up wall - would you mind giving a précis?

Additionally I have to say Angular (or any client side framework) seems a poor
choice for a consumer facing content driven site. Apps are for actively doing
something - not passively reading. Of am I missing the point

~~~
jsnk
Say goodbye to Quora sign up pop up using
[https://github.com/niftylettuce/block-quora-login-
popup](https://github.com/niftylettuce/block-quora-login-popup)

------
shirro
I need to stop clicking on the "why we left x for y" articles on HN. Mostly
people have picked the wrong tool for the particular job and the articles are
just an embarrassment.

Obviously SPAs take a lot of extra work to make search engine friendly and are
probably going to be the wrong tool for the job for any site which requires
that. Much of the web isn't searchable and doesn't want to be searchable. If
you are writing a web app to solve some business problem which sits behind a
login angular really isn't a problem.

Think of the millions of poorly maintained and inflexible VB and Java business
apps out there that are due to be replaced and the employees who are wanting
to do business on the road with their macbooks, chromebooks and tablets. There
is your market for Angular.

~~~
prottmann
The Problem is that most of the people only read about "the new fancy JS
frameworks" and then they choose it too.

Most articles are so optimistic (because it is new, cool, make fun), that is
hard to understand if the "tool" is the right one or not, you see it when you
use it.

So i am glad to see when people / companies write about their expierence with
the "new" technologies. Everybody can then verify if the tool is the right
tool for a project/problem or not.

E. g. you write "If you are writing a web app to solve some business problem
which sits behind a login angular really isn't a problem". When somebody read
this, this person thinks "cool, angular is the right tool for a login backend
application".

------
Cthulhu_
> 3\. Slow, complex build tools

Slow... depends on what you're used to; I've worked with Java / Maven and
such, and one step worse, Scala; if you want slow, go for those.

Complex. The author links to a certain gruntfile[0] as an example of a large,
unmaintainable gruntfile, but apparently people forget that a gruntfile is
just a Javascript / NodeJS file, and thus can be broken up into more
manageable chunks - like any code[1]. Alternatively, there's newer, less
config, more code build tools like Gulp.js[2].

#4 is also no longer valid; Angular's Protractor[3] wraps around Selenium etc
and deals with angular's asynchronous behaviour, as long as you stay within
angular's framework.

And #5 is to be blamed on the developer for not having attention to
performance / total load times, not the framework.

I'm defensive, but then, I don't have a public-facing app.

[0]
[https://github.com/ngbp/ngbp/blob/v0.3.1-release/Gruntfile.j...](https://github.com/ngbp/ngbp/blob/v0.3.1-release/Gruntfile.js)
[1] [http://www.thomasboyt.com/2013/09/01/maintainable-
grunt.html](http://www.thomasboyt.com/2013/09/01/maintainable-grunt.html) [2]
[http://gulpjs.com/](http://gulpjs.com/) [3]
[https://github.com/angular/protractor](https://github.com/angular/protractor)

------
carsongross
I've been working on an Angular alternative called IntercoolerJS:

[http://intercoolerjs.org/](http://intercoolerjs.org/)

The idea is to keep a lot of the advantages of the traditional web development
model, but, via HTML5-style attributes, RESTful URL design and partial driven
UX, achieve a better UX.

It's not for everyone or for every problem, and it is still in pre-alpha (we
are going to change from a preamble to HTTP headers for meta-directives, for
example) but, if you find Angular too heavy-weight and foreign for your UI, it
might be of interest.

Please contact me if you are interested in contributing.

~~~
srgpqt
I think this method is the way forward for most document based sites/apps.
Last year I built something similar to intercooler (nice lib btw) for our
product to great success. Makes things _so much simpler_ to develop and
maintain.

~~~
carsongross
Thanks man. Please, clone. I barely have any idea what I'm doing. ;)

------
dlau1
Have you tried react.js [1] ? If you use node to serve your content, you can
pre-render the initial state of your app. When everything loads up, react will
take a checksum of the rendered portions to ensure that it doesn't re-render
the same DOM. This should come close to solving your SEO/test issues with
minimal work.

In my opinion, a setup like this is close to what the next big wave of
frameworks will use.

You can break your layout up into parts and have a site that is partially
dynamic and partially static. You just pass the html that react renders to
your templating engine.

Getting everything setup correctly can be a little hassle, but gulp is fast
enough when doing a watch on the compilation step. Of course, because
everything is javascript you share the exact same component code between
client and server.

This is a good example that helped me a bit[2]

[1] [http://facebook.github.io/react/](http://facebook.github.io/react/) [2]
[https://github.com/mhart/react-server-
example](https://github.com/mhart/react-server-example)

~~~
sqs
Haven't tried it, but I heard great things about it from bradfitz, who uses it
on [http://camlistore.org/](http://camlistore.org/) (and whose opinion
definitely deserves respect). Is React an all-or-nothing thing, or can you
sprinkle it in certain places on your site without needing to make the whole
site in React?

~~~
dlau1
The great thing about it is that you can sprinkle it in just where you need to
have some dom manipulation.

TBH, a lot of sites really overdo the client-side rendering thing.

------
taude
One thing people don't really think about is that this whole notion of SPA is
kind of a pipe-dream, overkill. There might be some apps that are really a
single page application (likely just those simple, demo add task apps), but
most really can be broken down and composed of many mini-applications.

For example, how often do your users go to their settings page? Does that need
to be part of the SPA? Have a complex Settings pages that's composed of 5 or
six tabs and 20 different user interactions? Maybe the settings page is itself
it's own mini-SPA

How does a user flow through your app, do they really need every screen
bundled under a single SPA?

Routing issues, complexity, code dependencies, etc...are all good reasons to
not make one monolithic application, even if it's behind a login.

Likely your SPA should really be an app composed of a bunch of smaller SPAs.
You search functionality...mini app, your separate workflows...a mini app,
your timeline...mini app. history view...mini app, etc...

Breaking your app down into a bunch of smaller SPAs has a lot of advantages
and implicit modularization, as well as productivity gains when working on
bigger projects with bigger teams.

~~~
hrayr
This is exactly how I'm planning to architect my front-end code. Is Angular
ideal for such environments or are there better suited frameworks.

~~~
taude
I have one project using Angular in this manner, and it's great for it (I
don't use Angular's routing system). Another project is using Knockout.JS. I
prefer the Knockout method when integrating with a lot of 3rd party/external
JQuery components.

In general for a Web apps, you won't go wrong using different pages as a
module system. It's proven and when your app gets big enough, you don't
necessarily have to worry about a huge up-front download.

BTW, if you develp web apps to be shimmed into native apps, like PhoneGap, or
something, then definitely look into the routing aspects of these libraries.

------
danabramov
We're using Backbone+React so this may not be applicable.

However...

 _“You can separate your dev and production build pipelines to improve dev
speed, but that’s going to bite you later on.”_

In my experience, you _must_ separate dev and prod pipelines. It has never
bitten me because I make hundreds dev (local) and dozens kinda-prod (staging
server) builds a day.

For dev builds, Grunt just compiles LESS but doesn't touch the scripts so
there is literally _no_ delay there. In dev environment, we load scripts via
RequireJS so there is no need to maintain a properly sorted list of scripts
too.

For production, we concat them with grunt-contrib-requirejs with `almond:
true` so RequireJS itself is stripped out completely. Production build takes
time (10 to 15 seconds; we're also running Closure Compiler), but it's never a
problem.

Even adding JSX (Facebook React) compilation didn't cause a slowdown for dev
builds because grunt-contrib-watches compiles them on change and puts into a
mounted directory.

~~~
sqs
Yes, we did use separate dev and prod pipelines when we used AngularJS. (We
used [https://github.com/ngbp/ng-boilerplate.](https://github.com/ngbp/ng-
boilerplate.)) It took 2-3sec for the dev build (most of which was taken up by
recess) and 30-45sec for the prod build (primarily JS uglification). However,
probably 5-10 times we deployed a broken site because either 1) the LESS
compiler changed the order of our CSS rules or 2) we used AngularJS DI syntax
somewhere that ngmin couldn't handle. We fixed the issues and added better
linting, but it's still one more thing to think about (and the theme of this
article is that it was death by a thousand cuts, not one big show-stopper).

~~~
vladgur
Im curious which DI syntax couldnt be handled by ngmin?

I made it a rule to use the square bracket notation for angular DI and that
obviously takes care of any minification issues.

~~~
sqs
For us, the most common case was non-square-bracket DI syntax in the "resolve"
values of Angular UI-Router[1] route definitions.

[1] [https://github.com/angular-ui/ui-router](https://github.com/angular-
ui/ui-router)

~~~
vladgur
good to know. Im sticking to my square-bracket syntax :)

------
jbeja
I am curious to know why you go for a full js app approach from the begining,
knowing that your app would be very dependable from content that needed be
indexed by search engines overall?

~~~
sqs
(OP here) This was definitely a bad choice on our part (my part, as I'm the
one who made the decision originally). It was super simple to get started with
AngularJS, and I had a fair bit of experience with it. Part of the motivation
for this post is to tell other developers in a similar position (who have used
AngularJS/Ember/etc. in the past and are starting on a new project) that they
should consider server-side generated pages as well, even though they are
often considered old-fashioned.

~~~
mbesto
Hey OP! We did the same _EXACT_ thing as you. Our end user experience was
super slick using Angular, but this doesn't bode well for things that, well,
aren't users (we migrated back to Rails). Your post looks like it got HN-
hugged so I can't read the whole thing. Either way I'd be happy to share (so
we can compare/contrast) our own findings and conclusions via email. As you
said, educating other developers is great!

------
jaunkst
I have to disagree with most of this article. 1\. Bad search ranking and
Twitter/Facebook previews Don't force your public side to strictly angular.
Serve normal pages and use angular for your interactive components. Let Google
index a well formed dom. Use a full angular stack for your non public facing
application(a SaaS application). You don't want to index this anyways.

2\. Flaky stats and monitoring Use event driven metrics from your api and or
client side. Track everything in the sense of user, controller, action,
params. Blacklist sensitive data. Derive metrics with funnels, user did x
actions, returned and subscribed. Conversion! It's all there just understand
your events.

3\. Slow, complex build tools. Your not limited to grunt, or node. For example
we use rails and use our own buildscripts and generators to build fullstack
angular apps. Easy Breezy.

4\. Slow, flaky tests There is room for improvement. But jasmine and phantom
can get the job done. But let's not forget were also testing our api. Use your
goto testing framework and let jasmine phantomn do the client frontend
testing.

5\. Slowness is swept under the rug, not addressed Precompile your angular
templates, only wait for api responses. Don't fragment your page load into
seperate request. Resolve all the requires data beforehand in the route
provider.

~~~
jaunkst
Would also note angular isn't for everyone or every project. But when you do
its priceless.

------
Eric_WVGG
I’m as big an Angular evangelist as anyone, but that bit about search rankings
is an absolute killer.

You talk about these server-side webkit parsers as tricks that “slow things
down,” which indicates that you at least ultimately got them working. I never
got that far.

~~~
untog
As someone who is familiar with AngularJS but hasn't used it much, the idea
that the best answer running WebKit on the server, indexing your client-side
generated pages and dumping them out into a Google-indexable static resource
just _blows my mind_.

~~~
cozuya
What's really interesting is that "google" didn't see this coming - they made
angular, they should in theory be huge advocates of SPA, but in reality their
primary product doesn't support it well at all.

~~~
onedognight
Googlebot renders client side JS just fine. Notice how the OP didn't list them
and instead listed FB/Twitter.

------
kirushik
For sake of correctness — recent versions of Phantom.js are not dependent on
Xvfb or any other variant of X, and there are grandmotherly prepared binary
builds on the official website (kinda statically linked, so no dependency on
WebKit as well). Not that it changes the author's arguments that much, but
just worth pointing out.

------
cies
I'm currently playing with Fay (haskell2js compiler)... It's awesome.

It type checks like haskell and allows code sharing between serverside and
clientside of the app. This means i can use code to generate a complete HTML
site (for SEO purposes) when the URL is hit directly and modify the DOM from
there once the app is loaded... with the same code!

Obviously this is code sharing is mostly interesting to app written in
haskell. But I'm so excited about it that i had to share... :)

G'luck! The "javascript problem" (try google for that) is a hard one.

[edit] i call it "playing with Fay", but im certain this will end up on
production for me.

------
colemorrison
I used AngularJS + Express for a reasonably sized custom news app for a
client. It does everything form payments, to security, ya know, all the
shebang.

I agree with is the first but only if you're still in the days of SEO
trolling. Frankly it's just not as important if you're doing your other
marketing aspects right.

For #2, I think there are plenty of ways to build in analytics. We use
angularlytics and it works pretty well. Took me like 5 minutes to setup.

#3 - Yeoman. Generator Angular. Here's how I do it:

1\. Make a client dir, and yeoman up your project with generator angular. 2\.
Make a server dir and setup an express server. 3\. Grunt serve your client dir
4\. Make it so express watches your .tmp and app folders for local dev 5\. Run
your express server 6\. When your ready to serve it, Grunt build to a dist
folder in your server folder 7\. For production, have express serve the dist
folder

Yeah kind of dirty (since you're running two local servers for dev), but hell,
it's fast as can be to setup and a pleasure.

#4 Tests? If you're doing tests of any sort, they're bound to slow you down to
an extent.

#5 Isn't this applicable to all web apps? Mistakes and mismanagement of
loading resources is a problem for anything.

Sure it has it's problems, but there's just far too much productivity to be
gained from using it. For example, Ajax animations are beyond time saving.

The real problem with angular is the terrible docs ;)

------
DigitalSea
Really, this seems to be more of a case of the wrong tool being used for the
wrong job than a tool with flaws and no real use. AngularJS positions itself
as a fit-all solution for great Javascript based applications, when in reality
it is meant for use only in an authenticated user setting. Look to an
application like Asana (built on a similar internal Javascript framework), you
only get the Javascript application version after you've logged in, not
before.

It's like creating an online store and deciding to choose MongoDB or any other
NoSQL branded database and then discover it doesn't support transactions and
having to move over to a RDBMS like MySQL or PostgreSQL. The caveats listed in
the article are definitely true though. As someone who's used AngularJS enough
to know its downfalls, it's definitely not a one sized fits all solution and
much like anything it comes with both its own pros and cons.

It's important you spend the extra amount of time when planning your project
to ensure you choose the right tools for the right job (well at least at the
time). If your requirement is to be indexable via search engines, choose a
solution that allows that and so on. Don't use something just because it's the
flavour of the day on the HN front-page.

------
mcgwiz
This is perplexing to me.

> 1\. Bad search ranking and Twitter/Facebook previews

This problem is patently obvious to the most cursory examination of single-
page applications. If SEO is important, and you want to do an SPA, then you
must be willing to bear the cost of addressing HTML requests. For my startup,
I wanted to keep things DRY, which lead me early on to the Nustache engine for
ASP.NET, allowing me to use the same Mustache templates on server and client.
This doesn't have anything like the complexity described in the article.

> 2\. Flaky stats and monitoring

Simply not true. Using Google Analytics and Backbone, you simply listen to the
Backbone.history:route event and fire off a pageview using the Google
Analytics API.

> 3\. Slow, complex build tools

Complex, yes. Slow? Using r.js, no slower than a typical static language
build.

> 4\. Slow, flaky tests

Slow, yes, but no more so than desktop app test automation. I've found
PhantomJS with QUnit (unit-testing), and CasperJS for integration testing to
be quite reliable. It took a few days to get everything connected (scripting
IIS Express to start and end in the background being the trickiest bit), but
that was it.

> 5\. Slowness is swept under the rug, not addressed

This is a UX challenge that is known and obvious up-front. Failing to address
it is a design problem, not a technological one.

Overall, this seems the result of the ineptitude prevalent in inexperienced,
"move fast, break things" teams. Rather than owning up to moving too fast and
foregoing due analysis/research, they blame technology. Or, the article is a
marketing ploy.

~~~
calaniz
This a thousand times. I read the article and thought it a little weak on
perspective. I've used Mustache+Backbone+Require.js stack like the one you're
alluding to and it worked quite well together.

------
balls187
This isn't about AngularJS in particular. This is about using a client-side JS
app framework.

Substitute any other flavor and the same problems exist.

~~~
CmonDev
The problem is using languages designed for animated rich documents for GUIs.

------
taude
I, am/was a big fan of Angular, but on a recent project decided we didn't have
the right team composition for a lot of the coding styles and complexities
angular introduces. We went with a JQuery/Knockout solution, too. Some of the
devs still struggle to keep the viewmodels clean, but being able to integrate
from knockout to existing JQuery plugins has been a big win. Writing custom
angular directives, adding another layer to existing Jquery is a pain for a
lot of front end developers, and likely overkill for many projects.

(to give scope size, we're replacing a several hundred screen Adobe Flex app
with our new KO/JQuery app)

------
akbar501
This is really a case of picking the wrong tool for the job. __This is in no
way a slight of the author__...b/c I have done worse on more than one
occasion, so thanks for sharing.

To anyone reading, you really should understand your workload before picking
tools. And, you need to understand the difference between Web Application vs.
Web Site: Which are you building?

Server-side rending is the winner for content sites (as mentioned by the
author). Beyond initial rendering, a server-side solution allows for more
caching. Depending on the site you could even push a good amount of file
delivery to a CDN. In the end the author switched to Go, but Node.js +
Express, RoR, PHP, Java with Play, etc. would all work just as well.

Next, are you CPU bound or network bound or I/O bound. If you're writing an
application that requires heavy calculations that utilize massive amounts of
CPU, then pick the appropriate framework (i.e. not Node). If you are I/O bound
then Node may be a great solution.

Client-side rending (such as Angular/Backbone/etc) really shine when you need
a web application (not web site). These frameworks are best when the
application code is significant relative to the data such that many small JSON
requests deliver better overall performance. Think of a traditional desktop
application or native mobile app where the application code is in MB, but the
amount of data required per request is in bytes. The same logic applies to web
apps.

A few areas where problems such as what the author experienced emerged from
blanked statements about technologies:

1\. Gulp vs. Grunt: I use Grunt. I may switch to Gulp. But seriously, which
one is "more complex", "faster", can be quantified. Lots of people pick the
wrong technology because the web is littered with echo'd opinion statements.
Exchange "more complex" for project A has a config file with X number of
lines, while project B has a configuration of Y number of lines for the same
task. Or project A uses JSON for its configuration while project B uses YAML.

2\. "Or we could have used a different framework) - with a link to Meteor" \-
No please do NOT use Meteor for your site. I love Meteor and want it to
succeed, but it is not the optimal choice for a content heavy site where each
user views a large amount of data. As mentioned above, use a server-side
rendering solution (like you did with Go), then cache, then push to a CDN.
Problem solved. Meteor is awesome and is a great real-time framework. Use it
when you need real-time capabilities...but not for a content heavy, static
site.

> but they just weren’t the right tools for our site.

This could have been the title or first sentence and would have delivered 100%
of the message if the reader read no further.

A lot of these articles about why we changed from technology A to B could be
much improved if the original decision making was documented (not just the
switch). As in we picked project A because we thought it would deliver A, B
and C benefits based on our applications required capabilities. However, our
application really needed capabilities M, N and O, which project A was not a
good fit for. So, we switched to project B and experienced the following
improvements. Therefore, it can be concluded that if your application needs M,
N and O then project B will be a better fit.

~~~
nathancahill
> "Client-side rending (such as Angular/Backbone/etc) really shine when you
> need a web application (not web site)."

This, 1000x over. I have static landing pages and about pages for search
engines, but the app itself is a single page Angular app. The data does not
have to be indexed.

~~~
mcv
Exactly. And if you're going to use it for a content-driven site, don't use it
to serve up content, use it to make a nicer UI around the content. And if you
do use it to serve content, make sure that content is also accessible through
a direct URL of its own, so you can show that to Google.

Though Google is cheating here, of course. They use plenty of JS frameworks to
serve content, yet those Google+ posts do show up in my search results. Though
every G+ post does have its own URL, so I guess that's the way to do it.

------
RRRA
With all this discussion about SPA websites:

Is anyone aware of a solution to allow clients to validate a version of an SPA
website (cryptographically), in the sense that once downloaded a signature is
checked and then further visit, if they require an update, have to be
validated and verified by the user?

I'm thinking of a way to allow user to trust their applications in the same
way you would trust a dist-upgrade on Debian via the packager's PGP signature
and chain of trust.

This would solve the current problem that sites can change user side code at
will anytime without them knowing and thus making it quite impossible to
develop proper security solutions where the user actually owns and is
responsible for his own security.

With such a solution in place, we might start seeing proper p2p/webrtc
security related apps, we could even imagine an in Browser (read js) Tor-like
service...

------
ben336
Maybe I'm missing something but I don't get "4\. Slow, flaky tests". I
understand that Selenium et al can be a pain, but how does server side
generated code excuse you from using it? Are you only validating the html
structure and not testing any of the interactive capabilities?

------
ChikkaChiChi
Until Web Developers stop treating the end-user as a consumer of unlimited
computational and bandwidth resources, issues like this will continue to crop
up.

I love AngularJS for internal desktop tools I write, but I would never use it
or any other client rendering script in the wild where my applications could
be consumed by unknown form factors. Specifically, you have absolutely no idea
how much memory allocation you are getting when you are dealing with mobile
devices, and any assumption on the developer's part is asinine.

AngularJS was not the problem in this case; and I'd wager we are going to
continue to see articles like this as developers go through growing pains of
learning that you should optimize for the end user first, not yourself.

------
m0th87
Try prerender [1]. We use it in production with backbone. This combined with
keeping the most content not-client-rendered has alleviated most of our
issues.

In the long-term I'd love to see a web framework that uses react on the
server-side, kind of like how rendr uses backbone on the server-side [2].
Seems to make sense because react works against a virtual DOM, so it would
allow you to avoid the hacky ways of working with an actual DOM in node.

1:
[https://github.com/prerender/prerender](https://github.com/prerender/prerender)
2: [https://github.com/airbnb/rendr](https://github.com/airbnb/rendr)

------
wheaties
I just want to say thank you to the author for showing me backbone.anayltics.
Absolutely fantastic and everything I had been looking for recently. Funny how
one thing teaches about something else.

------
laureny
Since the author hints that they migrated to Go templates, this article is
more about when you should render templates client side vs/ server side than
an opinion against AngularJS.

------
Kiro
> 3\. Slow, complex build tools

I'm building a big AngularJS app and I'm not using any build tools. Apart from
minifying, what would you use it for?

~~~
notjustanymike
Concatenating your large collection of controllers, services and directives.
Running internationalization jobs, running unit tests, running JSLint, running
LESS compilation. Creating a versioned file so you have a fallback. And more!

~~~
nXqd
Sometimes, we just create our own problem. I fell into that trap before, and
my toolbox is more minimal now. And btw, gulp is a better replacement for
Gunt. But still, consider adding too many plugins into it before it's too
late.

------
ilaksh
Take a look at the prerender.io module. Also it is not impossible to render
some types of angular pages in the server it is just a bit of a pain. Google
angular on server. If you really don't need an interactive app then I would
consider generating static pages when the data changes or when called and then
don't update them more often than you actually need to.

------
JDDunn9
These are just difficulties that need to be addressed, not deal-breakers. All
new technologies have a transitional period where the rough edges need to be
sanded off (Node.js, HTML5, etc.). As for people making comments that SPA
should only be made for back ends and never a content site, USAToday.com is a
SPA, and they rank just fine in Google.

------
jasdeepsingh
I think you just used Angular at the wrong place. For a content based site,
Angular was just not the right choice. I've made similar decision on a content
site which I did in BackboneJS and totally feel your pain. I've had exactly
the same problems you mentioned.

Server side generated stuff would've been just great here or on the project I
did!

------
davesque
This post's title should really read: "Why we left single-page apps." Saying
that they left Angular makes it sound like it's somehow inferior when compared
with similar technologies like Ember. As the article describes, Angular was
not so much the problem as was the mis-application of the single-page app
architecture.

------
robmcm
> 5\. Slowness is swept under the rug, not addressed

This is a joke right, asyc loading is somehow bad? If it's that much of a
problem hold off rendering untill you have all your data back, of heaven
forbid implement item one of Nielsen's list of heuristics, "Visibility of
system status" and chuck in a loading gif.

------
blueskin_
Javascript-only sites are the equally hideous 2010s equivalent of the Flash-
only sites of the 2000s.

------
Navarajan
Yes Client side rendering will not give any advantages for static contents,
Its more useful for Dynamic content providing applications.

And if you want to deliver your content in mobile devices with there native
app then Client Side Framework will be handy for you.

------
mavdi
Yeah let's stop the progress of the web because SEOs aren't getting any
better.

------
deaquino
Just noticed that you can't search on your website if you include '(' or ')'.
500 Internal Server Error.

i.e.
[https://sourcegraph.com/search?q=%28](https://sourcegraph.com/search?q=%28)

------
fantastical
Are there any good guides on how to organize JavaScript on non-SPAs? I have a
weird web development background in that I've only ever worked on SPAs, so I
haven't ever done JavaScript work on a server-side rendered app.

------
seba_dos1
If you describe something as "a content site", then implementing it as
"single-page app" is ridiculous by definition.

Content site is not app. Single-page app frameworks are for apps, not for
content sites.

------
Illniyar
All these arguments seem like lowly excuses to not do proper work and instead
blame the framework you are using. If you have any kind of interactiveness the
feel of a fat client is so much better then template rendering.

Look at the site: [https://sourcegraph.com/github.com/tomchristie/django-
rest-f...](https://sourcegraph.com/github.com/tomchristie/django-rest-
framework)?

Is that the best interface you can get? In 2014 everything I click reloads the
page? a tabbed interface that doesn't load the content in the window is
noticeable by users these days. No pop ups of any kind? why do I need to
reload the page to see a list of 4 contributers. You've gained maintainability
at the cost of user experience, a lot of user experience for very little
maintainability.

There are sites that benefit little from client-side rendering- blogs and news
site for instance, but most will gain a lot.

1) Indexing with PhantomJs is a breeze, truely. Not only are there a ton of
libraries that already do it, there are even SAASes that will do it for you
for a fee. If you are really unable to come to terms with this, you can use
react.js, which solve the SEO indexing issue completely.

2) If the only thing that you are doing on the site is measuring page loads
then your site either lacks interactiveness completely or you aren't measuring
everything you should. You aren't measuring to where a user left your site
(and incredibly important metric) or any action he does (assuming there is any
he can do) that isn't navigation.

With Angularytics (and a thousand other libraries) adding analytics is maybe 5
lines of code, and you get declarative analytics on any link you want.

3) This site's js is neither minimized nor concatenated, so I'm not sure what
build tools you need for angular either then the ability to serve static
content? But in any case it's js, you are going to need to minimize and
concatenate it at some point for performance, doesn't matter if you use a fat
client or some custom jQuery plugin. Even with Grunt, though I don't like it
very much, the build file is maybe 10 lines long, and the build process takes
miliseconds.

4) And the alternative is what? using manual QA on every build? You have a
website with even minimal interactivity you are going to need to use a browser
based testing solution. Karma is a breeze, and with the new setup, the only
thing you need to install is node and karma. Takes exactly 3 seconds, and you
get one of the best isolated unit testing framework for client side code.
Angular is actually built around the ability to unit test it.

5) So your saying that the solution to slowness is to have 43 unique resources
loaded and rendered on every navigation? Page reload slowness is one of the
major hassles that Ajax, and fat clients as a consequence, are trying to
overcome. Your site takes, to me, about 3 seconds to load from page to page (6
seconds to finish rendering), there is obviously no wait time indicator that
you can add and no tricks to minimize this. Not to mention that rendering is
slow, and server-side rendering is not only extremely slow it can also cause
parallel load which will make things worse. If you don't care about your speed
it doesn't matter what framework you use.

For the sake of this you are losing interactiveness, speed and lower bandwidth
to name just a few.

~~~
Bahamut
Using PhantomJS to prerender is not a viable solution for everything - for
example, fast updating content like forum threads.

~~~
Illniyar
Why not? it's not like google and other crawler bots crawl your site every
second, we are talking about roughly once a day.

And even then, there are solutions to do PhantomJS rendering on the fly, it
might be a bit slower, but shouldn't be drastically so - some of the SAAS
solutions I mentioned already provide such an option.

------
usablebytes
It was a wrong choice of tool for that kind of a project, in the first place.
The biggest problem that I've personally seen with AngularJS is the steep
learning curve.

------
planckscnst
I honestly don't get what Sourcegraph is useful for. They primarily seem to be
cluttering up my Google results, with pretty much useless entries.

------
ishener
the crawling issue is simply a deal breaker. try searching in google for
something in angular docs - and you'll see what i mean...

------
scottschulthess
"Slow tests"

Our javascript tests suites are always much, much faster than our server-side
test suites with similar coverage.

------
kin
Wouldn't ng-cloak solve the partial content loading issue? Actually, there are
a ton of ways to skin that cat.

------
Sym3tri
This article unfairly picks on Angular. The issues mentioned are the same for
any rich single page app.

------
sassyalex
This is exactly the same problem with other client side javascript frameworks

------
miralabs
just a case of using the right tools for the right job...move along

~~~
filipedeschamps
Pardon me, but what does this have to do with Angularjs?

------
andyl
We've transitioned from Angular to ReactJS with great success. Much smaller
learning curve. Using Backbone to handle the models and React for the view is
a great combination.

~~~
dustingetz
one thing React by itself can do that React+Backbone.Model can't, is handle
oddly shaped state. Which is almost all of your state, once your application
becomes nontrivial.

[http://jsfiddle.net/dustingetz/YUCBT/2/](http://jsfiddle.net/dustingetz/YUCBT/2/)

~~~
porker
Sorry, what is your fiddle meant to show? It's not clear form the source what
problem you're illustrating.

