found drama

get oblique

Tag Archives: AngularJS

9 thoughts about 4 hours with AngularJS 2

by !undefined

Long story short: I was only able to give a couple hours of dev time to my hack team at our company’s hackathon yesterday. We chose AngularJS 2 as the backbone of our app’s front-end because… Well: why not take the developer preview for a test drive? Isn’t that what hackathons are for?

What follows is a short list of impressions. I haven’t meditated too deeply (or really at all) on any of these items. So here goes:

  1. “It’s just JavaScript.” This is something I said all along with AngularJS 1, but there seemed to be less ceremony here. For example, the service that we wrote? Literally “just a function”. No ng.factory() boilerplate whatsoever. Grade: A-
  2. TypeScript? OMG why? The docs are basically TypeScript by default. And I have no interest in TypeScript. (Not much interest in any of the compiles-to-JS languages, beyond that which is strictly academic.) I didn’t want to go learning (re-learning? refreshing?) TypeScript on top of diving into AngularJS 2. It’s frustrating that everything is framed this way. Grade: C
  3. Whither ES6? Given the state of ES6-to-ES5 compilers, it’s pretty disappointing that their “for JavaScript” docs are still ES5. I know I just said I wasn’t willing to throw TypeScript into the mix, but I would’ve added Babel. What’s more, the official AngularJS 2 docs don’t seem to mention ES6, and I wasn’t finding any decent blog posts or how-to guides in the quickie 10 minute search I did. (An eternity in hackathon time!) Grade: C
  4. Annotations? Sure, OK. I suppose I like the idea of the @View and @Component annotations, etc. (Maybe I’ve spent too much time with Spring in Java lately?) But they’re also restricted to TypeScript (vide supra) and the way that the translate into ES5 was a little… clunky? Seems like this is the price to pay for getting rid of some of ye olde AngluarJS 1 ceremony. Grade: B-
  5. Per-component bootstrapping. This one was confusing at first. Under AngularJS 1, you applied that ng-app directive somewhere in the mark-up (and pretty much only once) and the framework magically started up your app. Here, you define your components as directives (directives as components? either way: win!) and drop the associated mark-up into the DOM but… then what? The examples didn’t mention this but you’ve then got to explicitly call ng.bootstrap() on the function associated with that ~~directive~~ component. So once past the initial confusion of “why isn’t this working?” – it’s actually kind of refreshing, and promising because you can more easily build an app comprised of logically partitioned components. Grade: B+
  6. The docs reflect the framework status. I don’t know of a nicer way to put that point. Although some have accused me of being delusional, I always thought that the AngularJS 1 docs were pretty good. I think the AngularJS 2 docs could be good. They’re off to a decent start. But there are gaps. Unmentioned quirks. Unupdated sections. Inaccuracies. You can muddle through it, but it takes some persistence. Grade: C+
  7. All the low-level dependency injection. Unless I’m missing something (see my notes about the docs, vide supra) you need to do a whole bunch of annotation and configuration to get the dependency injection to work. Which is good because it removes a bunch of the Function.toString() magic that was much derided and the source of so much consternation. But in my main component, I had to set the bindings for the DI’ed service in two places (maybe only one of them was really necessary?) and then there was the realization that any services injected into the component’s constructor weren’t really reusable by functions attached to the prototype (so much for “just JavaScript”?) because “oh right that’s not how closures work”. (Side note: I’m sure there’s a good pattern for this, but not one that was obvious to me, and/or not one that I could figure out in 4 hours in the middle of the hack team’s noisy room.) Grade: C+
  8. Template locals. AngularJS 2 has this notion of variables that are local to the template. You can annotate a given element with #someHashPrefixedReference right in the mark-up. So say something like <input #foo /> gives you instant access to that input element as foo from within the template. Which is great for those places where you just need to capture user input off of some element without necessarily going through all the ceremony of adding it to the view model. There’s just one problem: #someHashPrefixedReference won’t work. Because it’s camelCase. So the mark-up makes it #somehashprefixedreference and so you need to reference it as somehashprefixedreference. Which doesn’t exist because it’s #someHashPrefixedReference. Or maybe it does? I tried a bunch of things, one after the other, all in rapid succession, because I had to head out. But: the point is the same: #somethingLikeThis didn’t work as I expected and #somethinglikethis did, which was not what I expected. But hey… local references. Grade: B-
  9. Package manager and/or module loader: don’t leave home without one. A bonus thought: I did not init this project with a package manager or a system loader – something like Browserify or webpack or SystemJS. I know better. And I know that I know better. But boy oh boy did I miss it once I realized I had started the project and didn’t have one. (I guess I’ve just been doing too much work lately on legacy projects that don’t have them?) Oh well, live and learn. Grade: N/A (this isn’t AngularJS’s fault… but they could maybe have more of an opinion about this in the docs)

Overall grade? C+ (B- if I’m feeling generous.) Overall I think they’ve reduced the surface area of the framework, and tried even harder to align it with vanilla JavaScript. But getting up and running isn’t as simple as I’d hoped, and briding the gap from AngularJS 1 seemed to put me at a disadvantage (re: unlearning things). The lean toward TypeScript also left me with a sour taste (again vis-à-vis the current state of ES6-to-ES5 compilers), and there are some rough edges in the state of the documentation. It’s definitely not out of the developer preview stage (not that anyone said it was). I remain optimistic that when it’s announced as production-ready, that it will be a great framework to work with. But for now… let’s check back again in 3-6 months.

–

[SIDE NOTE: A quick re-hash of my background to add some color/context around the above. I’ve been “doing” front-end development for about 15 years, and doing it professionally for over 7 years. I’ve been working with AngularJS since 2012 and have used it to build at least one large non-trivial application. I have given several talks about the framework, two of them public. I wouldn’t pretend to know everything about it, but I would say that I know enough that these comments are not unfounded.]

Eric Clemmons re: Angular vs. React

by !undefined

Angular is Easy. React is Hard.:

Eric Clemmons’ perspective on the perception (myth?) that React is easier to reason about and therefore easier overall than AngularJS. Among his main criticisms of React: that it’s only solving the view problem, that you need to “bring your own architecture”, that there subtle bugs may be introduced by JSX, and that confusion around props vs. state can lead to tightly-coupled components.

Ultimately Clemmons’ opinion is that AngularJS is better for prototyping while React is a better fit for “universal” applications. He admits though that all his points may be irrelevant in the near future as newer versions of these frameworks come online. His conclusions seem even-handed and worthy of consideration (though I think he under-states how useful AngularJS can be when properly applied).

birds-eye view of JSPM and Babel for ES6

by !undefined

Building with AngularJS, JSPM, Babel, Gulp and ES6:

Unfortunately, it’s a very birds-eye-view of putting these pieces together, but it’s still worth checking out because it gives a glimpse of what it might be like. The AngularJS-specific bits offer nothing new (and frankly feel a bit out-dated), and I’m still just lukewarm on Gulp — but what’s particularly interesting is the combination of JSPM and Babel, and how that empowers developers to start using ES6-style JavaScript today.

Abraham Polishchuk on AngularJS Performance

by !undefined

AngularJS Performance in Large Applications:

Abraham Polishchuk presents us with a fairly comprehensive break-down of some performance do’s-and-don’t’s for large AngularJS applications. (Although there’s nothing in here specifically about the sizes of the applications themselves.) He covers some basic JavaScript performance techniques at the beginning before diving into the AngularJS specific items. The key takeaways seem to be (1) to limit the number and contents of scopes and (2) to avoid the AngularJS event system. Some of it reads like FUD (“Don’t use filters!”) but there’s also good advice here, especially w/r/t/ limiting scope and in particular his points about limiting the use of `$watch`.

That being said: this seems to align with my recent criticism — that it isn’t so much that AngularJS itself isn’t performant, but that it’s (arguably) too easy (using the “by default” features) to get youself into a poor performance situation.

Matt Asay: Why Web Tools Like AngularJS Need To Keep Breaking Themselves

by !undefined

Why Web Tools Like AngularJS Need To Keep Breaking Themselves:

By Matt Asay, writing for ReadWrite.

tl;dr: AngularJS 2.0 is targeting the future because the future is where we’re going and anyway let’s not forget that the existing architecture/design is at least four years old anyway, and who’s on a 10-year software development lifecycle anymore?

In large part, I think the points that he’s making are good, but easy to make. What he doesn’t seem to address, and is the thing that keeps coming up in the conversations I’ve been having, has been the real-world developer concerns around the upgrade path. Or rather: the fact that none has been communicated. In other words, “the point” of picking a framework like AngularJS has a lot to do with not wanting to solve the problems that are not central to your application’s domain. You’re building a travel planning app or a photo sharing site or a CMS or… fill in that blank with just about anything. You’re not building dependency injection and data-binding and a whole host of other abstract things because… well, that’s not what you’re customers are paying for. And I think that by and large no one minds the occasional refactor of their application, so long as the things that you’re refactoring are your features.

Not having an upgrade path is a source of anxiety because it goes from feeling like a “big refactor” to “complete rewrite”. This is the cringe that I hear in everyone’s voice.

That being said… (1) I’m still not convinced that we won’t see any upgrade path — even if it’s a painful one. And (2) I agree that we want the frameworks we’re using (when we’re using them) to be powerful and tap into the powerful underlying modern APIs.

optimize for trade-offs

by !undefined

Optimize for change. It’s the only constant.:

Alas — the snark and schadenfreude are terribly unconstructive and show a shocking lack of empathy from someone who has otherwise gotten a rather fantastic reputation for having exactly that kind of empathy.

There’s an unstated assumption that people selected AngularJS for their projects simply because it was “backed by Google” or because it was some kind of shiny thing that everyone was playing with “at the time” — and while this may be true for some, there are many who have done their homework and did their framework/library bake-offs and looked at their specific situations and said: “You know what? AngularJS is the best solution for us for these legitimate reasons.”

Right. So the schadenfreude? Not helping anyone.

Which is unfortunate, because this point is really good and really important:

As a leader on a dev team, I personally consider it too risky to invest our team’s energy in learning the intricacies of a particular framework; I want our team to learn how to solve problems in JavaScript by combining the right tools for the job.

And/but here’s the twist: your customers never give a shit about what language or framework or library you use to solve their problem, they just want you to solve the problem. In that respect, domain knowledge is more valuable than any piece of technical minutia you’re picking up along the way. Which is not to say that that technical knowledge is not important — after all, these are (probably) the tools you need to use to solve exactly the problems in that domain you’ve worked so hard to learn something about. Which brings us full circle: do you burn time writing your own thing? or searching for and stitching together the little libraries? or buy into that larger framework which is going to allow you to off-load a lot of that?

Each team needs to decide this for itself. What trade-offs are you willing to make to get where you’re going? Because don’t believe for a second that you can just pick “a loose collection of a bunch of optional modules” and say that you’ve “optimized for change”. You’re just choosing a different set of dragons to wrestle with.

And anyway, everyone needs to draw a collective deep breath and chill the hell out over this. (1) Your software choices and architecture designs are always wrong to someone. (2) Maybe this event serves as an important wake-up call to you and your team and you come out on the other side of it having learned some valuable lessons about how to build front-end apps. (3) And/or just because no AngularJS upgrade path got announced doesn’t mean there won’t be one and maybe 6 months from now there’s a blog post that reveals just how everything is going to be just fine.

Regardless: relax, don’t worry, it’s just software.

UPDATE: Just about as soon as this was published (after simmering overnight as a draft in the queue…), I saw that Joreteg has re-written the post to be… less harsh. I’ve decided to leave my post as-is because if nothing else it will serve as a reminder to myself that we can all act too hastily in our responses at times. The main points of my own response remain the same: (1) try to be constructive in your criticism; (2) do your own research and make the right choice for your team; and (3) maybe just maybe it’s still too early for everyone to freak out as much as they have.

Linkdump for July 15th

by Rob Friesel

Balance Your Work and Personal Life Like a Pro Kevin Daum at Inc.com: Make a list of the activities that give you energy and strength. Make these a priority in your life. (tagged: work-life balance ) Looking At Attribute Interpolation Workflow Changes In AngularJS Ben Nadel with a breakdown of a small but important change […]