We rely more and more on frameworks, but once upon a time, programmers faced a blank canvas before starting their work: the <body> tag. They’d meticulously plan, referencing entities and relationships, then hand-craft beautiful interfaces with pure HTML and a sprinkle of JavaScript.
These were the code cowboys, wrangling websites with bare-bones editors. They built structures from tables, rows, and columns indented to oblivion. A single missing closing tag could explode your monitor – a bulky 14-inch CRT with a radiation shield, no less. Legend says some, due to the sheer mental and physical fortitude required, worked in next to nothing.
The more civilized wrote CSS rules in the document header, and the bolder ones added exotic flourishes like “marquee” for fancy form submissions. After all, Internet Explorer dominated the market (around 90%!), so only quality control might notice… if they ever hit submit. But fake data in the database meant trouble with the DBAs – a now-extinct breed known for their gruff demeanor.
We often (over)praise Steve Jobs for his product innovation, marketing genius, and other traits that made him a tech. But me, I remember him for practically single-handedly killing Flash.
For the uninitiated, here’s a glimpse of Flash’s potential:
Wikipedia paints a different picture: “Adobe Flash Player… was software for creating or using primarily vector animations mainly for the web… It also evolved into a powerful tool for Rich Internet Applications and streaming audio/video…” But by July 2017, Adobe announced Flash’s demise in favor of HTML5, WebGL, and others.
Flash’s downfall stemmed from its resource-intensive animations and security vulnerabilities caused by its isolated nature within the browser. Flash content still exists, requiring the latest player (with lingering security risks). Wikipedia downplays it, but Flash even ran on Arduino!
Its scripts became so pervasive that some websites made you wait 10 seconds just to see a cartoon cat lick its paw.
Jobs had enough. He banned Flash from Apple products.
Clean slate (almost). HTML5 arrived, and social media boomed, partly thanks to Jobs and his iPhone. Now, the challenge was making websites display perfectly across countless devices.
Twitter (whoever they are now) released Bootstrap, a framework offering pre-built tools and design rules for flawless webpage viewing on any screen size. Initially, it was a lifesaver, standardizing web design. Interfaces became clean and minimal, and overnight, many an eyesore vanished. Finally, nights weren’t spent searching for “!important” under every tag.
But with each passing year and announcement, frameworks became the standard, the point of no return.
We began taking things for granted. Speed trumped understanding, and we increasingly relied on “magic boxes” that solved problems in an opaque way. Frameworks became easier to use but far more complex under the hood. Few bothered to peek inside, leading to a loss of valuable knowledge.
We started using them like a cannon to swat a fly: downloading megabytes of code for landing pages or forcing uniformity on tiny CRUD applications. While I don’t miss hand-coding htaccess for routing, I wish people remembered it – to grasp the mechanisms and, if needed, customize framework behavior without the dreaded “Angular doesn’t allow that.”
“Doesn’t allow” is a strong word. Most times, it allows it, but with a bloodbath. The complexity that frameworks introduce for simple tasks can take you to parallel dimensions where up is down. So, to avoid losing your mind, you just do what it says.
Of course, lugging around a massive code block hurts performance. Due to the complexity, few will truly understand what JavaScript is doing to your little piece of HTML. Pray, eat your liver, and hope for the best.
Given the npm module vulnerability mess of last year, I won’t dwell on security. You can’t guarantee complete safety; proper tools are a must. Frameworks often involve diverse skillsets and professionals like DevOps, making things even more complex for freelancers or solo developers.
Lastly, there’s independence. Frameworks constantly update, potentially causing incompatibilities or requiring significant code changes. Avoiding them means no dependence, allowing you to sleep soundly (well, almost) every time your server updates.
Frameworks offer a ton of benefits, enabling collaboration with best practices, maintaining standards, and avoiding development from scratch. If I had a euro for every curse word hurled at the phantom programmer who left me with untested, undocumented code (laced with colorful commentary about the previous coder), I’d be a millionaire. And I definitely wouldn’t have made the embarrassing mistake of telling a client “Whoever wrote this is an idiot” only to discover it was my own code from a year ago.
From Angular to Slim, let’s embrace the tools that help us solve our everyday problems. But beware of getting “trapped” in them. Remember, when you’re banging your head against a trivial issue solved in an abstruse way, imagine your framework dressed like Jessica Rabbit whispering in your ear, “I’m not bad, they just draw me like this…”
