"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!"
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 :)
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.
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"?
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".
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.
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.
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.