It's funny because I find myself going the other direction from server-side page generation to angular.
One of the main reasons is angular forces you to separate your controller logic from DOM manipulation. Without directives I tend to see a pile of jQuery on every page.
The separation between DOM and logic is indeed a nice part about AngularJS. We took a look at how much client-side logic our particular site actually needed, and it was much less than we thought. Most of the page logic can be implemented using Go's template library's own AngularJS-like server-side templates. We implemented the remainder in jQuery, which you can see at https://sourcegraph.com/static/js/web.js. (If someone in the future comes along and that link is 404, email me at sqs@sourcegraph.com if you want to see it.) It's actually a surprisingly small amount of code.
So I would say you should ask yourself how much of your controller logic needs to be done on the client? If most of it can be done on the server, then the amount of jQuery you need will probably be quite manageable.
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.
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.
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.
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.
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.
The angularjs.org sites are indexed, just by using a trivial nginx directive to selectively serve partials to crawlers. All of the angularjs.org apps still rank fairly well using this strategy.
This isn't always appropriate of course, those apps aren't really relying on data from a database, they're proper SPAs. But as noted by others, there are ways to fool crawlers if it's something you want to do.
Generally though, the feeling is that crawlers not executing JS is going to end, and the problem will go away on its own.
If you're OK to delegate the scraping process to a SaaS then you may be interested by SEO4Ajax [1] which will make it much simpler. Disclaimer: I'm one of the co-founder.
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?
(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.
Thank you for sharing your experience, and i hope that this post teach people a lesson about context (e.j: in your case you were using the wrong tool for certain context), consider that either serve-side or client-side rendering are not competing to each other to claim which better, it always "depends" on the context that they are implemented and lastly that server-side redering is not something that should be percieve as "old-fashioned", there is a duality between the two techniques that address specifics problems and is our job to choose what is best for the job.
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!
I'm well-versed in Angular, and I too made that mistake on one project as well. There's something to be said for picking the right tools for the right job.
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.
Most websites shouldnt be SPAs. One can still use Angular to code widgets in a regular page based site,without using a js router.
It's just that devs are getting lazy ,they throw a restfull server app quickly then dont want to deal with any view layer on the server and do everything in client-side js. For some projects it make little sense.
I think the key word is "App." There is a difference in nature between a web app and a web page. Both can be built using the same underlying technologies, but the goals are very different.
Knowing which one is building can greatly inform choice of framework.
Agreed - there is a wealth of applications that are not in the massive scaled consumer market - and making those clean, easy to maintain and deliver is an enormous win. That said, there is a wealth of consumer apps that don't have massive market shares either so the market for learning these lessons is pretty rarefied
Any sort of standard server side rendering, or possibly a front end framework that can be rendered server side as well (I think React can do that, same as Backbone).
Basically, SPA frameworks are useful when you are working with lots and lots of data moving back and forth. A good example is something like Intercom.io's interface. They have tons of tables and modals and data flying around. This isn't conducive to the standard browser request -> server render -> load whole new page on the client. It's just too slow. When you're interacting purely with data in a master interface, SPA frameworks are the way to go. And it isn't even a matter of literal page loading and rendering speed, it's the fact that refreshing the view with a whole new page on each link click is a context change that adds up when you're managing a lot of data or performing a lot of small tasks in an application.
But something like Blogger, where you're reading just some content, maybe some comments...there's no real benefit from loading it in a SPA environment. Render it server side, cache it, and fire it to my browser as fast as possible.
> Render it server side, cache it, and fire it to my browser as fast as possible.
Shameless plug, but we've been trying to do something similar with Forge (getforge.com). We built a Javascript library called TurboJS that precompiles a static HTML build into a JS manifest and loads it all. It's SEO-friendly and super-fast. Our other site, http://hammerformac.com/ uses it, for example.
Precompiling static HTML is a strict sub-problem of the problem most people in this comment thread are referring to, which is development incentives and SEO characteristics for web pages that have non-trivial amounts of dynamic content.
I've started using PJAX where the rendered page does not have to change when its source data does, and where you don't have large tables/calendars that would have to be re-rendered when one data value changes.
Development is significantly faster, less error-prone, easier to maintain. Development can also be given to people with lower skill levels.
"node.js + express + jade" is a fairly common stack, you can even try to move an existing complex angular.js code there because it's written in the same language
Discourse is essentially a SPA (see http://try.discourse.org/) and designed to be public-facing. It does a good job at providing a very bare, lightweight interface for people with JavaScript disabled and, I'm assuming, for web crawlers.
Totally agree, but you still have the analytics/tracking problems. Unless you're not tracking clicks/activities/views on your various features. But if that's the case, you have bigger problems :)
The Blogger example doesn't seem fair: Any app can overload the user with too many animations or other distractions.
At Thinkful (http://www.thinkful.com/) we're building our student / education app in Angular, and are moving all browser-side code to Angular as well – both public and private.
In a lot of our splash or SEO-enabled content we're not making use of all of angular's features, but the upside of using it is that we have a single, unified codebase in which we can share libraries, team knowledge and design patterns. Simply put: Using Angular everywhere allows us to keep DRY. Testing the front-end using purely Angular is yet another core asset at Thinkful.
One framework for writing code and testing is much better than a hybrid of server-side rendering and Angular.
Our biggest challenge was SEO, but this was reasonably easily solved with using BromBone (http://www.brombone.com/).
There are reasons to stick with non-angular or JS frameworks, so it's not always a slam-dunk. For example, if Thinkful had millions of SEO pages that we needed to load as fast as humanly possible Angular would be a bit much... But that's not what we're optimizing for: We're building a phenomenal user-experience that we can support long-term, is well tested, can have a lot of developers use, and can have non-developers do their job inside our codebase (everyone at Thinkful codes).
For all this and more Angular has proven a great choice for both logged-in AND public sites.
I agree that things like blogger are a great example of what not to do, but I'd go further and say that treating something as a single page web app running on the client side throws away most of the advantages of the web:
URLs which can be stored and shared and are idempotent
Mostly stateless operation for anonymous use (fast to serve/load/cache)
Document formats that anything (including dumb crawlers and future gadgets) can parse and reuse in unexpected ways
What you call suboptimal browsing devices are what makes the web special and distinct from native apps. These are not trivial advantages, and most websites would benefit from these strengths of the web, even if they are an app.
As an example of where something like a single page app can shine on a public site, I've seen chat software which used it which worked really well (using socket.io I think), but only because people didn't care about sharing individual messages and the chat was ephemeral.
> Document formats that anything (including dumb crawlers and future gadgets) can parse and reuse in unexpected ways
As in the article, you can use phantomjs to serve up static HTML to crawlers. They are correct in that it does slow you down and add complexity.
The main problem I think is that SPA tech is still immature and getting all the moving parts to build a public facing SPA working together is a time sink.
It's not really a single page application if you are serving separate pages is it? BTW, the page you linked to says 'Uh-oh! Couldn't find that page.' before loading and displaying the content... ouch.
One of the things I love about the web is that it uses incredibly simple building blocks like simple html pages at defined stateless URLs, dumb servers and dumber clients, and builds complex systems through their interaction. I'd be very wary of solutions that drop those advantages.
There are certainly technical solutions possibly to almost any problem with angular or client-side apps in general, but I'm not sure that rendering everything client-side really gives you enough advantages to warrant it for many websites. What do you see as the main advantages to this approach and do you see it spreading everywhere eventually?
Every website is different and what suits (say) a chat application will not suit a document-orientated website at all. There's certainly room to explore both approaches or even mix them at times.
" I'd be very wary of solutions that drop those advantages." They are called native applications. I can think of some useful ones over the years, particularly for people who produce rather than consume. I notice that my Bosch drill isn't available for seo and mashing :) Seriously though, it depends on your perspective. What's wrong with saying I'd like to make a native app but use the web as a delivery/installation mechanism and that's all?
Nothing really, there's room for all approaches to be explored.
I suspect the concept of native APIs (desktop or mobile) will eventually disappear, but it'll be an interesting journey if we ever do reach that point and would take decades.
You make some really good points, but I think simple json documents are much simpler and easier to re-use by other clients in interesting ways than simple html pages. I think the API + client (note, not just traditional web browser) rendering is actually a more "pure" interpretation of what the web can be - data sources and data consumers that interpret and present that data on behalf of their users.
I'm also not sure that rendering everything client-side is advantageous enough to warrant its current popularity (hype...), but I do see some advantages. Firstly, I think it is a better separation of concerns - the server is in charge of data discovery, persistence, consistency, and aggregation, while the client is in charge of determining how that data can be most useful in the current context. In practice, this means it is possible to have different front-ends for the same back-end. Admittedly, that is certainly not always a necessary or desired feature. The separation also makes it easier to build the front end and back end of an application separately from one another, and possibly even in whichever order you prefer. That can be a good thing, though I don't think it's really taken advantage of very often. I also think that true web applications can be made to feel much snappier and closer to native. The line between what should and shouldn't be considered an "application" is unfortunately blurry (the Blogger example is a good one).
I'm not sure it makes much sense to refer to a JSON packet as a "document". HTML is truly meant to represent documents, with embedded semantics. JSON is really meant to represent data or objects in the most abstract sense. It has no notion of embedded semantics.
I think simple json documents are much simpler and easier to re-use by other clients in interesting ways than simple html pages. I think the API + client (note, not just traditional web browser) rendering is actually a more "pure" interpretation of what the web can be - data sources and data consumers that interpret and present that data on behalf of their users.
This is an interesting point - if you are representing numeric data like chart datapoints, a representation like json might make it cleaner and more reusable by other services or clients. Of course much data is actually formatted documents or snippets of text, in which case json is not such a good fit and html is perhaps better. In many ways html is a worse is better solution, but that is probably part of its strength - it is very easy to get started with and munge to extract or insert data.
I'm not sure a separate of concerns between server and client is necessary and helpful to all apps, though I'm sure in some cases it is useful (for example serving the same json or xml to a mobile app, a client-side app and some desktop client, or separate teams working on both), but then a server-based solution can easily output both formatted html for traditional clients (web browsers, which are now and in the future ubiquitous), and a json or xml representation for other clients - this sort of separation of concerns between data and presentation is not really exclusive to client-side solutions.
Turns out I wasn't using Iron Router properly. My bad.
It is a single page application if you don't make your browser reload the page from the server each time you navigate within your app. URLs here are implemented using HTML5 pushState -- the browser isn't loading or refreshing the page when the URL changes, except for the first page load.
My point is you get the best of both worlds there: static, representative URLs that live forever (as they should); and the responsiveness you get when you only need to load data and move some divs around instead of reloading everything from scratch each time.
In fact Meteor takes things even further with latency compensation: it predicts how things will change as you interact with the app and does eventual consistency with the server state. This makes updates/deletes feel even faster.
But yeah, it's a trade off. And right now it's a big trade off -- my productivity has dropped in some places, compared to writing a simple app in express or Rails.
I think the term "Single Page App" is a bit deceiving in usage sometimes. My idea of a SPA is one where the client downloads the bulk of the application code on first page load, and then only talks to the server with data-based API calls (JSON usually). The predownloaded client then just renders that data, rather than downloading an entire new template to render on the whole screen.
This interface style does not require any visual page refreshes to load new content, but it also still can support routing and deep-linking.
Some people use screen readers, text-mode browsers, IE due to stupid work/school policies, etc. Some people like automating their workflow, which can involve scripted browser interactions. Some people actually care about security and privacy, and so run NoScript, etc.
Screen readers and browser automation can run javascript. Sure, it may be more pure and perfect for everyone write websites that don't require javascript, but the economics of building websites doesn't support it.
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.
Haven't tried it, but I heard great things about it from bradfitz, who uses it on 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?
> you can pre-render the initial state of your app
This, I think, is the killer feature of Node, and the reason I'm slowly transitioning from Python for new web projects. You can reuse your server-side templates client-side (without worrying about, say, reimplementing Handlebars Helpers in your server-side language), and can easily render full HTML templates for the client that get enhanced when the client-side JS loads. This also solves UI nuisances -- like your server's markdown renderer being different to your client-side preview (grr).
Meteor and Derby are obviously heading down this path, and while I'm not sold on the rest of Node and the general JS style, having the same language in the browser and the server is too much to pass up.
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.
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.
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.
Yes, we did use separate dev and prod pipelines when we used AngularJS. (We used 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).
I understand how this could be really frustrating. We solved this problem (well, we never really had it, but we solved the ability of this problem to come up) by having a suite of unit and functional webui tests. Combined that with a CI environment that runs these tests and creates builds only when the tests pass. Ngmin can be a little flakey if you get into fringe situations but deploying broken code is a testing problem, not a toolset problem.
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.
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.
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.
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?
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
I was able to read the first answer without signing up.
And I'm not sure I'd say passively reading is something we ever do on the web. Consider nytimes.com redesign -- it uses app concepts for a sidebar while devoting all attention on the prose in front of you. You can even navigate using arrow keys, though that could be improved: first time I do it, use a popup to let me know what happened and how to undo. The point is, the app-ification of the web is upon us, we just have to find language and frameworks that will best support it. Both client-side and server-side are necessary at points.
The app-ification of the web implies one does something with an app. Something that produces, creates or alters - simply having a easier navigation for reading an article does not to me qualify. I already have a very good framework for reading - text and books.
we are going to see a million and one ways of presenting the same article of the same tv show, and one million of them will be crap. the other - who knows. I just hope it's worth living with the million others - I will prefer to avoid them and wait for the one announcement.
To answer that question -- for the same reason you'd prefer mobile apps on a smartphone. Even in resource-constrained hardware, it makes sense to do things client-side if that's less expensive: no need for server communication on some or all of the app, since it can be cached locally. Sometimes your app can be more expressive than a sequential history of documents loaded one page at a time.
Now, do people really think that way when they adopt these frameworks? Nope. I mean, they might think about speed, but we all know that loading a bit of static HTML and CSS is faster than any JavaScript execution.
That said, I'll ignore my point above and get a bit technical here: Unless you're using Opera Mini, client-side rendering is indeed all we have for "textual document model rendering". That's what we call "HTML" folks when we're not "viewing source". So ... I'd give the client-side a bit of credit here, things will improve with time.
Use the right technology for the job. And that advice keeps changing. Right now, I'm most influenced by http://www.igvita.com/slides/2013/breaking-1s-mobile-barrier... but once you've caching/native, it's a whole different game. And if you add pre-fetching...
> Even in resource-constrained hardware, it makes sense to do things client-side if that's less expensive: no need for server communication on some or all of the app, since it can be cached locally. Sometimes your app can be more expressive than a sequential history of documents loaded one page at a time.
> Now, do people really think that way when they adopt these frameworks? Nope. I mean, they might think about speed, but we all know that loading a bit of static HTML and CSS is faster than any JavaScript execution.
You sort of gathered the problem up into a nutshell. People aren't thinking of separating the need for server communication all the way through. They aren't thinking the right way when they adopt the frameworks. They aren't thinking about what they don't know. That's okay, they can't. But, continuing to push the idea that they can is not helping anyone.
Not only is this affecting the actual performance of the app, it's affecting analyzing it, testing it, making it properly available to SEO, and probably other things not illustrated in this common revelation of an article. This isn't just one problem, it's a slew of problems that get so bad that ultimately the entire system needs to be rewritten. If it was just slowness, that'd be one thing, but it isn't.
> That said, I'll ignore my point above and get a bit technical here: Unless you're using Opera Mini, client-side rendering is indeed all we have for "textual document model rendering". That's what we call "HTML" folks when we're not "viewing source". So ... I'd give the client-side a bit of credit here, things will improve with time.
You're right, I should have said "textual document model generation". I've edited my comment as such. The act of rendering the model isn't normally the problem. The problem is that these frameworks rely on the client to turn their representation of the model into something else. They're converting something the browser doesn't natively understand into something the browser does understand, then using the browser to run a whole bunch of commands to generate representations of objects that can then be displayed on the screen.
Wouldn't it be nice if you could've skipped all that and just delivered clear instructions on how to render the information from the get-go?
Listen, SOAP is ugly. We all hate using it. But it's there and it's a standard for shit that matters because humans are fallible. We're not good at knowing what we don't know or how things may change. Every time a shortcut is taken, something else will need to be done down the path to ensure stability of the system at a later date. Often times the cost of that is human intervention.
Developers and big companies discover over and over why the nice and easy:
"Throw up a REST bro, JS that shit in Chrome, and get a back end as a service for the rest. We don't even need to worry about the fact that the server and client are different anymore! We can CODE ALL THE THINGS in one spot and not have to learn anything further! Isn't that great? Can we get our VC money now?"
...isn't sustainable.
Again, I'm not saying that it can't be done. I'm saying that it's really hard, you have to pay very close attention, and you need to know a lot up front.
Otherwise you get stuck trying to fix things you didn't know you didn't know. And you write another one of these blog posts.
Cool. Can't argue with any of the above. And sorry for getting nit-picky earlier.
I'd point to react.js as a framework that encourages fast code while discouraging knee-jerk adoption by calling itself a view layer, batteries not included. Of course, that doesn't help people realise whether JS MVC, PJAX or PHP is the best choice for the job. But it does highlight certain desires for client-side rendering that's more generic than "insert this block of HTML here". Like angular, it's most useful when you need to repeat yourself a few times on a page as each new piece of data has to be rendered in real-time to a page. If static, you should have fewer worries. Usually with JS, if it's easy, you're doing something wrong, or using Dart :p (Okay, the last was tongue in cheek)
That said, I'll ignore my point above and get a bit technical here: Unless you're using Opera Mini, client-side rendering is indeed all we have for "textual document model rendering".
Semantic nitpicking. It's obvious that the grandparent speaks about templating, which can be done both on client and server side.
Honestly, I'm really tired of people who pretend there is no difference between serving up HTML and serving a program that constructs that HTML. The difference is that in the second case you cannot get the content without executing the program written by someone else with all the relevant implications.
Also, people often miss another important fact: server-side rendering can be cached and shared across clients. Client-side templates must to be executed by every client separately.
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.
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.
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".
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.
> "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.
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.
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.
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.
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.
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?
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.
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.
167 comments
[ 3.1 ms ] story [ 162 ms ] threadOne of the main reasons is angular forces you to separate your controller logic from DOM manipulation. Without directives I tend to see a pile of jQuery on every page.
How do you address this?
So I would say you should ask yourself how much of your controller logic needs to be done on the client? If most of it can be done on the server, then the amount of jQuery you need will probably be quite manageable.
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.
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.
This isn't always appropriate of course, those apps aren't really relying on data from a database, they're proper SPAs. But as noted by others, there are ways to fool crawlers if it's something you want to do.
Generally though, the feeling is that crawlers not executing JS is going to end, and the problem will go away on its own.
You can do that, however if you dump static page to Google bot IP only it's an SEO cheating.
https://developers.google.com/webmasters/ajax-crawling/
[1] http://www.seo4ajax.com
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.
Most websites shouldnt be SPAs. One can still use Angular to code widgets in a regular page based site,without using a js router.
It's just that devs are getting lazy ,they throw a restfull server app quickly then dont want to deal with any view layer on the server and do everything in client-side js. For some projects it make little sense.
Knowing which one is building can greatly inform choice of framework.
Basically, SPA frameworks are useful when you are working with lots and lots of data moving back and forth. A good example is something like Intercom.io's interface. They have tons of tables and modals and data flying around. This isn't conducive to the standard browser request -> server render -> load whole new page on the client. It's just too slow. When you're interacting purely with data in a master interface, SPA frameworks are the way to go. And it isn't even a matter of literal page loading and rendering speed, it's the fact that refreshing the view with a whole new page on each link click is a context change that adds up when you're managing a lot of data or performing a lot of small tasks in an application.
But something like Blogger, where you're reading just some content, maybe some comments...there's no real benefit from loading it in a SPA environment. Render it server side, cache it, and fire it to my browser as fast as possible.
Shameless plug, but we've been trying to do something similar with Forge (getforge.com). We built a Javascript library called TurboJS that precompiles a static HTML build into a JS manifest and loads it all. It's SEO-friendly and super-fast. Our other site, http://hammerformac.com/ uses it, for example.
We added PJAX rendering to a Django site in under an hour. All the benefits of SPA's and few of the downsides.
Development is significantly faster, less error-prone, easier to maintain. Development can also be given to people with lower skill levels.
In most cases Node.js is just faster than Rails or Django.
https://github.com/discourse/discourse
It uses ember.js with a Rails backend.
At Thinkful (http://www.thinkful.com/) we're building our student / education app in Angular, and are moving all browser-side code to Angular as well – both public and private.
In a lot of our splash or SEO-enabled content we're not making use of all of angular's features, but the upside of using it is that we have a single, unified codebase in which we can share libraries, team knowledge and design patterns. Simply put: Using Angular everywhere allows us to keep DRY. Testing the front-end using purely Angular is yet another core asset at Thinkful.
One framework for writing code and testing is much better than a hybrid of server-side rendering and Angular.
Our biggest challenge was SEO, but this was reasonably easily solved with using BromBone (http://www.brombone.com/).
There are reasons to stick with non-angular or JS frameworks, so it's not always a slam-dunk. For example, if Thinkful had millions of SEO pages that we needed to load as fast as humanly possible Angular would be a bit much... But that's not what we're optimizing for: We're building a phenomenal user-experience that we can support long-term, is well tested, can have a lot of developers use, and can have non-developers do their job inside our codebase (everyone at Thinkful codes).
For all this and more Angular has proven a great choice for both logged-in AND public sites.
URLs which can be stored and shared and are idempotent
Mostly stateless operation for anonymous use (fast to serve/load/cache)
Document formats that anything (including dumb crawlers and future gadgets) can parse and reuse in unexpected ways
What you call suboptimal browsing devices are what makes the web special and distinct from native apps. These are not trivial advantages, and most websites would benefit from these strengths of the web, even if they are an app.
As an example of where something like a single page app can shine on a public site, I've seen chat software which used it which worked really well (using socket.io I think), but only because people didn't care about sharing individual messages and the chat was ephemeral.
If you use a decent router, you get shareable idempotent URLs: https://solvers.io/projects/7GTeCKo7rGx5FsGkB
> Document formats that anything (including dumb crawlers and future gadgets) can parse and reuse in unexpected ways
As in the article, you can use phantomjs to serve up static HTML to crawlers. They are correct in that it does slow you down and add complexity.
The main problem I think is that SPA tech is still immature and getting all the moving parts to build a public facing SPA working together is a time sink.
One of the things I love about the web is that it uses incredibly simple building blocks like simple html pages at defined stateless URLs, dumb servers and dumber clients, and builds complex systems through their interaction. I'd be very wary of solutions that drop those advantages.
There are certainly technical solutions possibly to almost any problem with angular or client-side apps in general, but I'm not sure that rendering everything client-side really gives you enough advantages to warrant it for many websites. What do you see as the main advantages to this approach and do you see it spreading everywhere eventually?
Every website is different and what suits (say) a chat application will not suit a document-orientated website at all. There's certainly room to explore both approaches or even mix them at times.
I suspect the concept of native APIs (desktop or mobile) will eventually disappear, but it'll be an interesting journey if we ever do reach that point and would take decades.
Photoshop wouldn't work as a website, and HN wouldn't work as a program.
Different forms for different use cases.
I'm also not sure that rendering everything client-side is advantageous enough to warrant its current popularity (hype...), but I do see some advantages. Firstly, I think it is a better separation of concerns - the server is in charge of data discovery, persistence, consistency, and aggregation, while the client is in charge of determining how that data can be most useful in the current context. In practice, this means it is possible to have different front-ends for the same back-end. Admittedly, that is certainly not always a necessary or desired feature. The separation also makes it easier to build the front end and back end of an application separately from one another, and possibly even in whichever order you prefer. That can be a good thing, though I don't think it's really taken advantage of very often. I also think that true web applications can be made to feel much snappier and closer to native. The line between what should and shouldn't be considered an "application" is unfortunately blurry (the Blogger example is a good one).
This is an interesting point - if you are representing numeric data like chart datapoints, a representation like json might make it cleaner and more reusable by other services or clients. Of course much data is actually formatted documents or snippets of text, in which case json is not such a good fit and html is perhaps better. In many ways html is a worse is better solution, but that is probably part of its strength - it is very easy to get started with and munge to extract or insert data.
I'm not sure a separate of concerns between server and client is necessary and helpful to all apps, though I'm sure in some cases it is useful (for example serving the same json or xml to a mobile app, a client-side app and some desktop client, or separate teams working on both), but then a server-based solution can easily output both formatted html for traditional clients (web browsers, which are now and in the future ubiquitous), and a json or xml representation for other clients - this sort of separation of concerns between data and presentation is not really exclusive to client-side solutions.
Turns out I wasn't using Iron Router properly. My bad.
It is a single page application if you don't make your browser reload the page from the server each time you navigate within your app. URLs here are implemented using HTML5 pushState -- the browser isn't loading or refreshing the page when the URL changes, except for the first page load.
My point is you get the best of both worlds there: static, representative URLs that live forever (as they should); and the responsiveness you get when you only need to load data and move some divs around instead of reloading everything from scratch each time.
In fact Meteor takes things even further with latency compensation: it predicts how things will change as you interact with the app and does eventual consistency with the server state. This makes updates/deletes feel even faster.
But yeah, it's a trade off. And right now it's a big trade off -- my productivity has dropped in some places, compared to writing a simple app in express or Rails.
This interface style does not require any visual page refreshes to load new content, but it also still can support routing and deep-linking.
Here's a link with all the nginx config you need to make it work: https://phantomjscloud.com/site/docs.html#advanced_seo
Some people use screen readers, text-mode browsers, IE due to stupid work/school policies, etc. Some people like automating their workflow, which can involve scripted browser interactions. Some people actually care about security and privacy, and so run NoScript, etc.
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/ [2] https://github.com/mhart/react-server-example
TBH, a lot of sites really overdo the client-side rendering thing.
Meteor and Derby are obviously heading down this path, and while I'm not sold on the rest of Node and the general JS style, having the same language in the browser and the server is too much to pass up.
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.
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.
I made it a rule to use the square bracket notation for angular DI and that obviously takes care of any minification issues.
[1] https://github.com/angular-ui/ui-router
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.
Most approaches I've seen use `forceUpdate` although it is arguably more React-ish to [pass along pure JSON][1].
We're currently sticking with passing JSON top-down and calling `renderComponent` when model changes so `props` never mutate.
What is your experience with this?
[1]: (http://stackoverflow.com/a/21710111/458193)
http://jsfiddle.net/dustingetz/YUCBT/2/
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...
[2] - http://www.quora.com/Web-Development/What-are-the-tradeoffs-...
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
And I'm not sure I'd say passively reading is something we ever do on the web. Consider nytimes.com redesign -- it uses app concepts for a sidebar while devoting all attention on the prose in front of you. You can even navigate using arrow keys, though that could be improved: first time I do it, use a popup to let me know what happened and how to undo. The point is, the app-ification of the web is upon us, we just have to find language and frameworks that will best support it. Both client-side and server-side are necessary at points.
we are going to see a million and one ways of presenting the same article of the same tv show, and one million of them will be crap. the other - who knows. I just hope it's worth living with the million others - I will prefer to avoid them and wait for the one announcement.
Now, do people really think that way when they adopt these frameworks? Nope. I mean, they might think about speed, but we all know that loading a bit of static HTML and CSS is faster than any JavaScript execution.
That said, I'll ignore my point above and get a bit technical here: Unless you're using Opera Mini, client-side rendering is indeed all we have for "textual document model rendering". That's what we call "HTML" folks when we're not "viewing source". So ... I'd give the client-side a bit of credit here, things will improve with time.
Use the right technology for the job. And that advice keeps changing. Right now, I'm most influenced by http://www.igvita.com/slides/2013/breaking-1s-mobile-barrier... but once you've caching/native, it's a whole different game. And if you add pre-fetching...
> Now, do people really think that way when they adopt these frameworks? Nope. I mean, they might think about speed, but we all know that loading a bit of static HTML and CSS is faster than any JavaScript execution.
You sort of gathered the problem up into a nutshell. People aren't thinking of separating the need for server communication all the way through. They aren't thinking the right way when they adopt the frameworks. They aren't thinking about what they don't know. That's okay, they can't. But, continuing to push the idea that they can is not helping anyone.
Not only is this affecting the actual performance of the app, it's affecting analyzing it, testing it, making it properly available to SEO, and probably other things not illustrated in this common revelation of an article. This isn't just one problem, it's a slew of problems that get so bad that ultimately the entire system needs to be rewritten. If it was just slowness, that'd be one thing, but it isn't.
> That said, I'll ignore my point above and get a bit technical here: Unless you're using Opera Mini, client-side rendering is indeed all we have for "textual document model rendering". That's what we call "HTML" folks when we're not "viewing source". So ... I'd give the client-side a bit of credit here, things will improve with time.
You're right, I should have said "textual document model generation". I've edited my comment as such. The act of rendering the model isn't normally the problem. The problem is that these frameworks rely on the client to turn their representation of the model into something else. They're converting something the browser doesn't natively understand into something the browser does understand, then using the browser to run a whole bunch of commands to generate representations of objects that can then be displayed on the screen.
Wouldn't it be nice if you could've skipped all that and just delivered clear instructions on how to render the information from the get-go?
Listen, SOAP is ugly. We all hate using it. But it's there and it's a standard for shit that matters because humans are fallible. We're not good at knowing what we don't know or how things may change. Every time a shortcut is taken, something else will need to be done down the path to ensure stability of the system at a later date. Often times the cost of that is human intervention.
Developers and big companies discover over and over why the nice and easy:
"Throw up a REST bro, JS that shit in Chrome, and get a back end as a service for the rest. We don't even need to worry about the fact that the server and client are different anymore! We can CODE ALL THE THINGS in one spot and not have to learn anything further! Isn't that great? Can we get our VC money now?"
...isn't sustainable.
Again, I'm not saying that it can't be done. I'm saying that it's really hard, you have to pay very close attention, and you need to know a lot up front.
Otherwise you get stuck trying to fix things you didn't know you didn't know. And you write another one of these blog posts.
I'd point to react.js as a framework that encourages fast code while discouraging knee-jerk adoption by calling itself a view layer, batteries not included. Of course, that doesn't help people realise whether JS MVC, PJAX or PHP is the best choice for the job. But it does highlight certain desires for client-side rendering that's more generic than "insert this block of HTML here". Like angular, it's most useful when you need to repeat yourself a few times on a page as each new piece of data has to be rendered in real-time to a page. If static, you should have fewer worries. Usually with JS, if it's easy, you're doing something wrong, or using Dart :p (Okay, the last was tongue in cheek)
Semantic nitpicking. It's obvious that the grandparent speaks about templating, which can be done both on client and server side.
Honestly, I'm really tired of people who pretend there is no difference between serving up HTML and serving a program that constructs that HTML. The difference is that in the second case you cannot get the content without executing the program written by someone else with all the relevant implications.
Also, people often miss another important fact: server-side rendering can be cached and shared across clients. Client-side templates must to be executed by every client separately.
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.
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".
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.
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.
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.
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 2: https://github.com/airbnb/rendr
Substitute any other flavor and the same problems exist.
keep in mind that client side JS have to work with the DOM - which is pretty awful
And if you want to deliver your content in mobile devices with there native app then Client Side Framework will be handy for you.