I’ve been asked a couple of times recently, as part of separate projects, to split the results of a SQL query on whitespace within. Simply put, how does one go from:
foo
foo bar
quux
blort wuu spong
to the expanded form:
foo
foo
bar
quux
blort
wuu
spong
Now I know the title sounds presumptuous, but there’s a certain methodology I’ve settled into that seems to work really well for encouraging Javascript that’s legible and safe. I thought I’d share it with anyone that doesn’t consider themselves a JS playa, in case it’s of some use to you too.
Simon makes the case for disambiguated URLs. He’s right, largely. I would say as a proviso, though, that URLs need to be hackable by the developer as well as by the user.
A comment on Ask the Wizard’s post about obviousness bemoans the non-obviousness of a particular social network’s use:
You wouldn’t happen to have a video you could link to of that person who showed you Twitter being valuable. Why? Because I (still) don’t get it…
Assaf writes about, among other things, REST as a simplifier of development against an existing system:
REST plays the same role as open source and open APIs: It eliminates tooling and vendoring as artificial barriers to adoption.
Steve compares “graceful degradation” with “progressive enhancement.” Mostly he takes issue (rightly) with the rhetorical spin that the former applies to the idea of building a website. But I think you can compare them with each other as if they were two different types of crowbar instead: two ways of prising open the task in hand.
I’m so impressed with Radiohead. I was a fan back in the days of The Bends (y’know: before they literally, if not metaphorically, sold out), and have more affection for Pablohoney than most. But in an era when it’s trivial to get whatever music you want for free off your mate who happened to buy it, they accepted that fact and gave alternative distribution a whirl. And maybe it worked and maybe it didn’t: it depends on who you’re talking to.
There are three main technologies that your browser employs to present HTML for you: XSL, CSS and Javascript. The first two of these are functional: that is, they turn your incoming (X)HTML documents into a set of functions, or behaviours if you like. Because CSS isn’t generally considered a language, let alone a functional one, then it’s worth seeing an example in both languages. Here’s the CSS:
p.intro { color: green; }
And here’s a sort-of XSL equivalent:
If you’re here, then you probably came from here, and you want to make Javascript more functional. If you didn’t come from there—and this is getting a bit like a Choose-Your-Own-Adventure book, isn’t it?—then you might want to go there first, to see if you want to be here.
In previous posts (part 1, part 2) I established the possibility that there were advantages to making Javascript more functional, to bring it in line with CSS and XSL. I didn’t say what these were, particularly, but I then provided a few bits and pieces on top of jQuery to make Javascript just that: functional and quasi-XSL in its behaviour.