Basically, I spent the whole day programming my painting gallery and music player for my site. I’m making progress. It’s looking good. I have this abstracted music player that I built a while back (about 2 years ago with the HTML5 Media API) that I named B.Audio.js, and it has two components: the player root, and the controller, which takes a root and a PlayerUI as arguments.
From back in the day, I have probably built 50 different audio players in Flash, Java, and HTML4/5 for many different purposes for myself and for jobs over the last 10 years, and about the same amount of video players with audio. In fact, one of the music players I made that I included in my resume portfolio landed me the gig to work on the website for the video game “The Conduit”. He saw my work and gave me a call. That particular one actually included a full, 32-band, real-time FFT spectrum analyzer, as well (in Flash). And, it was part of the game itself as an in-game puzzle where you went to this site for a reward from the publisher (or something like that – can’t remember exactly what). None of this is to brag, Haha. In fact, I feel like I’m writing this to my Project Log to record my thoughts, to tell my ongoing story like I would do in a diary, pretty much like everything else in the Blog. I felt like including those tidbits would provide context for my current experiences to whomever is the reader. 🙂
So, yeah, back to the BradOrmand.com Audio Player – once I provide the audio root and playerUI to the Controller, then I can configure my client JS to manage the additional functionality specific for this site, while the core player controller can be used with different skins and functionality, even a concurrent player. I wanted to keep it open to be able to be embeddable or searchable later. I’ll cross that bridge when it comes closer to the time to augment it…
I have the B.Audio.js dispatching events to it’s subscribers and they just do what they need to do on trigger. For instance, on the music page, the “onLoadProgress( type, time, progRatio, src )” gets triggered by the core player, and it updates the UI, which it gets in it’s class constructor, but doesn’t know what kind of HTMLElement it is, but just that *is* an HTMLElement, being polymorphic, with those standard properties. That lets me make it whatever I want it to be in the UI as long as it’s a block element, and the playerUI will operate on it. Here in this call, “type” would be B.Audio.LOAD_PROGRESS, “time” is the timestamp from the event system from B.js, “progRatio” is how much has been loaded so far 0 <= r <= 1, and “src” is the URL of the track. So, anyway – that’s the kind of stuff I have been into today. Been back in that world.
To be fair, when working on large projects with a diversified team, I really do see the wisdom in using a specified library stack, and I work on a project like that at work, and have in many previous jobs. In fact, I think it’s absolutely vital to understand the popular libraries very well if you want to get a good JS job in the industry. However, it’s kind of a fun challenge to write something from the base level and write your own libraries to use (utils, MVCs, DOM tools, etc), without anything to “do it for you”. You learn about the base level. And, if you stick with them, they get better and better and better.
I think there’s something great about using what API the browsers provide natively as much as possible, going closer to the “hardware” (as possible). The new DOM core is much more advanced, lately, with better standards adoption across all browsers. For instance, supporting IE 9+ and the latest FF, Safari, and Chrome is straight easy without jQuery or any lib, actually, with no difficulty (with things like querySelector, XHR2, addEventListener, some CSS transitions and/or requestAnimationFrame, etc). If you’re supporting back to IE 6, 7, or 8… well, then – you’ll have to go back to earlier tools invented to use with those.
I do, though, make methods to abstract the funky bits like removing a specific class or getting a calculated style, and for bigger projects make MVC structures, etc. When there’s an id that needs to be gotten, for instance, I just reach for elem.getAttribute( “id” ) instead of $( elem ).attr( “id” ); And, when there’s a style that needs to be set where a class change isn’t appropriate, such as opacity animation, I just go straight for elem.style; That kinda stuff. Sometimes, it’s easy to “lose touch” with what browsers actually provide underneath (with clarity), natively, if you focus so much on higher abstractions. Promises and Deferreds, for instance… not always necessary. Never really have been, even with XHR1.
Working with the core – it’s a little bit faster, there’s no overhead to manage, keeps me practiced up with the base level and on the edge of the tech by keeping track of what the browser vendors come out with week by week. And, it’s really not that different at all from using libs in projects, in most cases – you don’t have even to learn a second (or third or 5 ) API on top of what there already is. 😉 . Personal preference, too, I guess.
I also do the same with my display programming in C for embedded systems. I’d much rather be close to the hardware and write the driver myself to learn about the different ways devices operate, what voltages they take, different power-on sequences, the rising/falling edge scheme, and etc…, because it’s something in life that I enjoy. Again, it goes along with the personal preference.
Anyway, enough about that. I hope I wasn’t that rant-y, but more presenting it from my point of view 🙂 .
I also mixed down a great copy of “Doing Fine” today. Just great stuff (compared to what I have done before). It’s really coming along. I’m finally getting to the point to where I can just really go in to the studio and ProTools and get what I want done and walk out happy. But, I didn’t always feel that way. Now, it’s rolling strong.