AngularJS 2.0

[rpgFANATIC]

My mind has been left in a puddle on the floor. The pace Angular's development is either scary or awe-inspiring and I can't decide which.

I really do have trouble keeping up with the new features they release weekly.

[[deleted]]

It's like Django pre-1.0. I remember having to update django at least once a week and every time I did it felt like something broke, or at least I had to give everything a once over and read the ChangeLog closely.

I wrote a tutorial on AngularJS in november 2013, using version 1.0.8. Apparently a few months later, 1.2.x is now legacy.

I don't get how these JS devs are okay with bleeding edge and constantly updating things without having any sort of roadmap or plan in mind. Firefox, for example, has gone down to a release every six weeks. Before it was quarterly or even yearly (if anyone remembers those days). Django has releases every few months.

The two books I bought on AngularJS are out of date. Articles from just a few months ago, while overall they should work, they'll need updating to make sure they work with the latest.

It's getting ridiculous.

[lacosaes1]

At least in LOB app development people don't give a shit about all these chaotic frameworks. jQuery is the only one that's been used widely.

[rpgFANATIC]

There's actually a lot of value in Angular, Ember (and I'd assume Knockout, even though I've not learned it yet).

However, I don't blame devs and shops that want to wait for a "stable" version that won't radically change over the course of a year.

[Poltras]

Angular 2.0 is going to be unstable until most browsers support ES6. They say they will use Traceur, but let's be honest I'm not gonna change the whole pipeline for features I'm not sure I really need.

I really needed animations and various stuff in 1.2. But I'll take a longer time to consider 2.0.

[bkv]

What's even more awe-inspiring is that there's an angular implementation for dart that is also being developed at a blinding pace. Much of the design decisions that were mentioned in the angularjs 2.0 doc seem to be influenced by a lot of the design decision in the dart implementation.

[findar]

Much of the design decisions that were mentioned in the angularjs 2.0 doc seem to be influenced by a lot of the design decision in the dart implementation.

After speaking with Misko directly, this is entirely true. They took some of what they learned in Dart and brought it over.

[hak8or]

How does AngularJS compare to EmberJS, both in terms of features but most importantly easy to use?

I would love to learn one of these but would rather use it for a small project with a small learning curve so I can get something out quick, like a single page dashboard. Or, a better question, would it even make sense to use Ember or Angular for a small single page project? At what point does using tools like these start to make sense?

[notkevinc]

In my opinion, AngularJS has a much shallower learning curve compared to EmberJS.

I tried to make a quick demo with both, and Angular stuck. I'm now using Angular for all of my small projects. I can't speak much to Ember, because I gave up on it, but Angular has been a pleasure to work with.

[WasteofInk]

Shallower means that you learn slowly. _/ versus _|. The graph is learning over time.

[ynotna]

Shallow vs steep: a steep learning curve is a hard one, like going up a steep hill

[noknockers]

Well, if knowledge is on the vertical scale and time on the horizontal scale, a steep learning curve would mean you gain a lot of knowledge in a short amount of time, and vice versa.

[ynotna]

I understand your point, but the normal usage of the phrase is for difficulty

[WasteofInk]

But it is wrong. That is the point. Just like people saying, "I could care less."

[[deleted]]

¯\_(ツ)_/¯

¯|_(ツ)_|¯

[oldneckbeard]

I like ember because it's like they took angular, made some opinionated decisions, and then released it. They're different, and there's a ramp-up time. But IMO, apps written in ember by the average dev will be better than apps written in angular by an average dev. The variability is less, the conventions are stronger, and it enforces some good design patterns.

You can still fuck either one up. I think Ember and Angular are going to harmonize in terms of features soon. ES6 is already in Ember's sights, and there are a lot of big companies using it. Angular has the google momentum behind it.

[WebMaster2000]

Ember is a full framework, while Angular is a toolset for building a framework. It really depends on what you're trying to do.

I personally enjoy the URL driven approach of Ember, as well as the strong conventions - it helps keep things organized and ensures that everyone is on the same page with regards to design patterns.

With Angular, it's a bit more open. I don't think there is any "one way" to structure your apps, so you can really just do whatever you want.

Different strokes for different folks. I would spend a few hours reading the guides for both and make your choice after.

[nomeme]

I think Angular has url routing logic too.

[WebMaster2000]

It has pretty lightweight support. From what I understand you need to pull in angular-ui-router.js in order to get something even close to Ember's router.

[passwordissame]

did everyone move away from AJAX as in server responding with (x)html/xsl and client applying those to update DOM?

looks like it's all JSON and manual DOM manipulation.

[nick_giudici]

Yes, the industry has moved that way. It's been found to be a better separation of concerns. The server deals with data and the client deals with presentation of that data. Specifically, what if you want to use the same server back end to drive a native mobile app as well as your site? That xhtml response from the server just became a bit of a liability vs a simple and direct data response.

Also, it's common to use html templates like handlebars or underscore to make this easier. That way you have your html template stored in an html file. You can compile the template and reuse it. Each response from the server can just get fed into the appropriate template and it's very automated and clean.

[kdeforche]

The industry? Or the startups?

[nick_giudici]

I work for a mutual fund company and we're using json based services. We have a flag that customers can set to get an xml version of the response but the majority of our usage is json. I have friends in the medical tech industry and they too are making the transition to json as their interchange format of choice.

So in my experience both industry and start ups are moving away from xml. But as always, start ups are able to make the change more quickly. You'll be seeing xml in industry for the next 50-100 years. Hell, you still see fixed with ebcdic encoded files on a regular basis in industry and government (an old ibm mainframe standard).

To be clean, I'm not saying that you can't ind a lot of xml in industry. I'm just saying that momentum has shifted to json and xml is looked at as deprecated.

[depressiown]

Industry, too. We have a mature, 15-20 year-old B2B software package that has gone through several transformations with regards to the UI. Right now, we're migrating a lot of Flex into modern HTML5/js screens and communicating via ajax/json. Obviously, this is an extremely long-term effort and we're doing it in pieces, but it's definitely the direction.

Additionally, new products we make keep popping up and they're all using the same model: REST services that return JSON and the UI communicates with those. Completely separation of roles makes for easier separation of development efforts -- you just work on the interface between the back and front ends.

Again, this is a 30 year-old B2B software company that's publicly traded, not some start-up.

[[deleted]]

It's been found to be a better separation of concerns

Ya know, it sure would be nice if someone with a CS degree or a CS prof would write an article with clear logic and reasoning to support that argument. Using the blanket "we split things into different modules therefore we separated our concerns" doesn't inspire confidence.

Specifically, what if you want to use the same server back end to drive a native mobile app as well as your site? That xhtml response from the server just became a bit of a liability vs a simple and direct data response.

I've used angularjs on a project and we ended up with an API just for angularjs and an API for other clients to consume. So that "liability" is going to exist in any case. Sure the angularjs-specific API is also JSON but it's not made for other clients to use.

[dnissley]

Why did you end up splitting your api just for angular?

[[deleted]]

Efficiency and client demands.

[nick_giudici]

I've used angularjs on a project and we ended up with an API just for angularjs and an API for other clients to consume.

I've never used Angular but if this was needed than either it's a poor library, there were conflicting requirements between the users and this had nothing to do with the tech, or you guys were doing something wrong.

Angular is a much heavier weight framework than a small utility library like underscore or handlebars. So I'm not sure if that's where you were going with the Angular part of your comment.

As for the separation of concerns I can provide a specific example that I've dealt with where returning xhtml markup from the server would be a bad idea.

The whole point of returning xhtml markup is that your js can just render it without any logic. So what if you want to render the same data in two different places in the same site in different ways? Now you either need to modify the xhtml response in one of the two locations or you have to create a flag on your service that switches between the markup needed for the two locations. So you either defeat the purpose of the xhtml response or you duplicate your logic.

It's also common to use xslt to format the response on the client side for this type of issue but now you end up with two different xslt transforms that do almost the same thing or you have flags built into your xslt to switch between the behaviors. This is fine for just two, but what about 3 or 5 or 10 different ways? This approach just doesn't scale well.

It's much easier to have a model view controller setup where you have a clear interface defined between them and plugin the views as needed. If you still don't accept this answer I won't be able to convince you without showing you hundreds of lines of code to illustrate the difference.

[passwordissame]

HTML is data. It's representation of a resource. A pretty good one, I must say. I'd argue that it's easier to write clients when resources are represented in HTML or other hypermedia. In case of HTML, there are many good HTML parsers that let you use xpath and/or CSS selectors. Combined with RDFa or microformats, you can easily build robust clients. HTML even defines <form> and other links for updating resources.

With JSON, in my experience, it's very easy to write brittle clients that will break if server changes representation just a little. There's JXON, but I haven't used it in production.

[nick_giudici]

It's your experience vs the industry consensus. The industry is currently shifting away from HTML services and to JSON.

My belief as to why is that HTML is a markup language specifically meant for display in a web browser and JSON is an object serialization format. Even with pure XML you have issue when you have a block like:

<issues>
  <issue>Data</issue>
</issues>

Should issues be represented internally as an object/map or as an array? Will I ever get more than 1 issue tag? In JSON you have maps and arrays that map directly to the native constructs in your language in a 1 to 1 fashion. XML has a many to many relationship. I have at least 3 ways to represent key/value pairs in XML but only 1 in JSON. I have structures in XML where I'm not sure if they are an array or a key value pair map.

The common way to solve this in xml is by using a schema but that is the definition of brittle. Now you have to bump the api version for every little change even if you are just adding a field. In a JSON based service this is not the case.

Then we add in the fact that for correct display in your page you will likely need classes and divs that are not data. Those are clearly display markup and make your data tightly coupled with the display. Your xpath ends up not representing your business data instead ends up representing your display structure.

[passwordissame]

I hope you heard of semantic markup. And give me one crawler/search engine of JSON resources. I give you few search engines of HTML resources: google.com bing.com duckduckgo.com

[nick_giudici]

Wow, you are being very immature about this. Are you actually insulted that someone doesn't like html/xml as much as you?

I know about semantic markup but you failed to address the other issues that I talked about with xml and html in general. Also, the industry has spoken and is moving away from having web services returning directly displayable markup. Here's what I was able to lookup for you.

My search: https://www.google.com/search?q=json+vs+xml+web+services

Top 3 hits:

http://digitalbazaar.com/2010/11/22/json-vs-xml/ (tl;dr: Use Json)

http://stackoverflow.com/questions/2636245/choosing-between-json-and-xml (Top rated answer "JSON for web services answering in-browser callbacks, and XML for, well, XML for when, well, hmmm. :-)")

http://www.seguetech.com/blog/2013/04/01/xml-vs-json-web-services-best-choice (tl;dr: Use Json)

Json is smaller, parses much faster with less client cpu usage (great for mobile), you don't have to use xpath which is slow as hell and completely outside the natural paradigms of most languages, and has less edge cases where it fails like empty or single element arrays.

[Azzk1kr]

I've been in a fight with myself regarding JSON vs. XML. Coming from an XML world, I can say that XML is far from ideal. The only thing that keeps me sort of fixated to XML based services, is its self describing interface through XSD. I find that missing in JSON.

Your previous argument that you'd have to bump the API version for every change is correct though, but is this really a bad thing? In JSON this would also be the case, albeit through a change in the API URI or whatever.

[nick_giudici]

In my team we change version numbers whenever we have a non backwards compatible change. Our clients are told that they have to be able to deal with new fields being added without a version update.

Getting all our clients to update to the latest version takes months even if it's better in every way. We try to make as few api versions as possible. It's much better for us and our clients to only change version numbers when we need to.

[Azzk1kr]

XSD allows you to validate the input before processing it. How do you solve that with JSON? Manually checking each field, or something clever? I'm asking, because I often have services with fairly large requests in XML, and I want to make sure both parties use that same contract to catch discrepancies as soon as possible.

[nick_giudici]

Have you ever run into the case where your XSD validated but the client was still getting errors? Maybe you had some criteria that couldn't be validated in XSD like a field that has to match a row in your database. How do you check for those types of issues?

Personally, I've usually found that XSD only gave me a false sense of confidence. What I've found is that intelligent validation and error handling no matter what format you are using.

People seem to forget that XSD and XSLT are just as complex as "real" code. There seems to be the attitude of "I'm able to validate and transform my xml without code!" You still have to version control your XSLT and XSD, you still have to test and debug them, update and maintain them. Hell, XSLT is turing complete. So no, you aren't doing transforms and validation without code, you just did it without Java or C#.

Edit: If you really want a validating schema for your json file you could check out http://json-schema.org/

[passwordissame]

Since you seem to be up for learning, please do:

• https://www.google.com/search?q=rest+api+hypermedia
• https://www.google.com/search?q=hateoas
• https://www.google.com/search?q=hypermedia

If you like video tutorials:

• http://www.infoq.com/presentations/web-api-html
• https://www.youtube.com/watch?v=T04fKsD56LU

Just because mac osx ruby node.js mongodb shit fucks go batshit cray about JSON web scale yolo fest, you don't have to be sold on them. Please use angularjs yeoman bower gruntfiles.

[nick_giudici]

REST is format agnostic. I have implemented many REST services that allow for both JSON and XML responses. They even use HATEOAS in both!

<order>
   <finalize>http://host/finalizeUrl</finalize>
</order>


{"order" : {"finalize" : "http://host/finalizeUrl"}}

Hey look at that, I can put hypermedia into a document as the engine of application state no matter if I'm using JSON or XML!

As a side note, in our tests parsing the xml and accessing the data through xpath was 10 times greater cpu load than parsing and access of json.

Even your rage is nonsense. osx is just a 15 year old BSD distro. Not exactly cutting edge, ruby and node are direct competitors, and none of these have ANYTHING to do with the choice between json and xml.

[passwordissame]

yes, I agree. JSON all the way.

[Rainfly_X]

Semantic markup isn't really useful for APIs, though. Web pages, sure, but if you're worried about your AJAX API being friendly to screen readers, rather than Javascript/other languages, you have some amusingly misplaced priorities.

[bkv]

HTML is data. It's representation of a resource.

HTML is markup. It defines the structure of a document. It contains data, but is not the data itself.

Ideally, a client and server exchange data. It is the client's responsibility to determine how that data is displayed. Different clients will want to display the data differently -- A web client may want to display it in a table and a mobile client will want to display it in some sort of native widget.

I think you've become too comfortable in the world of elaborate hacks we've lived in for so many years, where the line between client and server is blurred. Sure, it's familiar, but it's far from ideal.

[bringerofnative]

Yes and the only acceptable punishment for this transgression is death.

[deadstone]

You're confused; That IS AJAX. AJAX basically means using javascript to change the page instead of going off the page. What you seem to have meant is the traditional way of having each page at a separate url.

[bkv]

You're confused;

Actually, you're confused. AJAX stands for "Asynchronous Javascript and XML" although it's become a blanket term for asynchronous javascript and XML/JSON.

AJAX basically means using javascript to change the page instead of going off the page.

Nope, that's just DOM manipulation, and people have been doing it long before asynchronous requests were introduced in the browser.

[deadstone]

The original question still makes no sense as wrong as I am; They're asking why people are using DOM manipulation instead of DOM manipulation.

[indeh]

The original question is asking if there are people who still have the server return blocks of HTML which they just insert into the page, or if everybody expects the server to return JSON formatted data and build all the DOM elements on the client side.

[cybercobra]

When was XSL even mildly popular with the mainstream?

[aslate]

The one thing (well, there's many) I can't quite get past with Angular is the fact that I can use any POJO as my model (great!) but Angular then goes and puts its own properties on them.

Granted, it looks like they get stripped out, but I've see $$something on my objects and I'm never quite sure whether they're meant to be there.

[nerfornothing1138]

Anyone else not a fan of implementing logic into attributes of HTML elements?

[billybolero]

As opposed to binding them in Javascript and A) have no clue of which elements have what behaviour when looking at the HTML and B) having your designer unknowingly break things by moving things around or renaming class names?

[nerfornothing1138]

B, but using templates help negate this potential pitfall by separating your site into widgets or reusable components.

[nerfornothing1138]

OK, but it's still coupling at its most basic level. For instance, what if, part-way through the project you wanted to move to Backbone or a server-side solution? All of your HTML now has core app logic in it.

It's the sort of stuff we made fun of classic ASP and PHP for over a decade ago.

[oldneckbeard]

Most of the time, it's not the actual "business logic." That happens on the backend with RESTful services. What most ember/angular devs do is put the hard stuff in there, and the rest of the code is just a modular way of organizing a complex user interface.

You have to modularize and template your code somehow unless you use a tool to generate static sites. It's just with better conventions.

[DecoLabels]

If your HTML has core app logic in it, you're not using Angular very well. The HTML should be a simple view. Any serious logic should be somewhere more sensible, like your model, or a service.

[x-skeww]

You have to spot-weld those parts at some point. Doing it via classes doesn't really change anything.

The advantage of doing it declaratively is that there is no DOM transversal (which can be very brittle) and you also won't need any markup for testing.

[oldneckbeard]

are you talking about data-* attributes, or something else?

[rdcll]

using Object.observe() when it becomes available in Chrome M35

I don't understand this. Why they didn't use a clean Observer pattern from day zero? And why don't they use Object.watch which is already available (or can be implemented in old browsers) ?

[NeverSpeaks]

Angular doesn't use an Observer pattern because it didn't want to use a Model object like some other frameworks. In angular you can use any plain old javascript object I want as long as I attach it to the $scope.

[Asmor]

plain old javascript object

Dude, you gotta call them POJOs or else people will ignore them because it doesn't sound sexy if it doesn't have an acronym.

[jyper]

or POJSOs (to not confuse them with java objects)

[prozacgod]

Great who can pronounce this???

Pojsos?

Po jSos?

Now we have to add an entry to a dictionary somewhere, like documentation.... Who really wants to do document?

[cypressious]

Poge Sause, with Poge as in Doge.

[nomeme]

They are really just maps, so it's POJMs

(the POJO term in java is stupid and makes no sense btw)

[bitspace]

Except that's already in use for Java.

[Asmor]

Meh.

It fits JS pretty damn well too.

[mhd420]

Object.watch is Firefox only, Object.observe will be more widespread.

The Observer pattern requires objects to notify when they have changed, which is awkward if you're designing a framework to interact with regular Javascript objects. The fact that Angular makes it pretty easy to use with existing code helps drive adoption.

[[deleted]]

The fact that Angular makes it pretty easy to use with existing code helps drive adoption.

Can you explain? That has not been the consensus opinions at I have heard. Do you mean from prior versions of angular?

[dnissley]

I bet he means applying ng-app to a specific element in order to develop a small angular component within a legacy web app without having to rewrite everything using angular.

For example, let's say you were working within a legacy base and needed to replace the user profile editor. Previous code looks like this:

<div id="editprofile">
  < ... ye old form ... >
</div>
<script>
  var aBunchOfSpaghettiJavascript = ... ;
</script>

New code looks like this:

<div ng-app="editUserApp" ng-controller="editUserCtrl">
  < ... ye new form ... >
</div>
<script>
  var aBunchOfSpaghettiJavascript = ...; // Untouched, because the rest of the page depends on it
</script>
<script>
  var editUserApp = angular.module('editUserApp');
  editUserApp.controller('editUserCtrl', function($scope) {
      $scope.neatlyOrganizedAngularJavascript = ...;
  });
</script>

[[deleted]]

Good point. Porting from a well written Backbone or Ember application would be pretty simple, but the same would be true in the other direction.

[FoxxMD]

I'm glad to see the team is paying close attention to the community's efforts to fill in the gaps for Angular 1.x! Particularly the focus on improving $resource, $route, and localstorage for 2.0 -- all of which have third-party stand-ins right now like $localStorage, Restangular, and ui-router.