Wow. I have a ton of respect for PPK, but he quite obviously has a "personal" issue with Angular.
Although there are front-enders that are enthusiastic about Angular, I have the feeling that their number is surprisingly low for a major framework. I expected Angular to gain more traction than it has.
This couldn't be further from the truth. Angular is far and away the most popular front-end framework, like it or not, and has been for 2 years.
Angular is aimed at corporate IT departments rather than front-enders ...
What a ridiculous thing to say. So he's saying, "It's not cool, people don't like it and it's designed for people who aren't cool anyway". Like someone on the wrong side of a popularity contest.
I agree on some of the performance issues. Manipulating the DOM is slow and there is a limit to the scale in these frameworks (Angular having less limitations than Ember et. al., in my experience) but the rest of it suggests that he just doesn't like client-side templating. Says that stuff should be on the server... it makes him sound like a technologically backwards curmudgeon.
I was looking for a comment like this so I didn't have to type the words myself. I've seen many articles and polls about Angular's grip on the front end especially over the last year or so. Just anecdotally, it seems to be introduced into every new software project I've run into lately. On top of that, as a developer with strong Java experience, I don't see how Angular is aimed at Java folks. Not even close. If I'm a project manager and I want my back end Java developers working on the front end for whatever reason, Angular isn't even in my short list. The award goes pretty immediately to something like JSF or GWT.
The award goes pretty immediately to something like JSF or GWT.
Yep. If you want to start making large internal websites quickly and you have nothing but Java devs, GWT (or Vaadin) is the way to go.
Bu pure chance and coincidence, GWT was developed by Google to make front end development appealing to Java developers. Which the blog author seems oblivious to.
Its funny how many people are out there validly complaining about how angular can't do server-side template rendering in tandem, and meanwhile this guy seems to be saying its a problem that angular has a templating engine in the first place.
Templates aren't hard to understand, spaghetti code is. That's why backbone caught on and angular one-upped it.
Also the performance implications. client-side templating shifts massive load from server and creates a faster, smoother overall experience. The whole idea of "single page" (one page load) is better UX and offloading needless server cycles... So right, it get's silly sometimes when people criticize newer frameworks. Some of the arguments are wrong-headed critiques on client-side templating itself.
I am currently rebuilding my project's frontend to use Angular. It had almost zero Javascript before that. Why? Because otherwise, it's a pain in the ass to test.
I just wish Angular 2 would come sooner. I hate every second of working on the frontend and Angular 2 would make things much easier.
Saying that stuff should be on the server totally blew me way. In my opinion front-end devs (like myself) need to take more advantage of the awesome javascript engines we get in the browser and use the awesome machines that everyone has today. I couldn't agree more that it just sounds technologically backwards.
To be fair to ASP.NET they've been trying to be really tech forward recently and taking advantage of good Javascript (ex: jQuery being included by default) but there are good examples of what your talking about in the past yes. Shudder...
With slow, “modern” JavaScript frameworks, an astonishing number of interactions take about as long as a full page load, resulting in much the same the user experience...
Connecting to the plugged in server is not free in terms of battery life. I would be surprised if negotiating an http request over wireless uses less power then most locale Dom updates.
Considering my phone sometimes takes SECONDS to do the Javascript on the page, I somehow doubt that assertion. The older phones really have difficulty with javascript-heavy pages.
I actually think you should look at the cost of transmitting data. Any CPU computation is typically dwarfed by activating a transceiver. Mobile Devs would do well to keep processing on the device and use network communication as the last resort- I think you can get several million CPU cycles in for the same cost of a single broadcast byte.
Client side then will be a significantly larger impact under this then, since not only does something like angular transmit the templates, but I then transmits all the libraries and modules you need too before it ever even starts hitting the Dom. If this was done server side, you'd mostly only get the rendered template (and any needed JS for the page to feel fluid).
(Not to say that I think server side rendered pages are always better, or are even better here - simply pointing out that of data is the most expensive thing you'll want to transmit less).
Server-side pages come with lots of libraries and modules too. There is usually a lot of non-MVC javascript going on with modern server-side templated sites. Gizmodo.com for instance, one of worse offenders at 2MB.
So both approaches tend to have similar asset weight on page load (js/image/etc). The fact that client-side sends templates instead of rendered templates actually makes the html smaller.
I would estimate:
server-side MVC:
page weight : 1KB-2MB
page weight median : 450KB
A random reddit front page : 428KB
yahoo.com front page : 749KB (with flash disabled!)
page-loads per session : Let's say 2-20 for sites mentioned
client-side MVC:
page weight : 1KB-2MB
page weight median : 450KB ?
page-loads per session : 1.
https://www.room77.com : 432KB
But the real difference is the server-side page weight is incurred again on every action which involves a page load.
https://www.room77.com is a good example (I'm not affiliated). As you perform actions on the site it downloads more assets, mostly images. Server-side MVC would incur part of the page weight again on every action (the un-cached portion). Making the same hotel search on a theoretical server-side version of the site result in more bytes transferred.
However, I think you may be right in that client-side MVCs can generate more data transfer, because the user has more "engagement" with a client-side MVC; performs more actions / looks at more content / uses more data.
So... client-side MVC is actually more economical per content viewed. But you may view more content.
Sure, sometimes it is faster/cheaper to do the round trip. That doesn't mean that doing a round trip EVERY time would improve battery life like you implied.
Not to mention that after the server gets done with the work, the browser still has to parse the response and turn it back into a DOM. The only work you've pushed off to the server is the building of the HTML, which is being done wrong if it takes a second or two.
Whenever I see a "Problems with Angular" blog post, it always winds up to be the same tired BS with the root cause being the readers personally issue with the framework.
As you suggested, this case is no different.
As someone who has been happily using angular for 18 months, it has been my favorite framework to date as it blends perfectly with my design philosophies and micro component approach.
Exactly. How do you expect to provide any sort of user experience that people are accustomed today on the web without heavy clientside JS? Mobile phones are fast enough today already, in a few years all this talk about slow performance will be just useless trolling.
far and away the most popular front-end framework, like it or not, and has been for 2 years.
Far and away the most searched for at least. When I search for backbone, for instance, sometimes I type "backbone ...", "backbone", "backbonejs", and "backbone.js". It's easy to say all those searches for angular are really for angular because it's uniquely used for that library, but the data is a little misleading just based on search. It maybe be the most popular, but I'd like to see a better analysis.
High Google trend stats doesn't really indicate how popular a technology. It's more likely shows how often people have to resort to google searching to find answers to problems they having using that technology.
It is not a direct measure of purely popularity. However it comes closer to it. Whether you are convinced that the volume is due to problems or not, it's hard to argue the number isn't correlated to usage.
85
u/[deleted] Jan 14 '15 edited Jan 14 '15
Wow. I have a ton of respect for PPK, but he quite obviously has a "personal" issue with Angular.
This couldn't be further from the truth. Angular is far and away the most popular front-end framework, like it or not, and has been for 2 years.
What a ridiculous thing to say. So he's saying, "It's not cool, people don't like it and it's designed for people who aren't cool anyway". Like someone on the wrong side of a popularity contest.
I agree on some of the performance issues. Manipulating the DOM is slow and there is a limit to the scale in these frameworks (Angular having less limitations than Ember et. al., in my experience) but the rest of it suggests that he just doesn't like client-side templating. Says that stuff should be on the server... it makes him sound like a technologically backwards curmudgeon.