FretZone is a passion project I'm working on to teach myself React by cloning Guitar Pro. It's a challenge I've undertaken to keep myself hireable.
When I suddenly landed back in the frontend developer job market earlier this year, I noticed that a ton of really interesting job postings at my level wanted applicants who have experience writing production React code for at least 1-2 years.
Although I've been using Angular to build UIs almost exclusively for the past 4 years, that requirement hasn't stopped me from applying to those jobs anyway. I believe that willingness to learn, a firm grasp on programming fundamentals, and good communication skills matter more than experience with a particular tool. All the same, I figured it couldn't hurt to spend my downtime learning a new skill.
In the beginning of my React journey, I coded while following along with a ton of tutorials. The following guides stood out to me, in order of increasing complexity:
- Every UI Designer needs to learn React. Here’s why, by Sergio Nouvel
- How to React, by Kent C. Dodds
- Framer Guide to React, by Koen Bok
- Getting Started with React, by Tania Rascia
- React: Getting Started - The Complete Tutorial for 2020, by Dave Ceddia
There's a wealth of information here and elsewhere about motivations for learning React in the first place, what React is and how it works, how to make simple standalone apps that demonstrate basic React principles, and additional resources for going deeper and learning more. I'm immensely grateful that as a newbie I had access to these high-quality guides for absolutely free.
For a while, I felt like I was learning a lot. I was in motion, but not taking action. Reading reference material alone wasn't enough to solidify my understanding. After a month or two, was I at a point where I could list React as a skill on my résumé with confidence? Not really.
Aside: On switching to React from Angular#
Me a week ago: "Grid seems cool but FlexBox has always been good enough for me"— Adam Rackis (@AdamRackis) July 17, 2020
Me today: "Grind CSS Grid into a fine powder so I can snort it through a $100 bill"
I deeply relate not only to the CSS subject of this tweet—but also to how that powerful and exciting feeling feeling is just like the one I've gotten from learning React after relying solely on Angular. Like many other developers, I immediately fell in love with the developer experience, with the most outstanding reason being that React is simple. In my experience,
- JSX is easier for me to understand than
@Outputdecorators, data-binding with brackets and parentheses
[(likeThis)], and custom directives like
- React components can be extremely lightweight.
NgModules or handling dependency injection with
Providers. In contrast, React's error messages are helpful and easy to look up.
- I've found the React community to be very open and welcoming, with plenty of well-written docs and tutorials.
I'm not saying that Angular should be obliterated, or that any web app that's not built with React is trash. The takeaway is similar to that of the aforementioned tweet. Whichever frontend framework you end up using depends on the needs of your app and the skillsets of your team, just like how whichever CSS layout you should use depends on the content you're styling and how it should behave responsively.
React is a tool I'd definitely like to work with more. (The same goes for Vue, which also seems to have very little cruft besides funny-looking custom directives.) I see learning it as a solid investment, because it seems like it'll be around for a while.
Now back to my story.
The brutal job search#
While I was in this React tutorial hell, I'd sent out dozens of job applications for frontend developer jobs but hadn't received many responses. During this time I found this fascinating blog post by Josh W. Comeau that examines several salient factors in the tech job search.
With some of these factors, I was already in good shape. I'd been working as a UI/UX developer full-time in the 2 years since graduating college with a Computer Science degree. So I was well past the point where a coding bootcamp would be worthwhile.
I had less control some of the other factors, like my connections. My professional network was pretty small, and the COVID-19 pandemic had made expanding that network difficult. And being relatively early on in my career and not very entrepreneurial, starting my own business didn't seem like a viable option.
There was one factor mentioned, well within my circle of influence, that I knew would help my personal situation more than anything else. This section of Josh's post shows that some non-production side project experience with a relevant technology can have a huge impact on one's ability to get a new software engineering job. I realized that I needed get some practice using React to build UIs beyond the tutorial level.
I needed a project to work on#
Plenty of frontend framework tutorials teach you how to create a to-do list app or something. That didn't sound very exciting. Instead, I took my first step outside of tutorial hell by using React to create a music visualizer. While that was a great learning experience, and I was super stoked that it got featured on the front page of CodePen, there wasn't much farther I could go with the visualizer in terms of building web UIs. (I do plan on coding up more music visualizers to practice using creative coding tools like p5.js and three.js. I'd just like to not be unemployed anymore, first. 🙃)
To escape tutorial hell completely, I began hacking on FretZone.
FretZone is my attempt at cloning Guitar Pro, a guitar tablature editor, with React.
Why would I want to do this?
Less importantly: As a frontend developer, creating a guitar tab editor with code is an interesting problem to solve in itself, because writing guitar tabs is something that can be done entirely client-side, without any servers or backend logic. In that sense, I'm taking inspiration from Excalidraw, an open-source collaborative drawing/diagramming app made with React which doesn't store users' drawings in a database. For example: if you want to save a drawing for later, you can export it to an
.excalidraw file, which is just JSON. I plan on taking a similar approach eventually.
More importantly: There are two ideas I've heard several times in the past few months that have led me to this endeavor.
- If you're learning any new programming technology, the process will be so much more self-motivating and rewarding if you use that technology to create something that you specifically care about, and/or something that solves a specific problem that you have.
Based on these ideas, I want to do this because Guitar Pro as a piece of software is near and dear to me.
What's so great about Guitar Pro?#
First it's necessary to understand what guitar tabs are in the first place.
What are guitar tabs?#
Tablature is a format that's been used to notate music for stringed instruments like the lute since at least the 1500s. Ever since picking up the guitar in 2007, I've pored over hundreds of guitar tabs, mostly from the internet. Almost all of the tabs I found at first were basically just ASCII art, like this:
e ---------------- B ---0-1-3-0------ G -2---------0-2-- D ---------------- A ---------------- E ----------------
Tabs are the most widely accessible way to learn music on the guitar because this format is simple to make and share. The six horizontal lines represent the strings of a guitar, with the highest line corresponding to the highest-pitched string; the numbers indicate where on the guitar's neck you should press the strings with your fretting hand; and the sequence of numbers from left to right indicates the order in which the notes on each string should be played. All you need to write tabs like these are a good ear, a text editor, and a
However, as every purist guitar teacher will tell you, where text-based tabs shine in simplicity, they fail in terms of musical accuracy and expressiveness. Sure, you can type
10/12 on a string to represent a slide from the 10th fret to the 12th fret, but...
- Is the
10a grace note? If so, is it played on the beat or before the beat?
- How long does each note last in relation to the others?
- How does the reader of the tab know precisely where and how quickly to accelerando or diminuendo?
- What's the time signature? Is there a triplet feel?
- If the reader wants to improvise, what key signature is this section in?
All of these questions are answered by sheet music symbols I've been aware of since taking piano lessons as a kid. And they don't even account for guitar-specific techniques like tapping or harmonics. How can any and all of that be articulated with text alone?
Guitar Pro = tabs with superpowers#
Without any question, the most helpful (and generally least inaccurate) tabs I've come across have been Guitar Pro tabs. Those files are made specifically for Guitar Pro, a tab viewer and editor that addresses the above issues by way of and in addition to these features:
- Tablature synchronized with Western musical notation
- Audio playback
- Ability to program instruments besides guitars, like pianos and drums, to play over a full backing track
- Adjustable metronome so you can play difficult sections at half speed
- Ability to export programmed instruments as MIDI files, to aid in writing music
Guitar Pro tabs are freely available on Ultimate Guitar. Songsterr (the most popular tab site, last time I checked ) provides an interactive environment to view and hear Ultimate Guitar's Guitar Pro files, but with only limited ability to edit them. Songsterr users can submit revisions to existing tabs in the form of Guitar Pro files.
Guitar Pro tabs are also the de facto format for many artists' official transcriptions for sale, including mind-bendingly technical guitar heroes of mine like Animals as Leaders, Periphery, and Arch Echo.
I love transcription#
Guitar Pro matters to me not just because it's massively expanded my ability to learn new songs and write my own—but also because transcribing songs with it is a huge reason why I'm a frontend developer at all.
As I got into more challenging/obscure music, plenty of tabs I found—including Guitar Pro tabs—had wrong notes or were straight up missing notes, especially during fast solos. Too many songs I wanted to learn just didn't have tabs on the internet at all. (For example, who would want to tab out a hidden track 10 minutes into a song from a prog metal band's debut deathcore EP? 🙋🏽♂️)
In 2008 I began making my own tabs with Power Tab Editor, which is free, but not very feature-rich. When I was 13 I saw what Guitar Pro was capable of through a free trial, like somewhat realistic-sounding digital instruments, and determined that it was more than worth the terrifying $60 price tag.
Since then I've created dozens of Guitar Pro tabs, 20 of which I've uploaded to Ultimate Guitar. Most are metalcore songs I loved as a teenager. One of the earliest is a Power Tab of Trogdor. Over the years I've accumulated unfinished tabs for at least 70 songs that I'm waiting to share until I can get them juuust right.
As of today, my 20 uploaded tabs have totaled over 90,000 views and 1,074 favorites. All 13 that have been rated ≥ 3 times average a 4-star rating or higher. I know that those numbers mean next to nothing in today's internet. I'm just happy that my teenage self surfaced things from rabbit holes that have helped others enjoy music on a deeper level.
But what does any of that have to do with frontend development?#
Transcription is a meticulous process that takes hours and hours. It certainly speeds things up if I can find video footage of the original artists performing each song, but not by a lot. Despite the tedium, I find the activity to be very zen. And it's remarkably gratifying to work out an accurate transcription of even a single riff or lick, and save it for posterity. It's so much plain old nerdy fun that I started transcribing non-guitar parts too. While the act of transcribing songs I want to play has undeniably made me a more skilled guitarist, it's also made me more well-rounded musician by strengthening my appreciation for instruments I don't play, like drums.
If you're a web developer, maybe some of this sounds familiar:
- The steps of imagining a result, then typing some stuff into a computer to make it a reality.
- The immediate feedback between editing a file and noticing how it changes that result.
- Memorizing a bunch of keyboard shortcuts to make your life easier.
Isn't this just reinventing the wheel?#
Yes. Learning a highly marketable skill like React, along with how invested I am in the app that I'm cloning, are already sufficient reasons for me to want to do this. But there are other small reasons why making a web clone of an existing app might be a good idea. For instance, one Guitar Pro license will only let you install it on up to 5 different machines.
And there's totally a use case for a free browser-based tab editor. Imagine being able to just open a URL and quickly jot down a short melody or riff in your head, without having to install anything! (I've needed this in an office setting on more than one occasion.) Noteflight offers a comparable experience, but you can only input notes using staves, not tabs. The latter are far more intuitive for me.
I've been taking a lot of notes on FretZone since starting 5 months ago, thinking I'd put all of what I learned into a single blog post. But because I'm using it to learn React from scratch, there are way too many problems and solutions to all fit together in one post. So this is going to be just the first post in a series.
FretZone is minimally working! At the time of writing, there's no audio playback, no musical notation graphics, and no export options—but you can write text-based tabs for any number of six-string guitars in standard tuning, and the app will keep track of the length of each measure. The only available time signature is 4/4, and notes can be dotted and/or rests.
1. I’ll trace the toolbar icons as SVG later so emojis will do for now.
2. I'm a happy CSS grid convert after avoiding it for too long!#webdev #webdevelopment #thall pic.twitter.com/JOxo2dmbt5
In the beginning, I'm trying to rely on as few external libraries as possible. This is so I can struggle a bit and understand the problems that these libraries are solving. However, using Redux for state management was a choice I made early on for 4 reasons:
- Redux is listed in quite a few frontend job postings' desired skills.
- It seemed like a simple way to allow multiple components to dispatch the same action.
- Prop drilling for the
EditionPalette(left sidebar) seems like it would get ugly quickly.
- Redux's docs sold me on its promises of predictability/ease of debugging.
Though I'm open to ditching Redux entirely and just using vanilla React's
useReducer if possible.
Style-wise: While the BEM class naming convention has made FretZone's CSS pretty easy to write, I'm leaning towards using
styled-components, because I like the API and the fact that it removes the need for a CSS file separate from its component's JSX file.
For now I don't plan to monetize FretZone since it's just a fun educational side project.
I may have bitten off more than I can chew, and I may not ever truly finish cloning Guitar Pro. As I'm digging through Guitar Pro's UI to replicate it, I'm unearthing features that I never even knew it had, like a modal dialog that determines the exact scale/mode of a selected sequence of notes!
But this nascent project, massive in scope as it is, has been loads of fun so far. And I've learned so much already! I definitely recommend the clone-your-favorite-app approach for anyone learning a new tool/framework. It's a rough work in progress and needs to be refactored in several places, but I've gotten many more interviews since starting this project, in a few of which I've been asked to explain some of its code.
While you're here: If you know any guitarists and/or frontend developers who might be interested in following this project, please have them shoot me an email or a message on Twitter! If I gather enough interest, I may publish a semiregular newsletter, or just anounce updates via FretZone's Twitter account.