Waaaat. How can you say Angular is hard? I don't think I ever encountered a framework or a technology that I picked up so quickly. Hell, node.js took me longer (with all the callback hell and workarounds for it). I've built several apps in Angular now (and am close to finishing a very complex one) and I dont think I have ever gone through a tutorial.
The reason Angular JS will fail
71–80 of 85 posts
Re: The reason Angular JS will fail
#72Earlier quoted context omitted.
That's what I was looking for when I found Angular. There are definitely two questions worth asking: 1) Is that combination really what we want? (I think it is) and 2) Is Angular's approach the only right way to do it? So far, they've got the mindshare and a serious head start.
So far, they've got the mindshare and a serious head start. I keep on hearing this, but I really haven't heard of it being in any large projects other than DoubleClick. I don't know if I'd consider being used in a bunch of small hobby projects a 'head start'.
http://www.localytics.com
Youtube App for PS3
there is a lot more, it's being used in a lot of startups and major companies throughout the world today, pretty sure the stats show it is far ahead of ember in real world adoption so far
Re: The reason Angular JS will fail
#73Earlier quoted context omitted.
I wish there was more discussion of the core concepts in Angular instead of just the implementation. Custom Elements + Two-way Data Binding + Services seems to be a pretty powerful combination.
Two-way Data Binding is really oversold IMO. There are few cases where I want such a thing (like say updating the count on a shopping cart when an item is added). I don't ever want an item you're adding in a form to be showing up as you type it in a list in the background. That adds nothing and on the whole it's probably a UX negative effect. I think it's brought up so much mostly because it's cool tech. But I don't…
That is only one use case for two-way data binding. A better example is that choosing an option in a select list instantly modifies your model, which triggers changes in some other computed properties on your model, which instantly binds back to the UI to populate that second drop down list with the filtered options.
Re: The reason Angular JS will fail
#74Earlier quoted context omitted.
Two-way Data Binding is really oversold IMO. There are few cases where I want such a thing (like say updating the count on a shopping cart when an item is added). I don't ever want an item you're adding in a form to be showing up as you type it in a list in the background. That adds nothing and on the whole it's probably a UX negative effect. I think it's brought up so much mostly because it's cool tech. But I don't…
That is only one use case for two-way data binding. A better example is that choosing an option in a select list instantly modifies your model, which triggers changes in some other computed properties on your model, which instantly binds back to the UI to populate that second drop down list with the filtered options.
Sure. But most if not all of that logic is on the server anyways. So to actually make it work that way would be (IME) a duplication of effort.
Then you have to deal with the fact that some of these second-order effects may be dealing with thousands of options. Do you really want to be calculating cartesian products on the client in JS? Ignoring the performance concerns, you could be talking about preloading a ton of data.
And then you're addressing complexities on the client side, coming up with potentially inconsistent solutions for because you're evaluating these on a case by case basis, and you've already solved these problems on the server.
While there might be some UX cost to round-tripping to the server, the client solution to approaching such problems is then consistent, and arguably far simpler. And you generally have much much better tooling to tackle these problems on the server, and more flexibility in applying your logic across web, mobile, batch processing scenarios, etc.
I mean, you could make your same argument for WebControls in ASP.NET. And it's my impression everyone mostly agrees it was a bad idea (at least I haven't noticed any competitors thinking it was an idea worth stealing). Except now it's on the client, with much weaker tooling, multiple runtimes it has to work with, etc.
We could go back and forth all day I'm sure. It's just a POV I felt like putting out there as someone who survived the two-way-data-binding wars of the early 2000's and isn't eager to see that idea rise to prominence again.
Re: The reason Angular JS will fail
#75Earlier quoted context omitted.
I wish there was more discussion of the core concepts in Angular instead of just the implementation. Custom Elements + Two-way Data Binding + Services seems to be a pretty powerful combination.
Two-way Data Binding is really oversold IMO. There are few cases where I want such a thing (like say updating the count on a shopping cart when an item is added). I don't ever want an item you're adding in a form to be showing up as you type it in a list in the background. That adds nothing and on the whole it's probably a UX negative effect. I think it's brought up so much mostly because it's cool tech. But I don't…
The two way binding can be so useful though. The best example I've seen was an array of coordinates bound to a directive that used D3.js to visualise it. There were some special function you could call that would affect and expand your data and immediately update the graph, and you could manipulate the individual points on the graph and it would propagate to the data seamlessly.
I guess to me two way binding is one of those things that you don't think of often, but when you don't have it you suddenly find yourself writing tons of boilerplate code to get the same effects.
The only cases when I didn't want the two way binding were when I was creating or editing an item. And then it's trivial to bind the form to a separate object while you work on it, then push your changes to the collection/original when you're done.
Re: The reason Angular JS will fail
#76I agree with the premise but disagree with the argument. > Which brings me to the pattern of ever failing technologies. Remember Moo Tools? Prototype? ... Prototype and moo tools tried to be innovative, but they just made things harder. Not only were they not intuitive to use, but referring to the documentation was even worse. Would take hours what jQuery could accomplish in mere minutes. That's just not true. I can'…
What I dont like about Angular: "it is built on the idea of adding HTML attributes to make it powerful enough to build applications. This is not a solid theoretical foundation and results in lots of neologisms -- scopes, transclusion, directives, reliance on dependency injection (in JS? really?), its own module system, its own idea of model/view/controller, etc etc.". Quoted it from pete hunt. When I studied CanJS or React, I felt the design made more sense.
Re: The reason Angular JS will fail
#77Earlier quoted context omitted.
So far, they've got the mindshare and a serious head start. I keep on hearing this, but I really haven't heard of it being in any large projects other than DoubleClick. I don't know if I'd consider being used in a bunch of small hobby projects a 'head start'.
http://www.localytics.com Youtube App for PS3 there is a lot more, it's being used in a lot of startups and major companies throughout the world today, pretty sure the stats show it is far ahead of ember in real world adoption so far
I'm rooting for Angular, but it just seems so far behind. Ember has more recognized names, Angular has tiny companies and hobbyists.
Square, Vine, Yahoo, NBC News, Groupon, Twitch, Urbanspoon, Discourse, Ghost, TravisCI, and now Netflix?
Re: The reason Angular JS will fail
#78Earlier quoted context omitted.
Two-way Data Binding is really oversold IMO. There are few cases where I want such a thing (like say updating the count on a shopping cart when an item is added). I don't ever want an item you're adding in a form to be showing up as you type it in a list in the background. That adds nothing and on the whole it's probably a UX negative effect. I think it's brought up so much mostly because it's cool tech. But I don't…
The two way binding can be so useful though. The best example I've seen was an array of coordinates bound to a directive that used D3.js to visualise it. There were some special function you could call that would affect and expand your data and immediately update the graph, and you could manipulate the individual points on the graph and it would propagate to the data seamlessly. I guess to me two way binding is one o…
[deleted]
Re: The reason Angular JS will fail
#79Earlier quoted context omitted.
I wish there was more discussion of the core concepts in Angular instead of just the implementation. Custom Elements + Two-way Data Binding + Services seems to be a pretty powerful combination.
Two-way Data Binding is really oversold IMO. There are few cases where I want such a thing (like say updating the count on a shopping cart when an item is added). I don't ever want an item you're adding in a form to be showing up as you type it in a list in the background. That adds nothing and on the whole it's probably a UX negative effect. I think it's brought up so much mostly because it's cool tech. But I don't…
If you think it's oversold, you've probably only seen a bunch of stupid tutorials about neat features with it.
What Two-way data-binding gives you is a structurally-controlled presentation layer.
You can represent the page's state as objects with properties, and it "just renders". You can have a "readonly" property, and it makes everything readonly. You can have a "show edit box" property...bang. A "loading" variable, etc.
The idea is that you can treat the front end html like everyone else has always treated their world: as a finite state machine.
Since I am primarily a back-end developer (with more middle-tier experience than I originally would've wanted to admit), this jives really well to me. Instead of jumping in and hacking at the DOM every time data gets updated, I just use Angular for pages that are "that dynamic".
I really don't want to have to render new DOM elements (even with a template engine like Dustjs) and overwrite them into the page, just to represent a small state change.
With a data binding library, I don't have to. I don't use Angular for many things, and I sure don't use the "SPA routing" functionality... but when I need to do constant rapid-fire AJAX requests for growing subsets of a huge dataset (say, schools/programs by region and proximity), Angularjs saves you a lot of code: code that's generally quite ugly.
Re: The reason Angular JS will fail
#80Earlier quoted context omitted.
That is only one use case for two-way data binding. A better example is that choosing an option in a select list instantly modifies your model, which triggers changes in some other computed properties on your model, which instantly binds back to the UI to populate that second drop down list with the filtered options.
Sure. But most if not all of that logic is on the server anyways. So to actually make it work that way would be (IME) a duplication of effort. Then you have to deal with the fact that some of these second-order effects may be dealing with thousands of options. Do you really want to be calculating cartesian products on the client in JS? Ignoring the performance concerns, you could be talking about preloading a ton of…
If that logic is on the server, you wouldn't use Angular for it...
But from a strict MVC standpoint, it seems smart for that logic to be on the client. The server provides a getter API: /api/schools_by_state/CA for example. The client does an ajax call if you choose "California" to get the schools list, which it can do in under 100ms on a fast enough world...then it can cache California schools on the client side, so it doesn't need to fire that call again.
And of course you want that calculation to happen on the client, for 2 reasons:
1. In sparse-use sets (like pick a state, then pick a city, then pick a district) you will only really need to use 10% of the data, you can save a ton on bandwidth here.
2. In situations where the render patterns get complicated, it's really just a PRESENTATION issue. The server may validate that you're not using noncompatible dropdowns, but it otherwise should not care what happens in the browser related to that.