found drama

get oblique

Tag Archives: JavaScript

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).

thoughts on that “Do We Need CSS Anymore?” post going around

by !undefined

The Debate Around “Do We Even Need CSS Anymore?”:

As with just about all approaches in software, there’s no one-size-fits-all solution, and for any given development team, they’ll need to come to their own conclusions about the trade-offs. Personally, I think the “do it all in JavaScript” approach seems like a short-sighted optimization. From the component-based perspectives like we’re seeing with React, I can see why you’d want to bundle style changes to the components — but my gut says this is a slippery slope that prioritizes developer ergonomics over all other concerns.

Consider battery performance on mobile, for example — I’d put even money that mobile browsers have been tuned for CSS performance with respect to power consumption, but there’s probably a lot more overhead in managing JavaScript changes and then having to repaint with all those low-level styles applied at the element level. (To be fair: this is a hunch, and I have no data to back this up, nor have I been able to find any in my admittedly brief and shallow search.)

Keith J. Grant’s “stop pretending” point is a legitimate claim, and regardless of which of the big front-end frameworks you’re a fan of, you’ll find that they’ve all embraced some flavor of this by now. However, I remain skeptical of the wisdom to put all the eggs in that particular basket. I still see a lot of value in keeping these concerns separated… to the extent that you can separate them at all.

“a good thing being able to configure a framework”

by !undefined

The Future of the JavaScript front-end framework:

More/less the same drum getting beaten by so many right now (see also: the Joreteg’s announcement about Ampersand, although this opinion piece is probably a better illustration of the theme) – and by that I mean: “Go ahead and provide an all-inclusive framework, but be modular so I can swap out the parts I need.” Which is great, but I would say misses a big point: discoverability of those modules. Say what you will about Spring’s role in the Java eco-system, but its worthwhile to align with a single trustworthy starting point. Part of what’s missing from the “framework fatigue” discussion is just that – that our “big frameworks” only provide a relatively thin slice of what our whole app needs and we’re in “contrib” (and/or plugin, and/or mixin, etc.) hell for everything else. This glosses over the BIG-Big frameworks of a few years ago (e.g., dojo, ExtJS, YUI), but the point stands.

(A version of this previously appeared as my comment on Prismatic.)

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.

re: Slatkin on PPK on client-side templating

by !undefined

One Big Fluke › Experimentally verified: “Why client-side templating is wrong”:

By Brett Slatkin (“One Big Fluke”).

If you followed PPK’s AngularJS post

from January (and his follow-up

client-side templating post

), then this is a worthwhile reply in its own right — and somehow I missed it when it ran.

Whereas PPK argues largely from a position of principle, Slatkin throws experiments and data at it, and while he arrives at different conclusions, he’s also gracious about the whole thing, drawing the conclusion thusly:

The take-away here is to choose the right architecture for your problem.

What’s good about this post is that he dug deep into this problem, cut it up a bunch of different ways, and remained open to the possibility that either approach might “win”. Which isn’t to say that his experiments were perfect (if some flaws aren’t obvious to you then check out the comment thread where several “improvements” are enumerated) or that there isn’t some speculation going on, but we have some good applied science here to give us a sensible picture.

Two important things here though:

First, it’s hard not to read Slatkin’s post as a refutation of PPK’s. This is unfortunate because, dogmatic though his tone may be, PPK offers up plenty of good points that you should consider when making these choices for your application. Whether you like AngularJS or not, whether you think client-side templates are a good fit for your problem or not, these thoughts are at least worth mulling over.

Which leads to my second point: it’s my sincere hope that people go with Slatkin’s real take-away, and that development teams have the discipline to look at their application, to analyze the data it’s producing about their audience etc., and to think about their goals for the future — and to design and build their applications with those data in mind. It’s entirely too easy to cargo cult decisions from posts like this one (and/or from PPK’s) and just assume that you got it right because you read something compelling from someone smart. By all means take their data into consideration, but no one else’s data is meaningful to you.

initial thoughts on Aurelia

by !undefined

Introducing Aurelia:

My first reaction is (of course) that this is why a lot of developers look at JavaScript and the web front-end see only thrash, and feel only fatigue. And in this case in particular (given Eisenberg’s previous project involvements), it smells a bit of icarian hubris.

And in that respect, you won’t find me among the early-adopters. (Taking a page from “sometimes better isn’t better if it’s different” here.)

That being said, this isn’t to suggest that there is nothing interesting happening in the Aurelia project. Count me with Tom Dale (here, and a couple of the tweets that immediately follow) in that the pluggable data-binding seems like a huge takeaway here and that we are going to see that in every framework, that you can’t have a compelling inter-op story without that. But much of the rest of what’s being pitched here (e.g., modularized code, no external dependencies, “just vanilla JavaScript”) — that’s all stuff that we’ve heard before.

(As a brief aside re: the icarian hubris remark above: let’s not lose sight of the easy-to-see flip side of that: that if anyone is going to propose a new framework, who better than someone like Eisenberg? who better than someone has been deep into other projects like this? And/but that’s also where the disappointment comes from — that it just winds up feeling like yet another technical leader decides to zig instead of zag, to go off and create a new thing instead of doing the hard work of taking something and making it better.)

Remy Sharp: My five promise patterns

by !undefined

My five promise patterns:

Remy Sharp’s write-up of several patterns that have emerged from his usage of promises. By itself I feel like this one winds up reading a lot like a few other Promise-related posts that I’ve seen (and/or like an inverse of this anti-patterns post) — but his discussion around throw vs. reject is worth the price of admission.

“more than just picking a few JavaScript solutions”

by !undefined

Planning A Front-end JavaScript Application:

Thoughtful piece by Cody Lindley over on the Telerik Developer Network. Even if you don’t agree with all of his points, he definitely sketches out a good framework for how to approach the problem of getting your application off the ground.

A couple of additional points here:

  1. Don’t get caught up in the specific technologies that Lindley is using in this article. They’re just there as examples, and he doesn’t appear to be strongly advocating for any of them — just that you consider something to fill in that blank on your project.
  2. There’s a bit of YMMV going on here depending on the specifics of your situation. That being said, most of the key lessons here should be easy to adapt — give or take a couple of questions on the checklist.

Again: look past any knee-jerk disagreements you might have (e.g., API first development; e.g., no RWD for “web apps”) and draw out the larger questions.