15 ms·

I don't really follow many of the author's objections. I think he or she left out a lot of reasoning. "This code reminds me of a simple server-side scripting l

• agmcleod 12y ago
  I agree, I wish the author brought reasoning to those points. I do think that it is a little odd of us to push more & more processing to the user's device, rather than doing it ourselves and purely delivering content. However, it does seem to have a net positive on server reliability, and the perceived performance & responsiveness of the apps.
  • overgard 12y ago
    It makes business sense: server cpu cycles you have to pay for, client ones you don't. (If the client is fast enough not to notice -- if not, of course, you could lose customers).
    • dhimes 12y ago
      I've been pushing this strategy for years. It makes more and more sense to have the clients- which include phones- do the processing. They have an excess of power. And more importantly, once the app is downloaded network lag is not as big a factor (it still is, of course, for any ajax-based stuff- but we minimize this).
    • JustSomeNobody 12y ago
      "If the client is fast enough not to notice -- if not, of course, you could lose customers" This. I honestly think most front end devs don't test with anything except a fast PC (or Mac). They sure don't test with last year's phones. Web pages are getting more and more sluggish (generally speaking) all the time. It's one thing to always want to work with new technology, but devs really need to spend some time in their customers' shoes.
• nailer 12y ago
  Ditto - I also dislike Angular, am aware of the author's background and initially upvoted - but further reading shows this is a generic disagreement with browser-side rendering with 'Angular' thrown in for linkbait. Flagged.
  • mattmanser 12y ago
    That's not what flags are for. The article's on topic, you just don't agree with it, don't flag it.
    • cloakandswagger 12y ago
      Maybe a misuse of flags, but I agree that the title has the same inflammatory, ambiguous quality of a linkbait article.
      • yuchi 12y ago
        Guys, do we really need to be so politically correct? Do we need to state that it’s his (author’s) personal thought on the topic?
    • nailer 12y ago
      You haven't actually read the post you're replying to. I do actually agree with the articles conclusion, but It has a misleading headline and my understanding is that this is exactly what flags are for. Dang should we not flag this stuff?
  • usingpond 12y ago
    "generic disagreement with browser-side rendering" re-read the article. Author has no issue with Ember or Backbone.
    • nailer 12y ago
      Please do so yourself. He repeatedly states that templating 'does not belong' in the browser with no justification whatsoever.
• robotkilla 12y ago
  Currently wrapping up my first commercial AngularJS project - I was outsourced by a client. Prior to this contract I had no experience with it, now I've been using it nearly every day for the past month and a half, have run through the tutorials and implemented it on a side project of mine. All that said, I will be stripping Angular out of my side project. It is something I am glad I learned for clients that demand it, but I wouldn't recommend it. IMO Backbone with underscore templates are much cleaner and seem to perform much faster for my needs (no benchmarks performed on my end, but as a user my site certainly felt snappier prior to implementing Angular).
  • sehr 12y ago
    Might want to check out React eventually, it vibes pretty well with existing Backbone apps
    • robotkilla 12y ago
      Thanks for the tip
• sgustard 12y ago
  I've been writing Angular on Rails for the last year. We took a bag of jQuery code which manipulated DOM for a complex single-page app. We threw that all away and replaced it with 90% less Angular code. It felt (not to trot out a stale trope) like magic and we never looked back. It was clear to us from day one that performance would be an area of concern, as well as the overall complexity of the framework. But those can be addressed. I don't agree that using another framework would magically prevent developers from thinking about performance issues. And many modules of angular we just don't use, and it doesn't impose those on us. On a regular basis we re-evaluate alternatives: React, knockout, backbone, and so on. I expect those might involve tradeoffs that end up being positive or neutral for us, even it just forces a re-thinking of the app architecture. But this article doesn't make any recommendation or even mention the initial problem of rich, single-page apps that create user interactivity without page reloads. And the painting of the framework as Java and Enterprise do not match our experience or use case. I'm the first in line for recommendations on how we can improve what we do, but my impression is his bias is throw away frameworks and bring back our mass of raw javascript.
  • EGreg 12y ago
    I think besides ng-repeat, angular is pretty much like any other two-way template binding framework. I don't know why it's really considered so radically different and special. It's when you get controllers such as ng-repeat that Angular's digest cycle makes some difference. But ultimately you could write a component like ng-repeat yourself. As for where you place the directives -- the tag name or attributes, inside the class -- who cares? Only the {{}} in the text nodes matters strongly. As for alternatives, check out http://platform.qbix.com http://platform.qbix.com . It is compatible with angular, ember, jquery etc. But it is much more straightforward, like react. You only have two concepts - pages and tools (components). And you can not only re-use a whole lot of tools from a marketplace but they all can work with a standard opensource platform of user accounts, realtime streams of data, which can distribute the social layer the same way bitcoin distributes money and contracts.
    • joewood 12y ago
      Agreed, even ng-repeat has equivalents in each framework. Migrating from direct DOM manipulation is a no-brainer, but I wouldn't count it as an advantage of Angular over the other choices.
• VMG 12y ago
  > "Although templating is the correct solution, doing it in the browser is fundamentally wrong. The cost of application maintenance should not be offloaded onto all their users’s browsers (we’re talking millions of hits per month here) — especially not the mobile ones. This job belongs on the server." Agreed. I'd go even further: presentation logic, including templating, is the job of the browser. The server is the database. And I include "mobile" front-ends in this, which do all not equate to "low-powered" these days.
  • kroosaidher 12y ago
    Why are we black-and-white fallacy-ing this? It is indeed stupid and wasteful to deliver 40 KB of framework and 8 KB of templates and 14 KB of data and 20 KB of business logic and 15 KB of CSS to the client and then make the client do all the rest of the work to "make page happen"--especially on an open platform with so few reliable guarantees about the client's capabilities and resources. But to say templating is only the job of the server is equally myopic. Web applications--high functionality, low content (as opposed to web sites--low functionality, high content) have struggled with the limitations of the static, stateless document paradigm for years and is the real use-case for client side templating as an answer to one of the many resulting challenges. When a page is highly dynamic in response to interaction, it is equally stupid and wasteful to perform full page refreshes. Request, server compile, download, flow, paint. Bad. Slow, discontinuous. Someone else mentioned UX being ignored in the quest for client side templates: no, wrong. Client side templates are at least 50% about UX. We have a DOM already there, let's use it. But that is also exactly the problem with the all-client mode: it delivers something several extra steps removed from being a useful (to the user) DOM when it could do otherwise and when doing otherwise would result in a better and more universally performant user experience. Right now, truly smart isomorphic templates are what we need. (But, then again, by the time we get them, we probably won't need them--because the goalposts will have shifted and/or we'll have a better answer.)
  • rimantas 12y ago
    37signals (now Basecamp) should have a post or two about how they made a new version of the product fast. One of the points was bringing templates back to the server, iirc.
• lhorie 12y ago
  Just thought I'd add a bit of meta context: PPK (the author of the article) is perhaps the first person in the js community to catalogue detailed per-feature cross-browser compatibility tables. You could say he's one of the old timers. PPK has a very strong background in cross browser testing and high level technology evaluation for non-techie audiences, but (from my impression of reading this article, at least), it doesn't seem like he has much experience w/ Angular per se and sounds like he is writing his opinions more based on blogosphere echo than personal time spent with the framework (clue: lack of Angular-specific terminology criticism) Some of the criticism is valid, I think: hiring "Angular" devs is hard, partly because of the over-engineered-Java-like feel. I've seen a few times overconfident frontenders think they could pick up Angular through Google-Fu just as they picked up jQuery, and then hitting a brick wall face first, with a looming deadline to add insult to the injury. The reality is that a lot of people (especially frontend people) don't have the CS foundation to understand why and when the design patterns prevalent in Angular/Java are useful (or even what patterns exist to begin with). @jasonwocky The snippets you highlighted do seem a bit like a "get-off-my-lawn" reaction from the author. SPA architectures certainly have their places, and it does feel like the author hasn't had experience w/ building heavily dynamic UI apps. >> Find me a framework that hasn't evoked serious criticism from some corner of the Internet. I think the point is that Angular criticism is much more prominent (and sometimes vitriolic) than other frameworks.
  • voidr 12y ago
    > @jasonwocky The snippets you highlighted do seem a bit like a "get-off-my-lawn" reaction from the author. SPA architectures certainly have their places, and it does feel like the author hasn't had experience w/ building heavily dynamic UI apps. > The snippets you highlighted do seem a bit like a "get-off-my-lawn" reaction from the author. New and shiny ways are not always the best. I'm still not seeing people writing kernels and device drivers in JavaScript. > SPA architectures certainly have their places And what areas those might be and why? You can build heavily dynamic apps without trying to do everything in the browser. Problem with the web nowadays is that a lot of decisions are being made for political reasons rather UX considerations. SPA architectures are appealing to front-end developers who just can't be bothered to learn how to do routing and templating on the backend or they just want to have those things in their territory. For me UX matters more than shiny architecture. I did the experiment in Chrome where I had HTML and applied some stylings to it via the raw DOM API as soon as possible. There was a noticeable delay before the stylings got applied and this was the highly optimized DOM code with no Angular, no jQuery, no nothing. The moral of the story is: browsers are still faster at displaying HTML and CSS. Aside from the performance failures, Angular has huge problems when it comes to writing maintainable Angular code like the scope hell, but you can find many others here: http://ihateangular.com/ http://ihateangular.com/
• astine 12y ago
  "Says who? What's the rationale for where a language belongs?" From the article: "Unfortunately they aren’t trained to recognise Angular’s performance problems." ... "The problem is that there is no way for Angular to discover these instructions except by parsing the entire DOM, including all text nodes and attribute values — a very expensive process if there ever was one, especially on mobile." The author is arguing that it is bad for performance.
  • antic 12y ago
    if Angular is truly dropping the template into the DOM and then parsing the DOM, Angular is doing something terribly wrong. Underscore (for example) parses templates that look very similar to this by parsing the template as a string (not as DOM nodes). If it's crucial to parse the content as nodes, the top element (or a wrapper) can be constructed outside of the DOM itself and parsed as nodes outside the DOM tree. I haven't looked into how Angular does this parsing but I would be very surprised if this complaint is accurate.
    • tragic 12y ago
      Yeah, that's pretty much what it does[0]. Most templates will typically live in separate files and be loaded and compiled when needed, of course - so not so much of a performance hit up front. But Angular still needs to know where to dump the stuff, so it needs to parse the DOM to find a node with the ng-app directive. Also, I'm not aware of anything like handlebars's offline pre-compilation for Angular, although such a thing may well exist. There's a lot of stuff in there... [0] https://docs.angularjs.org/guide/bootstrap https://docs.angularjs.org/guide/bootstrap
    • kroosaidher 12y ago
      Hold on there, cowboy. The innate superiority of strings over DOM based templating is not universally accepted. Because it's not unequivocally proven. In fact, a few years ago there was an obvious tide toward experimenting with alternatives to string based templating noticeable in several some high profile efforts in the client side templating space. See http://modernweb.com/2014/03/24/string-templating-considered-harmful/ http://modernweb.com/2014/03/24/string-templating-considered... for a recent overview that is pretty decent. Boris Moore did a lot of publishing about it, as I recall.
• PSeitz 12y ago
  This post resembles exactly my impressions. I don't see why such a weak reasoned article based on assumptions and feelings is getting upvoted.