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:
<div>
Length (float):
<input type="text" ng-model="length" name="length" smart-float />
{{length}}<br />
<span ng-show="form.length.$error.float">
This is not a valid float number!</span>
</div>
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 problem is that some frameworks assume that everything should be done with using configuration. What ends up happening is that the configuration (and conventions) becomes its own language. This is a waste of time in the long term; library conventions are not a portable skill set.
Some things are just better off with plain JS and simple HTML. FB/Instagram's React is a much better approach to building HTML UIs; you get readable JS and HTML instead of configuration mess.
This is a critique of the example, more than the framework itself. The "smart-float" directive is not a native angular directive, but rather a directive made for the example.
As for the "form.length.$error.float", it probably could be a bit more concise, but is it really that bad? What would be a "more semantic" way?
The main strength of angular, is that you are able to point your DOM elements to environment variables in your JavaScript code -- eliminating the need for traversing the DOM to find a mount node. If you are opposed to this functionality and insisting on traversing the DOM from the JS side, I'd love to hear why.
You can find small things you dislike in any framework, but rarely are they valid criticisms of the general concept. Often, these details are there for a reason, and just as often, they are flaws waiting to be fixed by an open source developer.
I'll keep this high level; that's where I have issues with Angular.
Angular wants you to learn its vocabulary, and encourages users to expand it further.
Like you point out, smart-float is a directive specific to the example. To me, it is a foreign object I don't recognize in html. In fact, directives, scopes?
The big one. Dependency Injection, factories, modules. In JS, this is a solution looking for a problem.
There are simpler alternatives to DI. They have issues, but only in theory.
Clarity matters a lot. ng-show="form.length.$error.float". Is there a more simpler way of doing it? There should be; I can't even tell what that means.
I think there are distinctly two camps. I'm in the one which wants frameworks to make me productive with the languages, specs and standards I already know. React (+ router) does this. Backbone does this too, depending on what you're building.
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 pleasure of working with angular: Once you've familiarized yourself with the verbiage, most of jeswin's concerns here come second nature just by glancing in one's source code. Let's take the example:
form.length.$error.float
The name form, albeit horribly chosen in this case, represents the parent form's identifier in angular (the form's name attribute). It would've made more sense to use <form name="formLengthValidationDemo"> or something more insightful so you could more easily see the name matching from HTML to JS.
$error is simply the representation of any form validation errors that may have occurred. It's standard in angular, and there's plenty of documentation. Just google for "angularjs form validation" and you'll find a million resources at your disposal.
form.length.$error.float is checking if an error exists for the validation rule float. Given the limited amount of code in the sample, we'd have to arbitrarily assume that the "smart-float" directive is implicitly setting a custom validation rule via:
ngModel.$setValidity('float')
I'll have to agree to disagree regarding pattern usage and dependency injection. They do have a place, and it tends to be in larger applications which become a burden to maintain as your application grows. To be quite honest, I believe angular brought a simplicity to DI that has yet to be seen in many other frameworks. It entirely lowered the barrier to entry for writing testable code and heavily promoted unit testing at the same time.
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 present dynamically in a template.
The declarative style that Angular coaxes you into makes things incredibly easy to understand - you can write code like
And instantly understand what the purpose of these elements are - they're easy to read, they're descriptive, and they're clearly custom elements not part of the normal HTML5 spec, so you can instantly recognize that they must be directives.
I can also do simple directives like <loading-spinner></loading-spinner> and create a nice template for CSS to hook into by using the loading-spinner element tag without having to distract from the rest of my DOM with a nesting of 8 divs that can easily be tucked away in a reusable template.
I agree with you that since your elements appear to not be a part of the HTML5 spec they must be custom and are directives, wouldn't it be a good idea to mark them as such in some way? Maybe prepend them with "an-" or something?
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.
Good point. I, too, enjoyed using custom tags like <zoomer> or such, but I'm going to think twice in future.
Interestingly, out of the box Angular provides directives as a, input, or form—meaning that when you write <input> you are, in fact, invoking a directive that provides extra features along with native tag's functionality. While using Angular, you may as well consider every HTML element a directive.
Nevertheless, Angular uses ng- prefix with their built-in directives that don't replicate some existing tag's functionality closely.
Yes, this is actually the recommended practice from the documentation. Built-in Angular directives are typically prefixed with `ng-`, and they suggest that other projects/developers use their own prefixes to avoid conflict.
That seems like a poor reimplementation of XML namespaces.
Why not use XHTML at that point? If XHTML ever had a clear mission statement in life it was that.
I mean I thought XHTML was a curse a few years ago when it was The Thing Every Good Designer Uses™ since it couldn't be rendered as XML in the most popular browser. But hopefully that's not as much an issue anymore. Or maybe it is. I haven't kept up with IE.
Actually, it's a little more complicated than this even. Not only might HTML add more tags, but a non-standard tag might be a W3C custom element: http://www.w3.org/TR/custom-elements/
When users gain the ability to define their own tags, you might not know which ones are driven by directives, the custom element, or both even.
The philosopher David Lewis had a lot of critics, and they would often cite the fact that they couldn't possibly see how modal realism could be true, to which Lewis would reply, "I don't know how to refute an incredulous stare."
Arguments from personal incredulity don't engage substantively with what they ostensibly claim to refute because they import a variable- the argument-maker's conception of what seems plausible- that really should do no work in a logical analysis.
The arguments adumbrated in the parent comment seem to have similar failure modes, adorned as they are with premises such as "to me, [the directive] is a foreign object I don't recognize," and "I can't even tell what that means." Someone who has never programmed before could look at some vanilla javascript and plead perplexity, but obviously this isn't an indictment of javascript itself. To really make the point, the parent comment would have to show that the learning curve is disproportionately arduous for the payoff at the summit, but reiterations of personal unfamiliarity were offered instead.
Jeswin gives no evidence of having made a reasonable attempt to understand Angular ("directives, scopes?"), but more crucially, displays little understanding of the benefits of Angular. DI is criticised as "a solution looking for a problem" in the context of javascript, as if dependency injection were a bandaid for not being a dynamic language. DI enables testability, and not even mentioning this advantage, let alone not providing a cogent argument for why the learning curve of DI doesn't justify the gains in testability, is to refuse to participate in the discussion entirely. Directives are similarly dismissed as "foreign objects," which they might be to some, but they're hugely powerful foreign objects that allow arbitrary behaviour to be written declaratively. Not knowing the benefits of Angular obviously contributes greatly to a reluctance to learn it, and perhaps a subsequent rationalisation of this reluctance as being provoked by something intrinsic to the framework.
Fittingly, after expressing bewilderment regarding Angular scoping, Jeswin goes on to divide the world into two camps, declaring membership in "the one which makes me productive with the languages, specs, and standards I already know", which is about the closest thing to a natural language scoping bug I've come across.
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 implementations of a dependency than simply throwing things into the global scope lets you do. Suppose I want to switch my model from one that communicates with Parse to one that communicates with Firebase. Supposing I adhere to the same interface, I should be able to simply drop it in place without affecting other functions or objects that still rely on the Parse version of the model.
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: function() {
if (config.provider === 'parse')
return ParseProvider()
else
return FirebaseProvider()
Why is writing configuration cleaner than doing the above? That thought process is carried over from projects with lengthy build time.
Whether or not Angular's implementation of its provider is cleaner is irrelevant to your original point that DI is a "problem looking for a solution" in dynamic languages.
My interpertation of the AngularJS DI implementation is that it exists primarily to make it easy to swap items out for testing purposes. I believe it solves that problem very well.
> just replace the value of "ns.someService" worldwide with a mock.
Having a window-wide namespace might make sense in the test, but it is pretty risky/limiting if you are writing a component that should be reused in contexts you don't fully control. There are other ways around that besides DI, but they will probably have similar trade-offs in safety EOU, etc.
Backbone was the start of the cycle. It came around at a time when front-end apps were largely jQuery soup and put polish on best practices that good JS developers were already doing. Then a lot of other frameworks were developed which largely started from the same code-first premise that Backbone had/has, and Angular "won" by introducing a new paradigm built on declarative binding.
I predict that the next winner will leverage web components and do the one thing that makes that paradigm better.
Correction: Backbone doesn't try to be the kitchen sink like Angular. Its source code is about 500 lines, and its docs say as much:
"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.
This. I would add angular is good for teams requiring extensive structure. The cost is control. If you're building a corporate webapp, angular is great to keep everybody neat. If you're doing something unprecedented such as 3D rendering or a new UI element, angular will hinder more than backbone.
I never understood how JQuery and JS were just dumped the past 3-4 years in favor of all thse complex frameworks like AngularJS, Ember, etc... is there something these frameworks can do that JQuery can't? Can they make fancy single page apps and JQuery can't? I need to be enlightened.
Or is it simply ppl need to exercise their mental creativity?
Among other things that Angular, Ember & others bring, what you should understand here is that JQuery does not help you to structure your code. Those frameworks offer the type of structure that makes it easier to reason about how an app should be built, and it helps a lot when you're working in a team.
JQuery and JS were certainly not dumped, it is just that people writing single page apps moved on and are now using tools that help them.
"I never understood how JQuery and JS were just dumped the past 3-4 years in favor of all thse complex frameworks like AngularJS, Ember, etc..."
Well, you can't have Angular without JS so we'll focus on the point of jQuery here.
jQuery does a few things really well – so well that Angular itself uses jQuery (or jqLite by default). angular.element(selector) returns a jQuery object.
Angular also does a few things well. Code reusability and testability are much easier to achieve with Angular, in my opinion. Features like data-binding also help to reduce boilerplate code.
There was a similar discussion last week. What I said then was that a lot of the things you would use jQuery for have a different solution in Angular: https://news.ycombinator.com/item?id=7396016.
jQlite is a pretty small subset of jQuery. Many things are left out to keep it lean. For example $(el).offset()/height()/width() etc. Mostly only the DOM methods are left as they do still need a bit of normalization across browsers.
Personally, the two big draws to me of Angular were "free" (as in, I don't have to write much code) DOM<->data binding, and the explicit goal of testability.
As a learning exercise, I wrote a page using just jquery, rewrote it in backbone, and then rewrote it in angular. Backbone helped me separate concerns; Angular helped me do that while writing _way_ less code, since I didn't have to manage keeping the DOM and the JS model in sync.
I redid a relatively trivial CRUD interface from backbone to Angular. The amount of code that I didn't need in Angular was ridiculous. Most of the code in backbone was moving stuff from the DOM into JS. Like var x = $('#elem').val(); kind of things over and over just did not need to be there in Angular.
I think that these kinds of interfaces hit a really good sweet spot with Angular and other databinding frameworks.
Agreed - data-binding and "magic" automatic updates to the view when the model changes are key to what make Angular attractive. The focus on testing is nice too, though.
Yes, there are a tons of things that jQuery cant do out of the box, like handle state in your application or keeping your client and server data reliably in sync, list goes on. Also, lots of frameworks haven't ditched jQuery, for instance, Ember.$ is a reference to Embers copy of jQuery.
imo AngularJS can be pretty micro and scales nicely. Its one of its major strengths, as you can use it to just build a tiny widget inside an existing page or all in and build a huge application.
It's worth noting that one of the goals listed for 2.0 in this post is increased modularity, which they imply will let you only load the pieces you're actually using.
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.
When I investigated React in detail, I found that there is a lot to like about it, but it's certainly no "holy grail." Specific downsides: you have to go back to manually writing event handlers (instead of getting automatic two-way data binding) and the virtual DOM is a leaky abstraction.
Also React does not "solve all the problems in the world" -- it says nothing about routing, validation, testability, and many of the other problems that Angular has solutions for.
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?
React encourages you to use a parent component that controls the state and passes it down to it's children via props.
Passing data to separate components without a shared parent is outside of what React is trying to accomplish but I've handled it before by passing a Backbone model to the separate components as props.
If you're passing it to child components you pass it through attributes. If you're passing up to parents, however, you have to create a function on the parent that will get called to accept the child's new data. This can get really messy if you have deeply nested components and need to get data from one branch to another branch.
I have been successful by instantiating separate services to perform REST operations and a global event emitter to establish communication between all the services and all the components that relate to these services in any way.
I cringe when I hear the words "global" and "event" together in the same sentence. Projects I've worked on in the past that relied heavily on global events often became a maintainability nightmare.
Why? Please share your experiences. I don't understand what's the utility of event emitters if not for serving as glue to all the separate components of an app. Am I wrong?
You're not wrong. It's definitely one way to solve it. I just find it harder to jump into a project with heavy reliance on global events and be able to quickly understand what's going on. It gets even harder if you have events firing other events.
This is extremely picky. "Smart-float" is the name of a custom directive that is used as an example. The term "smart float" can be used as a React component name just as easily. In that case, your React component would "sound like C++".
Also, the "we wouldn't have built many apps" part is a stretch. It's actually the opposite, AngularJS is extremely popular and the most successful current JS framework.
I don't see the problem. `<span ng-show="form.length.$error.float">` makes total sense to me. You show the content of that span when form.length.$error.float is truthy. Probably when it exists.
And yes, AngularJS absolutely defines its own language. The directives create an enhanced HTML (that you can enhance even further), and it has its own expression language where you can ask the value of `form.length.$error.float` without fearing null pointers.
This is basically what Angular is about, and why it works as nicely and cleanly as it does. And it's true; learning a new framework is absolutely comparable to learning a new language. Rails is not simply standard Ruby; it defines loads of new stuff that automatically handles things for you below the surface. Spring completely changes the way you work with Java. Grails has its own DSLs for various tasks.
Every framework has a learning curve. And a framework that doesn't change how you think is as useless to learn as a language that doesn't change how you think. But if you don't like learning, you can always simply stick to what you're familiar with.
I only looked superficially at React, so maybe I got something wrong, but the HTML/XML intermingled with Javascript seems extremely off-putting to me, akin to ASP/JSP/PHP.
'JSX' is also what made me avoid React at first. But once I started using it, it made perfect sense.
The 'JSX' is just compiled to Javascript anyway, it's just more convenient for deep nesting of html elements within a component.
In more recent talks the React devs have avoided using JSX in examples and instead use the compiled form as JSX goes far enough from what people expect that it turns people away before they've given it a chance.
The most important idea to take from React is that UI components are much simpler when they are state machines.
The thing that sold me on React was this statement: "Most people make the mistake that the DOM is a place you put things."
The DOM is what the user sees. That's all. With React, you have a virtual DOM that can hold everything, not just what the user sees. It's a pure data structure, and can be manipulated as such.
Because that DOM is a pure data structure, React can figure out for you what parts have changed, and re-render those bits as needed.
I agree with you that React's virtual DOM is a real breakthrough. However, that doesn't make all of React worthwhile. Other frameworks can (and should) integrate a virtual DOM.
It's just the first impression. React view code is not HTML in pure sense—it's a DSL for describing virtual DOM tree (that happens to look a lot like HTML for obvious reasons).
You won't regret taking a couple of hours to try to build something simple with it.
But then again, is the comparison between Angular and React even a valid one? After all, Angular is more or less MVC with a lot of functionality for resource routing, component building whereas React seems like a view templating library. So if I am not wrong, we are comparing a framework with a targeted library.
The weakness with Angular is not the view imo, but the $apply-cycle which can bog down even a modern browser with moderately sized data.
React basically eliminates the need for something like the apply cycle, because you just re-render from the top whenever something changes. React is the view layer, but its approach is different enough that you may restructure (and simplify) the rest of your app as a result.
> How semantic is ng-show="form.length.$error.float?
I agree with your conclusion, but I think you're misusing semantics. This isn't semantic, but neither would anything else be. As soon as we get to using logic, we don't have semantics.
That line is unclear and not easy to understand. That is why I object to it.
Thanks; I will read up on the proper definition. I had been using it to imply 'meaning' (more or less), from Semantics which wiki says is the 'study of meaning'.
'unclear' is a better choice. And less pretentious too, than 'semantic'.
>How semantic is ng-show="form.length.$error.float?
I could not care less. I find that talk about web programming has been polluted by non-terms like "semantic" that doesn't mean anything specific (in the context).
Especially the whole hoopla with regard to "semantic HTML", with designers (who don't know much if anything about programming, and just heard this "semantic" term from a few industry fad gurus) using it to insist developers should treat HTML as a format for reuse (as if the reason we write HTML is to enable better screen scrapping).
Endless discussions about whether it's ok to a DIV if it's purely for display purposes of not, as if HTML/CSS dont already make a clusterfuck of separating markup from presentation.
Fuck "semantic HTML" -- it's a presentation format, that also happens to have a not-that-functional styling component. If you wan't reuse and semantics, get those from the data level (the db, the REST endpoint, etc), not from code meant for browsers.
That's not necessarily semantic, but that's declarative and it's what I like with Angular. No need to think cinematic such as "when this change, update that", but just declare links.
Angular is starting to remind me more and more of JSF + CDI which immediately triggers a negative visceral reaction for me. But, if I step back and think for a moment, most of what I despised about working with JSF was related to the amount of state it needs to maintain between the browser and server. If that state is completely contained on the client and the client maintains a stateless connection to the server, it may actually work out well.
I have multiple friends who are very excited about Angular and one who is very excited about Knockout, so I am convinced that they are getting something right.
I am personally much more attracted to the reactive style of Meteor's Blaze or ReactJS. It seems much easier for me to reason about, but maybe this has something to do with my background in video games which means that a render-loop seems really natural to me.
I don't have enough real world experience with the former to make a comparison so I'd love to hear from someone who is able to properly compare the two styles what the real pros and cons are.
I've worked on one large project with Angular, and a couple of medium sized ones in Meteor (using the original UI system) and am working on a POC project with ReactJS at the moment.
I think Angular is better for "slightly more traditional" webapps such as dashboards. Its directives are nice for building small custom widgets, and the thin model wrappers $http and $resource can be useful (though I'm looking forward to what they add to these in v2.0). Data-binding is very straightforward and easy to understand.
I've built a couple of projects in Meteor, and I'm still a fan, though I've yet to have a real use case for the realtime (pub/sub) stuff: I'm still making straightforward webapps that would probably be just as easy (if not easier) to build in Angular or Backbone. The reason I'm using Meteor is more for productivity than for reactive realtime: I love that I get Mongo, a watched asset pipeline and a bunch of other stuff for free. I love being able to share/move code around easily between the client and server.
Sometimes the reactivity in Meteor can be quite subtle and difficult to get your head around, and I wish I was just using straightforward webservices instead; other times it's a productivity booster and keeps things simpler.
ReactJS is a really nice concise view library, with some extra stuff that Facebook put in that I'm not sure should really be in there (e.g. the synthetic events) and should maybe be a module instead (an approach I'm very happy to see Angular taking). ReactJS does for views and templates what Meteor does for client-server. It's also got its share of subtleties and gotchas though.
I'm also from a video games background and am also tending to favour Meteor and ReactJS. But I do think the extra power of these technologies brings an extra set of complexity and things to watch out for. But then Angular has transclusions, so......
Big +1 to Facebook breaking down React into smaller parts that are reusable. Makes it hard to point out where there are weaknesses in the library with the "all or nothing" system of dependencies.
"All code in Angular 2 is already being written in ES6. As ES6 doesn’t run in browsers today, we’re using the Traceur compiler to generate the nice ES5 that runs everywhere. We’re working with the Traceur team to build support for a few extensions like annotations and assertions."
While "cool" and "clever" and any other half-positive adjective you like, it does mean things will literally be hell to debug until native ES6 support is available in current browsers.
I thought the internals of Angular already had a reputation for being pretty horrible and indecipherable already. I doubt this will improve on any of that criticism.
I write Ember applications using CoffeeScript plus ES6 module extensions, and everything gets transpiled down to JavaScript. And yet, I find it pretty easy to debug the generated code: It looks more-or-less like what I wrote, it's nicely indented, and there's just a little extra boilerplate here and there.
Do you have any reason to believe that the Traceur compiler generates unreadable output with Angular?
Really? Do you mean it's just super optimized and advanced, or coded badly? I kind of always assumed that famous libraries built by a team of open source geniuses would be super tight and tested for major errors and performance inefficiencies.
No snark, I really did think this. Of course, Wordpress and Drupal do seem to have a lot of crazy architectural decisions that made maintenance difficult, so maybe I am just completely off.
Here are two JS files from a framework that I've written myself over the past few years, for my own use. Is the angular source code pretty much like this, or much more optimized?
It seems that they go as far as creating their own benchmark tool to optimize their performance[1]. They also seem to have a logging tool in the works just to expose the stuff going on under the hood[2].
That may be, but the rug has been pulled out from under "literally". One will never again be able to assert something ... literally ... and expect to be believed.
I've taken to repeating it twice. For example, "When the board saw the CEO's plans for the company-wide reorganization, they literally-literally cut him off at the knees"
(As in, they drew a sword and severed his limbs, such that literal-literal blood was everywhere)
That's the reason I've not done anything more than dabble with it. My experiences building anything that wasn't Angular from the foundation up left me frustrated.
This is great for XYZ, but I need to do AB123C... well... shit.
On the one side, yes; on the other though, it's a shame that the technologies we use or want to use for web applications right now (HTML5, ES6, etc) are just not done, standardized or implemented yet.
JS not good enough? We'll invent new languages; Dart, Typescript, Coffeescript, etc. ES6 not yet done? We'll build a transpiler so we can fiddle with it until it's done - if ever.
I just wish the standardisation processes for web technologies would go faster. We get small revolutions every 2 years or so, but the standards behind them only get updated every decade.
Unless they plan to release this 4-5 years from now isn't it a bit optimistic to release something intended to be used in production for IE11 only? For most real-world applications it's kind of nice to be able to support anything with a browser share over 1-2%, with this requirement it places Angular squarely in the 'startups for the tech crowd'-only world.
The intention is to use it with Traceur, which is an ES6->JS transpiler that works right now. It's like writing a framework in CoffeeScript or dart2js - users shouldn't care about the implementation language, the ultimate binary is just a blob of JS that works on browsers - except that the source code will eventually run natively in the browser.
> Dependency Injection is still a key differentiator between Angular and other client side frameworks
Why not just take Require.JS and use it as a dependency injector, like any other client-side frameworks allow you to do?
IMO Angular is trying too hard to be everything, while it is now de facto a template system with an excellent support of custom directives and two-way data-binding.
For example, Angular could be a good choice for a View layer of an app built on top of Backbone, since it moves away from opinionating the View layer. But it's just too much fuss happening around this templating system in Angular.
Require.JS is a service locator. It's not an inversion of control dependency injector. You can swap in a different service locator for your tests, but it's messier than just directly passing in different dependencies for your tests.
Well yes, Require.JS is not strictly speaking a dependency injector (however you can use it as one), but underlying AMD pattern is a very good example of IoC. And this allows all kinds of interesting stuff to do with your codebase - for example, use Require.JS for development, simplified module loader for production and, if Require.js configs become messy in your specific project, you can just load a module for your tests purposes directly, passing all of it's dependencies manually. I don't see what exactly Angular's dependency management adds to this.
RequireJS is not a service locator,it's a module loader. It doesnt instanciate anything.AngularJS DI IS a service locator, not a dependency injection container.
You're confused. A service locator doesn't have to instantiate anything.
Angular's injector, like Guice's injector is a service locator. Because the normal way to use AngularJS is to simply list your dependencies instead of requesting what you want from an injector instance, it is an IOC DI framework.
"We're in early stages of designing Angular 2.0, but some of our goals are:
- Angular will use the underlying web platform features available to it (e.g. Node.bind, template integration, Custom Elements, etc...)
- Web Components (Polymer, Ember, or any other framework/library) will work seamlessly within Angular apps and directives.
- Components written in Angular will export to Web Components (to be used by Polymer, Ember, or any other framework/library) .
We're working actively with the MDV, Web Components, and Polymer teams to make sure that our approaches remain compatible as all these projects evolve (and they will still evolve).
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.
I don't like it at all; the Http and Base64 imports require three tokens / lines to import, while the existing DI just needed one. RequireJS requires two (array entry, callback parameter).
I'll stick to ES 5 / Angular 1.2 if we're required to write this much boilerplate to achieve the same thing.
I was at ng-conf back in January and there were some great presentations on a lot of these topics, such as the new DI model. I'll have to pull out my notes.
It's great to see a framework team take a fundamentally new approach. Many frameworks get stuck in a mindset while other frameworks pop around them with new and more innovative approaches.
As to the mobile-first changes, we'll see - I have some reservations on using Angular on lower specced mobiles, for the $watch()-cycle seems to me huge drain on batteries. But since the Angular guys know what they are doing, I am looking forward to nothing but goodness.
Why not just include restangular as one of the resource modules if they decide to go all-out modular?
I am hoping for multiple ngIncludes and a bit easier development of directives, other than that, keep up the good work, guys :)
Should this be marked as Angular 2.0 BETA? The docs say that it is not done yet.
Also, the docs say that they do not know when they will be done. While I can understand that we may not know problem that arise, it is a pet peeve of mine that I never have a an idea when Drupal 8 will be released. I know that open source contributions are hard to track, we have to estimate (guess) when our projects will be done in our work, so why can we not do it for the projects we love?
It's not necessarily a beta since you can't start using the half-baked product right away. It's more of a foreseen product announcement. Awkward for sure though.
Unfortunately, Angular 2.0 sounds like a project killer. Let's abandon the huge effort put in by the community, and build this shiny new framework with all the latest and greatest (and currently unsupported) tools. Let's support everything we can possibly foresee, and make the ultimate framework that will never need improvement. That is until Angular 3.0, when we'll need to support ES8...
Rewriting a successful framework with no backward support is suicide. Please read this link before continuing on this path: http://www.joelonsoftware.com/articles/fog0000000069.html. Another informative example is Perl 6. The 'rewrite' killed Perl. Microsoft also did this time after time, forcing developers to constantly rewrite their applications instead of spending time writing new products. Even Python 3, with it's limited incompatibilities, had a very negative effect on the community: https://programmers.stackexchange.com/questions/63859/why-do....
Why should I bother supporting Angular 2.0, since 2 years from now the developers are going to get bored and want Angular 3.0? The community is NOT going to take the time to rewrite all their code to scratch your itch. My time is very limited, and I need to be selective where I use it. I love Angular, but there is zero chance I will rewrite any of my code for Angular 2.0. It's not going to happen. I'm quite certain that my sentiments are shared by other developers who have put in far more time and effort than I have.
My strong advice is to fix and optimize what you have. If there are areas that need rewriting or rearchitecting, then do it, but leave a clear upgrade path and don't break existing apps where possible. Sorry, but that's how software works.
You have a ground breaking, beautifully designed framework. Please don't destroy it because it's not perfect. Nothing is.
Can someone at Google please talk some sense into the developers running this project?
I realize this is a basic question, but how does synchronization between the client and server work with Angular? I understand the concept of data-binding once you've retrieved the data to a data-structure on the client-side, thus causing that data to update the view in the DOM, but what triggers a client-side update when your server-side data changes? Do you need to poll a REST service to check for changes? Does the server push the change to the client side? Say there's no client-action triggering an update? What causes the new server-data to get pushed to the client?
AngularJS is not a server-side framework and therefore it is agnostic on that question. You can do it however you like and you can even create directives that keep the client model synchronized with server-side, but it doesn't come out of the box.
So if you want to poll a service periodically, you can do that ... or if you want to use a websocket and just leave a pipe open to refresh your client-side model ... you can do that too? Got it. Thanks.
Yep. The $http service in angular core basically does your standard Http stuff (with some nifty additions like caching and promises), but people have built services to do sockets, sails, handle server-side events, etc.
An yet another simple text blog that is 100%, completely, utterly broken an useless without JavaScript enable. There isn't even any compelling feature. Besides the sliding out mention there is _no_ reason JavaScript even needs to be on this page.
I don't get why BlogSpot an so many other sites require javascript to o absolutely nothing of value just to see the site. It's maddening and appalling.
Also, I'm surprised I got downvoted for saying that we should be considering the disabled when making decisions on how to structure a blog. I know accessibility isn't _cool_ but it's the right thing to do, especially for a text-based site, like a blog.
(PS: mendelk, I'm not accusing you of downvoting me)
According to a recent podcast I listened to[1] about a blind Software user, it seemed like there is a lot of issues with the current generation of Screen Readers. This includes issues with JS.
The new DI system looks promising, looks like they are trying to make a JS version of Guice which I love in java. The whole thing of using annotations in javascript seems a bit out of place though especially when ide/text don't support them. Also the logging framework, seems they are making sure that they cover some "enterprise" concerns.
If you are going to use Backbone for the first time in a big project, beware that you don't end up with low-level code that is duplicated in different flavours all over the place.
When you have implemented features enough to notice that it takes too many steps to make new views that resemble old ones, ease off from feature building, and make proper custom abstractions suitable for that particular project.
Also check out Backbone extension: Marionette for modularizing and backbone-documentmodel for non-linear forms.
> 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?
Is this supposed to sell Backbone? Because I'm on a similar curve with Angular with just the online docs. Doing stuff in Angular is really unbelievably easy once you let go of your old preconceptions. It's a new way of thinking, but it's one that's very effective.
That's what bothers me. AngularJS is not going to be a big enough step (time will tell) for native apps to suddenly disappear and for everyone to go web app. They should have continued focus on a desktop-first approach since that's where they can really shine. What I see here with this announcement is that they are optimizing for the limited resources of the mobile device rather than the more powerful applications and usage patterns that we see on desktops.
Here is an example from the site:
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 problem is that some frameworks assume that everything should be done with using configuration. What ends up happening is that the configuration (and conventions) becomes its own language. This is a waste of time in the long term; library conventions are not a portable skill set.Some things are just better off with plain JS and simple HTML. FB/Instagram's React is a much better approach to building HTML UIs; you get readable JS and HTML instead of configuration mess.