found drama

get oblique

Eric Clemmons re: Angular vs. React

by !undefined

In “Angular is Easy, React is Hard”, Eric Clemmons gives his perspective on the perception 1 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 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” 2 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).

  1. Myth?[↩]
  2. Formerly known as “isomorphic”; which is a whole separate discussion unto itself.[↩]

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

by !undefined

Re: Chris Coyier’s The Debate Around “Do We Even Need CSS Anymore?” post:

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

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

  1. 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.[↩]
  2. We’ve already called out React by name here. And say what you will about the AngularJS approach of sticking directive hooks into the mark-up as attributes, but that’s evidence of embracing the approach. And let’s not forget Tom Dale’s 2013 expose on progressive enhancement — and/but/so by extension we know where Ember lands on this question as well.[↩]

search term haiku: June 2015

by Rob Friesel

Stowe pinnacle trail
git merge vs. cherry-pick
Safari for Chrome

“Search Term Haiku” is a series wherein I examine this site’s log files and construct one or more haiku poems from search terms and phrases that led visitors to the site. Where possible, I attempt to keep the search phrases intact. However, as these are haiku poems, I do need to follow the rules.

“…they will go off and work in the integrated development environments…”

by !undefined
What Is Code?

Photographer: Asger Carlsen for Bloomberg Businessweek; Set Design: Dave Bryant; photo taken from original article

Paul Ford, What Is Code?

They will do their standups. And after the standups, they will go off and work in the integrated development environments and write their server-side JavaScript and their client-side JavaScript. Then they will run some tests and check their code into the source code repository, and the continuous integration server will perform tests and checks, and if all goes well, it will deploy the code–perhaps even in August, in some cloud or another. They insist that they’ll do this every day, continuous releases.

Read every word. Every one of those 38,000 goddamn words. Even if it takes you 6000 hours.

on Allspaw’s “On Being A Senior Engineer”

by !undefined

“On Being A Senior Engineer” is essential reading 1 from (surprise!) John Allspaw. Not a new post by any means, but so relevant you’ll think it was published yesterday. It’s a great reminder that what puts the “senior” in “senior engineer” is not knowing 10 languages, or having done 10,000 deploys – it’s having maturity, and perspective, and caring and concern for the peers on your team. Or as Allspaw puts it:

Being able to write a Bloom Filter in Erlang, or write multi-threaded C in your sleep is insufficient. None of that matters if no one wants to work with you. Mature engineers know that no matter how complete, elegant, or superior their designs are, it won’t matter if no one wants to work alongside them because they are assholes.

Seriously. File this one for later and come back to it once a year.

  1. And re-reading.[↩]