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

[2] - http://www.quora.com/Web-Development/What-are-the-tradeoffs-...

[lstamour]

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

[randomdrake]

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

[lstamour]

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)

[romaniv]

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.

[lstamour]

Fun fact: Polymer-style development encourages data transmission using HTML. The lines get more blurred every day...

[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

[dkersten]

Append ?share=1 to the end of the URL and no more signup wall.

[lstamour]

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.

[lifeisstillgood]

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.