Why we left AngularJS

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.

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

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.

Knowing which one is building can greatly inform choice of framework.