How Angular Lets Us Iterate Like Crazy | Hacker News Reader

How Angular Lets Us Iterate Like Crazy

blog.chartbeat.com

43 pointsyonasb47 comments

There's a certain irony in the poster dismissing Java with one hand:

    "In effect, to the developer it 'feels like writing Java,' which as we all know, is a terrible feeling"

While professing the benefits of something which looks rather similar to Java tag libraries.

    <graph class="visitor-graph"> 
        <axis position="left"></axis> 
        <axis position="bottom"></axis> 
        <line name="typical-week" line-data="model.series.typicalWeek"></line> 
        <line name="this-week" line-data="model.series.thisWeek"></line> 
        <line name="last-week" line-data="model.series.lastWeek"></line> 
    </graph>

"If you’re thinking, “that’s not HTML anymore! What are these graph, line, and axis elements?”—well, that’s the point, Angular allows us to “extend HTML” to create those elements!"

    <cewolf:chart id="line" title="Page View Statistics" type="line" xaxislabel="Page" yaxislabel="Views"> 
        <cewolf:data> 
            <cewolf:producer id="pageViews"/> 
        </cewolf:data> 
    </cewolf:chart>

That's from a tag library released in June, 2002.

Lest angry Java-haters accuse me of trying to extol the virtues of JSPs, taglibs et al, this is not the point of my post. I'm indicating the commonalities between two modes of development separated by more than a decade, which in the churnful world of technology might as well be separate geologic eras.

It's interesting to compare these two things (particularly when a prior effort has fallen by the wayside) to determine if you are implementing the same concept in a new guise, or if you are removing the issues that people had with prior models which led to their lack of use.

Don't forget the dependency injection pattern that Angular uses all over the place. That smells like Java, too. :)

Definitely! I've used Spring's DI container before and while I wasn't a huge fan of the (at the time) XML config, I found the experience to be pretty nice.

Hi, article author here. This was more a comment on the verbosity of Google Closure's syntax. If you're not familiar with it, to get the most out of the closure compiler, you have to add type annotations in javascript comments for pretty much every function parameter, return value, constant, etc. Otherwise the compiler's static analysis doesn't really have much to work with. This makes it kind of a pain to javascript devs who are not used to this sort of thing.

Coming from Java, I probably found it a little less annoying than most javascript devs. Although in Java (as I mentioned in a footnote) you have really powerful and mature tooling like Eclipse, which--whatever else you think of it--does really help with Java's general verbosity. You're not going to find the same sort of tool help for dealing with Closure javascript.

"She" is becoming such a gimmick now.

Given the english language requires a gender-specific pronoun (I grew up saying "They" to the chagrin of my teacher) it always makes me a little bit happy to see She in texts. As a woman it makes you realise how much you don't see it. So it stops being a gimmick once the powers that be let us use a non-gendered pronoun ("they" is perfectly fine to me). Or we see a 50/50 split and rewrite the history books accordingly?

Anyway, on topic: we also feel the same way about Angular. Having our APIs abstracted from the beginning into services/factories means we just throw code into a new directive or controller and boom: instant functionality that doesn't cost us a million hours.

When I see "she" it makes me reflexively stop and look back to make sure I haven't missed something, wondering, "who is this 'she', I must have skipped the paragraph introducing the subject."

This is definitely bad for readability, the user, and all that. Please, anyone reading this who complains about line-heights and font-sizes, pay attention to grammar as well.

Im one to agree. I can see how a woman would be pleased by seeing this, but, when I scroll up and notice it's a "Nick" who wrote the article, all I can think is; huh? Is this guy trying to be edgy? So I re-read, like you said, and there is no mention of a she.

It's just awkward, please stop with the forced gender equality if that's what that is. If it's just being playful then I guess you can shrug it off.

When I see a comment like this, it makes me reflexively stop and look back to see if the commenter is trying to make a joke, or is really so dense and petty that they're trying to make this an issue.

On HN? Do you really have to ask?

From the article (the first time "she" is used):

"The developer refuses. She’s worked too hard on Feature X, and dammit, you’ll have to pry it from her cold dead hands!!!"

With the exception of the unnecessary extra !! I don't see what is wrong with the grammer, it's clear in this context that "she" is the developer.

"Let's artificially use the statistically unlikely case that the developer is a woman, in order to inspire more women to be programmers"...

What kind of BS magic thinking is that?

If you want to inspire women, teach them about the technology as girls and encourage those who like to work with it.

Pronouns ain't where it's at.

This seems rather a stretch , I don't see anybody suggesting that this is a panacea but I see no downside to this approach.

There is no loss of clarity in writing whether your hypothetical developer is a "he" , "she" or any other pronoun. It is certainly preferable to clumsily using "they".

I disagree with you. Although I stick to "they" as I think it's perfectly fine grammar wise, you getting upset because of your own bias and thinking it's an issue because the author wrote "she" instead of "he" is a bit silly, in my opinion.

Edit: Oh, and language has a massive effect on our thinking patterns, so yeah, you actual could possibly make the case that pronouns matter. They don't to me, at all, and if they "don't" to you, why express frustration or call it "BS"?

Maybe the problem is with you, and not with the text?

As far as I am aware 'he' has two meanings in common parlance, one gender neutral and one specifically referring to males. 'she' on the other hand has only one meaning, it always specifically refers to females. When people use 'she' when not referring to a woman this always strikes me as slightly weird, just like it always strikes me as slightly weird when I read old quotes that specifically refer to men, e.g.:

"Common sense is the most widely shared commodity in the world, for every man is convinced that he is well supplied with it." -- Rene Decartes

>As far as I am aware 'he' has two meanings in common parlance, one gender neutral and one specifically referring to males.

That works, if you were educated before 1960: "The use of he to refer to a person of unknown gender was prescribed by manuals of style and school textbooks from the early 18th century until around the 1960s" [1]

The thing is, you have read, most of your life, seeing male pronouns. I was a young teenage girl when I realised this and it made me feel left out, like I'd never be relevant. Acknowledging half the population is a good start - I like those programming books for example where Alice and Bob are equally represented.

[1] http://en.wikipedia.org/wiki/Gender-specific_and_gender-neut...

I have been looking into Angular, however I am yet to find it any productive gain as being told here.

From what I was able to find out, there isn't any UI component framework available for Angular with the same set of components offering as jQuery has.

For developer teams that haven't a clue about CSS dark magic as guys with designer background have, this is a big impediment to use Angular.

I have looked into UI Bootstrap, but is still seems work in progress.

Is there any UI component framework for Angular?

Look at angular-ui.

A lot of people just invoke jQuery from directives. Sometimes I catch myself doing it from the controller, although that is definitely bad practice.

Thanks for the reply. Angula-UI seems a bit too simple in terms of available set of components.

I got the idea that although you can use jQuery, it is an anti-pattern and not guaranteed to always work. At least from what I could find in SO and blogs.

My main problem is that I and many others in our teams, don't have any problem doing native UIs, but always get lost in the HTML/CSS/JavaScript jungle without designer help. Regardless of the experience level in web projects.

> I got the idea that although you can use jQuery, it is an anti-pattern and not guaranteed to always work. At least from what I could find in SO and blogs.

Only jQuery haters say that. jQuery is totally compatible with Angular,and Angular ships with its own jQuery lite, replaced by jQuery when available. The only thing you need to do is wrap jQuery calls into a directive. I use jQuery and plugins all the time with Angular, never had a problem ,as long i dont call jQuery from a controller , only in directives.

Thanks for the info.

Ionic is pretty good if you're looking for the whole flat iOS7 look

> UI Bootstrap, but is still seems work in progress.

If by work in progress you mean that it's not ready to be used, then you're mistaken. I use it in my current project a lot (started 6+ months ago).

I meant it does not offer as many components as the jQuery based version.

AngularJS is the best tool for building views that I have come across thus far in javascript.

When I write a view (most of my web apps consume JSON and display it to our end users) Angular leaves me with the cleanest markup I've been able to write to date.

It does seem to get slightly unwieldy if I want to start using additional libraries outside the scope of Angular (such as when I needed to add Google Charts), but for iterating it's the slickest thing since the invention of the ice cube.

I'm not so sure iterating like crazy is a good thing.

Well, the alternative is working for days / weeks on a feature that the end-user may not even use (is the message I'm getting from this article). Being able to create and alter a feature quickly is important in an agile environment.

There are better ways to discover whether a feature is wanted than hacking up a test version and seeing if the users use it. The idea is to test whether people want it before that stage. You can ask them, but often they'll say yes regardless because things often sound great. On the most basic level, adding a UI element that responds with nothing more than a "Coming soon!" message and measuring if anyone clicks it works brilliantly.

That has to be one of the most frustrating UI patterns out there, clicking a button and not knowing whether it will do what it says or say "haha, nope!". It's bad enough when apps do this to try and persuade you to upgrade to the pro version.

What you want to know is not just whether people click the button , but whether having a certain feature available changes the way that people actually use your application.

Doesn't that have essentially the same problem as asking? If is see a new UI element after an update to an app I use, of course I'm going to click it to see what it is, even if it looks like something I don't actually need.

I didn't really discuss this in the article at all, but frequently we hack up a test version (or a simple graph visualization) for internal evaluation, without showing to users at all. To your point, lots of things that sound great don't end up being that great, and we can catch a lot of those things internally before even showing them to users.

What if we graph this thing over a month? Hmmm, sort of always looks like a straight line for all of our test client datasets, and you can't really gain any insight from it. Let's try something different. etc etc.

It works kind of like how chanting "are we there yet? Are we there yet?" makes long drives shorter.

To be clear, our iterating like crazy is getting customer feedback and making new features or products to test new ideas as fast as possible.

A few weeks ago I was asked to make a dashboard for a client of ours on the last evening of our hack week. In two hours I had a proof of concept up, the client had a live URL and gave us feedback immediately. We are now devoting resources to making it real. We have angular to thank for that...

Source: I work at chartbeat.

Also you should checkout our product demos, our quality of product is never sacrificed. The newest dashboards really are quite useful and beautiful.

Is this website the result of your crazy iterations?

http://i.imgur.com/jqy2kwo.png

No, that's due to Ghostery. Recognized it as soon as I saw your image. Ghostery breaks lots of sites, even those it isn't explicitly blocking.

Ghostery doesn't break "lots of sites". This is one of possibly two or three pages I've noticed in the last year that have been broken by Ghostery. That's hardly an epidemic. (But perhaps this is an issue of sampling.)

Given Ghostery's popularity, I would almost venture to blame the website for this unintended behavior, not the plugin--even if they're keeping to standards and good behavior.

Is this due to JavaScript blocking? I mean, the whole premise of using AngularJS is that the client is executing JS..

It's blocking tracking scripts/pixels/etc. If a site's JS happens to rely on some external tracker having been loaded, it can break the site. I think that's what's usually happening here. Moral of the story: don't rely on external scripts people.

I think the moral is more that if you're not going to let them track you however they want and using whoever they want, they'd rather not have you as a visitor.

I've noticed many sites that have failed load a video or something similar due to Ghostery, but it has been happening much less after the last major update. It's usually not as drastic as stripping all CSS of course, just breakage that seems like a bug on the site, until you realize you should try again after pausing Ghostery.

Ghostery blocks Chartbeat since it's an analytics provider.

Just for info: ABP Has same result. (EasyPrivacy filter)

Ghostery doesn't really break many sites, although there are still a couple.

However, in this case, CSS and JS from ChartBeat is being blocked because it's one of the tracking services that Ghostery disallows. You can whitelist, but this is probably the "correct" behaviour if you want to block tracking services.

No, that's due to web devs tying the functionality of the website to tracking services. I don't remember the last website that didn't have any tracking services, most of them have many. But that alone doesn't break the Javascript when using Ghostery, let alone the CSS. I haven't analyzed this particular website, but it would typically be that they did everything wrong, like loading the CSS via JS, or that kind of weird things web devs like to do these days, that only works fine if you give up on your privacy and security entirely.

Hi, article author here. Our blog doesn't have any functionality tied to tracking services except the tracking functionality. If you're using something that blocks all js and css from *.chartbeat.com and you're trying to read a blog post on blog.chartbeat.com, you might run into an issue though :)

I'm not using Ghostery and I'm seeing the same thing. Could be Adblock I'm using from Chrome store. https://chrome.google.com/webstore/detail/adblock-plus/cfhdo...

Reply on news.ycombinator.com