found drama

get oblique

Category Archives: Code

Shell scripts, JavaScript pedantry, CSS fixations, Java debugging, and the rest of the polyglotism.

the illusion of control

by !undefined

“The fundamental problem with viewing JavaScript as the new VM is that it creates the illusion of control. Sure, if we are building an internal Web app, we might be able to dictate the OS/browser combination for all of our users and lock down their machines to prevent them from modifying those settings, but that’s not the reality on the open Web.”

–

Aaron Gustafson, A Fundamental Disconnect.

This isn’t (just?) FUD around JavaScript and web apps, it’s the reality. And this is the timbre of so many posts over the years: that you have no control over the ultimate runtime of your application’s interface and therefore [fill in the blank].

And so we’re left in this weird never-never land where we can’t really spend all the resources that we need to ensure that we’re reaching (literally) everyone, but neither can we justify rubber-stamping a “best in WebKit (on top of modern hardware)” banner as a way of coming in under-budget. There’s the notion that you can just follow a couple of best practices and be just fine but this doesn’t really acknowledge that not everyone doing front-end development is a Front-End Developer.

To Gustafson’s point about Hanselman’s point about JavaScript deployment basically being a VM… I wouldn’t say that he’s being unfair. After all, Hanselman is a smart guy and I must imagine that he’s making these statements in a sort of Inspired Visionary way. But at the same time… yes, calling the browser a VM is over-selling it a bit. And for all the reasons that Gustafson spells out.

from 10 seconds to 3 seconds

by !undefined

Switching Ghost From Ruby Sass to Libsass:

Paul Davis (Front-End Architect at Ghost) on how they dropped the Ruby dependency from the project and moved Ghost’s SCSS compilation to Libsass.

At the end of the piece I’m still left wondering what (if any) changes they needed to make in the SCSS source itself to support the switch, but seeing the details about how they switched up their compilation was useful.

Anne Lu: Testing with Casper-Phantom-Mocha-Chai

by !undefined

Testing with Casper-Phantom-Mocha-Chai – Anne Writes Code:

A good introductory blog post by Anne Lu about using Mocha (with Chai) in combination with CasperJS. It hits the essential points about using CasperJS, and also shows how simple it is to plug in a third-party test apparatus like Mocha. (Oddly though, her post lacks links to Mocha and Chai and I feel like some readers might get caught off-guard by the “language chains” feature of the casper-chai library.)

the programming equivalent of staring at the abject

by !undefined

“But it has always seemed to me that confronting unfathomable code is the programming equivalent of staring at the abject, of slowing down to peer into the carnage of a car wreck.”

– “The Beauty of Code”, an excerpt from Geek Sublime, by Vikram Chandra, as it appears in Paris Review.

Standard Markdown

by !undefined

Standard Markdown:

(Or Common Markdown, whatever.)

Mixed feelings about this.

As I always understood it, “the point” of Markdown was to have a (very) simple “plain text” format that you could scan/read easily without putting it through a parser. Because it was plain text. Right?

A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. [source]

And in that respect, there should be no need to standardize.

On the other hand, Markdown is so widely used that it’d be nice if there were some consensus around how to “do” certain things with/in it. That being said, aren’t most of the “problems” just a result of trying to do complicated things?

Romantic Versioning

by !undefined

Why Semantic Versioning Isn’t:

Jeremy Ashkenas on SemVer. Lots of good points in here.

SemVer is a great idea, but I’ve always been a bit skeptical about how useful it really is. It’s nice to distill down the versioning to the {major}.{minor}.{patch} but ultimately you (the developer/project maintainer) are making an arbitrary best-guess decision about which number is getting incremented.

So yeah: “Romantic Versioning”.

RIP YUI

by !undefined

Important Announcement Regarding YUI:

I was never a big fan of YUI, but it was an interesting framework, and an example of how to approach the design and assembly of a large, comprehensive project. The list of contributors is long and distinguished. I’m a bit sad to see them torpedo the project, but not all together surprised either.

architecting CSS for a large scale project

by !undefined

Enduring CSS: writing style sheets for rapidly changing, long-lived projects:

Ben Frain on “architecting CSS for a large scale project”. My initial reaction: “Another one of those CSS best-practice articles…” And in many ways this is ground we’ve covered before. FUN, SMCSS, OOCSS, BEM — a CSS system by any name is just a bunch of design/organization patterns that the new member of your team isn’t going to understand. But for all the effort that Frain puts into trying to frame his “FUN” technique, it may be easy to lose sight of one of the most important points he makes:

As a concrete example; being able to delete an entire Sass partial (say 9KB) in six months time with impunity (in that I know what will and won’t be affected by the removal) is far more valuable to me than a 1KB saving enjoyed because I re-used or extended some vague abstracted styles.

And that is the key lesson.

“my fallible conclusion”

by !undefined

Opinionated Rundown of JS Frameworks:

Henrik Joreteg, writing at the &yet blog. He does a brief teardown of 5 front end MVC(ish) frameworks (their pros and cons) and while you’re busy coming up with counter-arguments against his inevitable thrust about using “no framework”, he goes on to make almost exactly all of those same points.

Only to wrap it up with what winds up feeling a bit like a sales pitch for his Ampersand framework.

This is not necessarily bad, and he does acknowledge that each team needs to decide for itself what it wants/needs in order to make it effective. At the end of the day, this isn’t a competition to find out what framework is the best (spoiler alert: none of them) — it’s a struggle to find effective work strategies so that we can build great software that solves real problems for people.