81–90 of 169 posts
All I really need are client-side templates and awesome DOM binding. What's the current best options?
Backbone.JS, it's exceptionally bare bones, but hey it's YOUR code. You don't have to memorize an entire framework like Angular. Pick up a Backbone book and in two weeks your dangerous enough to use it. A month, you're in the groove. 6 months: Angul-who?
All I really need are client-side templates and awesome DOM binding. What's the current best options?
Backbone.JS, it's exceptionally bare bones, but hey it's YOUR code. You don't have to memorize an entire framework like Angular. Pick up a Backbone book and in two weeks your dangerous enough to use it. A month, you're in the groove. 6 months: Angul-who?
Earlier quoted context omitted.
Except that Backbone.js, a micro-framework if there ever was one, exploded in popularity long before most people had even heard of AngularJS.
Backbone doesn't do data binding; it's a completely different thing. (That's why things like rivet and epoxy exist; because backbone doesn't do it right)
"Two way data-binding" is avoided. While it certainly makes for a nifty demo, and works for the most basic CRUD, it doesn't tend to be terribly useful in your real-world app. Sometimes you want to update on every keypress, sometimes on blur, sometimes when the panel is closed, and sometimes when the "save" button is clicked. In almost all cases, simply serializing the form to JSON is faster and easier. All that aside, if your heart is set, go for it.
Earlier quoted context omitted.
React solves all the problems in the world with their nestable but still autonomous components approach. It dispenses controllers -- and automatically give control to the component which deserves it --, it dispenses templates, and automatically gives the power to make the entire app in modular small pieces of HTML, it dispenses models, because models are already embedded in the components in which data is rendered. R…
I'm curious what happens when you want to share models across components. In angular.js you would use services to do this, but what's the analog in React?
AngularJS has a J2EE mindset. Where libraries grow to become as hard to learn as programming languages themselves. It does not make semantic sense to me anymore. Here is an example from the site: Length (float): {{length}} This is not a valid float number! How semantic is ng-show="form.length.$error.float? smart-float sounds like C++. If programming languages worked like this, we wouldn't have built many apps. The pr…
This is true. AngularJS is much better than what we had before, it is kind of large and monolithic. The cycle probably goes thusly: Large monolithic framework comes and shows everyone a new way of doing things (Angular/Django). People think it is too large and monolithic, so make microframeworks (Flask/Whatever comes after Angular). The next step will be a kind of happy medium.
I have suffered trough JEE which is/was really humungous, and Angular is really tiny in comparison.
Earlier quoted context omitted.
I'll agree it's not pretty to view source and see an inordinate amount of fluff in what was once your beautifully handcrafted semantic HTML. Much of this can be alleviated with templating (ng-view). Have you taken the time to play around with angular before airing your grievances? My hunch is yes and that you may just be simplifying things for others who haven't used it yet. For those of you who haven't had the pleas…
Agree 100% with your post - some of these complaints are misrepresenting the aspects that are not as desired in Angular. I've used Angular quite extensively for the past 1 1/2 years, and most of the complaints I have with it are more nuanced, such as having to dynamically inject some custom directives via $compile in a service method provided to a controller due to the complexity of being able to alter the attributes…
The reason being, considering that HTML5 is an ever evolving spec that it might be possible for a new element to be introduced that could be using the same name as one of your examples. That might muck things up a bit. At least visually, as I would imagine the directives would likely continue working the same as before. It's just that the "they must be directives" logic would fail in that instance.
AngularJS has a J2EE mindset. Where libraries grow to become as hard to learn as programming languages themselves. It does not make semantic sense to me anymore. Here is an example from the site: Length (float): {{length}} This is not a valid float number! How semantic is ng-show="form.length.$error.float? smart-float sounds like C++. If programming languages worked like this, we wouldn't have built many apps. The pr…
This is true. AngularJS is much better than what we had before, it is kind of large and monolithic. The cycle probably goes thusly: Large monolithic framework comes and shows everyone a new way of doing things (Angular/Django). People think it is too large and monolithic, so make microframeworks (Flask/Whatever comes after Angular). The next step will be a kind of happy medium.
The new DI looks confusing. The old way is super simple to understand. You inject the location provider and call it. In the new way however I don't understand what's going on at all. Where can I find a simple example?
Seems pretty simple, imo.
Dependency Injection -- the heroin of abstraction junkies.
Earlier quoted context omitted.
With DI you can ensure you're not accessing anything that's globally defined. While you can mock out global objects and methods on global objects, it becomes far less clear what the ramifications of doing so becomes when your app becomes large and complicated. With DI, you have all the dependencies clearly defined for the function you're concerned about. Beyond testing, DI makes it much easier to swap in different im…
Your first point cannot be debated, since we are speculating. In practice, I'vent seen a problem. It works, it's clean, and it is the right amount of engineering needed to solve the problem. Parse and Firebase example: //someservice.js ... //works as long as both retain the same interface. provider = new FirebaseProvider; //new ParseProvider() //add: just using an if condition, the old fashioned way. getProvider: fun…