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