I’ll be the first to admit that I’m definitely not the best developer around, not by a long shot. But being a web developer is a dream job to me. I really love doing this, and I get paid for it? Double awesome. I’ve had non-developer friends walk by my screen after hours and ask, why are you still working? To which I say, this isn’t work stuff, it’s my own thing. The most common response is, “your screen looks exactly the same as when you actually are working”, usually accompanied with an eye-roll.
I feel that I started coding pretty late. I didn’t learn to program on a 486 running DOS when I was a kid. I only grasped HTML and CSS for real around three years ago. Before that, I was the web development equivalent of a script-kiddy, copying and pasting Frankenstein code to “build” websites. When I realised that web development was actually a form of gainful employment, I figured I’d better get good at it. And that’s when I began my daily diet of all things web design and development. Articles, podcasts, books and videos (more or less in that order) have taught me a tonne over the past two years. But nothing beats actually writing code and developing websites with a team. Experience is everything.
What are these framework thingys you speak of?
But this is what I love about the web. Most people open-source their code and share it with other developers. Want a responsive navigation menu? I’m sure there are at least twenty different plugins (I didn’t really check) that you can use, take your pick. Want some lightbox functionality for your image gallery? I’m pretty sure there are even more plugins for that. But sometimes, this easy availability can have its detriments as well.
Get the basics down pat before even touching frameworks
I’m of the opinion that before we use libraries and frameworks, we really should know how to write those functionalities on our own first. It is very important that we really understand the vanilla language we’re working with before we tack on all these fancy frameworks. Frameworks and libraries are there to help shorten development time but not at the expense of performance and code quality. Like the title says though, frameworks and libraries are not the problem, it’s the people who use them who cause problems.
Because of that, I managed to learn a lot about the ins and outs of CSS, not to mention I actually read the CSS specifications (not all of them, of course), and realised that they’re actually very readable. It’s not technical mumbo-jumbo at all, just plain simple English. The HTML specifications are also quite a good read, for anyone who is interested.
There’s a right way and a wrong way to use frameworks
Over the course of my career, I have had to work on projects that had been built with Bootstrap. I’d like to once again emphasise that Bootstrap is not the problem, it’s how people use Bootstrap that is problematic. I once inherited a project that loaded Bootstrap and jQuery, as well as jQuery UI, and amazingly, a bunch of other plugins that provided functionality which was already available in those other two libraries. My first thought was, what in the world is going on? The CSS alone was five times larger than my entire homepage. The HTML was nested six to seven levels deep, with an alphabet soup of classes, both custom and from Bootstrap itself. The CSS was also full of repeat selectors, contributing to the bloat. The clincher was that the site only needed the navigation and grid functionality from Bootstrap. All the other stuff was unused.
The thing is, full-fledged frameworks like Bootstrap and Foundation are going to be bloated because they cover everything, from responsive navigation, to modals and popovers, to embedded media and so on. Odds are, your website doesn’t even use 80% of those components. That’s not Bootstrap’s fault. The frameworks offer you the ability to only pick the stuff you need. People who don’t bother to familiarise themselves with Bootstrap’s underlying code will find it very difficult to do this. There are a number of dependencies between components, but that’s what the documentation is for. As someone who has written her fair share of technical documentation, I strongly urge ALL developers to read the documentation of whatever language, framework or library they use. All that documentation is HARD WORK. Give the developer some credit and appreciation.
If you can’t write vanilla code, you can’t use a framework
There should be (although I know it’ll never come to pass) a rule that says, until you can write the functionality yourself in the vanilla language you’re developing in, no framework goodness for you. Frameworks should only be used by people who already know how to write the code, but just want the time-saving benefits. Using frameworks is like driving. Anyone can drive, but can you drive responsibly? Don’t be that teenager who speeds while texting and chugging a six-pack. Even if you don’t kill yourself, you’ll end up killing other innocent people around you.
Some of these things I just needed to get off my chest. But I’m really against writing bad code. I don’t write the best code, but I do believe that perfection is something worth chasing. We’ll never be perfect. That’s a fact. The only reason one would continue to pursue perfection in spite of that is to enjoy the process of pursuing perfection. Sure I get that for some people, web development is just a paycheck, and to me, that’s very sad. I guess I’m just lucky to love what I do. Maybe that’s the athlete in me speaking, but I truly believe that we should take pride in the work we do and not just go through the motions. Keep on hustling, people.
Credits: OG:image from ART, DESIGN, CODE by Owen Mundy