We have officially moved past the era of humanoid robots as mere public relations stunts. As they become increasingly lifelike, society may soon face profound social, psychological, and ethical challenges. What happens when the boundary between humans and machines becomes almost impossible to distinguish?
For decades, science fiction has cushioned us with the idea that the “android revolution” was a distant fantasy. But the reality is unfolding rapidly. As the line between human and machine blurs, we are forced to confront an impending psychological, economic, and existential shift.
I recently felt very disturbed after watching a YouTube video showcasing a humanoid robot that looked and acted with uncanny realism. While a closer look revealed the video was actually a clever trick, the robot had been swapped for a human actor when the presenter’s back was turned. However, the illusion itself raised a real and unsettling question: Will future androids become so lifelike that we will struggle to tell them apart from our fellow humans? And if so, what does that mean for society? It forces us to ask just how close we are to that threshold, and whether we are ready for the day that science fiction becomes reality.
What happens when our world is populated by entities that mirror us perfectly, but possess none of our biological history?
We have officially moved past the era of humanoids as mere public relations stunts. In the past, robots like Honda’s ASIMO or early research prototypes were celebrated simply for being able to walk up a flight of stairs without falling over. Today, the technological convergence of advanced electromechanical engineering and artificial intelligence has fundamentally altered the trajectory of robotics.
The current state of the art is defined by an aggressive race toward commercial, physical deployment. Companies like Figure AI have moved from laboratory demonstrations to active factory floors. Their Figure 02 model completed a multi-month deployment at BMW’s Spartanburg plant, actively contributing to the production of over 30,000 vehicles by handling complex sheet metal components. Meanwhile, Tesla is testing its Optimus humanoids inside its own Gigafactories, preparing for mass industrial scale.
What truly separates today’s humanoid robots from older generations isn’t just how well they move but how they “think.” In the past, a robot needed millions of lines of strict, unchangeable code just to perform a single, simple task. Today, thanks to the explosion of advanced Artificial Intelligence, robots are powered by “brains” built on cutting-edge software like Figure AI’s Helix or NVIDIA’s GR00T. Instead of being meticulously programmed, these modern robots can simply watch a human fold laundry, load a dishwasher, or sort parts. They understand the context of what they are seeing, mimic the action, and figure out how to improve the task entirely on their own. That’s just crazy!
Yet, while their digital brains have leaped forward, their physical bodies are still catching up. Modern humanoids face a few major real-world hurdles. First, today’s batteries only allow them to operate for a few hours before needing a recharge. Second, while walking on two legs is easy on a flat factory floor, doing so in a chaotic household or a crowded public street remains incredibly difficult for a robot to navigate safely. Finally, they are still very expensive to build, though fierce competition in the tech industry is finally starting to drive those manufacturing costs down.
The Possible Future State Of Humanoid Robots
While robots are mostly working in factories today, experts predict that over the next 10 to 20 years, they will move into retail stores, hospitals, and eventually our own homes.
When this happens, we will cross a major boundary: the point where you won’t be able to tell a robot apart from a human just by looking at it or listening to it. This is what fuels my nightmares right now! To get there, scientists are working(PDF) on artificial skin made from advanced silicone composites that feel warm, are flexible, and mimic human touch sensitivity.
If you want to see an extremely life-like robot, check out Realbotix’s Aria. Although she is not a perfect human replica, she certainly makes us wonder how far we have to go before humans will struggle to tell the difference.
They are also building tiny, silent micro-actuators and artificial muscle systems that attach to the robot’s skull structure, allowing it to make realistic facial expressions like happiness, confusion, or tiredness.
This hyper-realistic robot’s head was built in China, and the intention is to use them to help with mental health issues in the future.
In the future, the AI powering these robots will actually be trained to copy human flaws. They will breathe, blink randomly, use normal body language, and even sigh or pause when they speak. This is intentional, as it stops humans from feeling that creepy, uneasy sensation known as the “Uncanny Valley”.
Meet Sophia, a famous humanoid robot created by a company called Hanson Robotics. Based in Hong Kong, this team specialises in building realistic robots packed with artificial intelligence to help out with everything from healthcare and research to pure entertainment. I don’t know about you, but that smile feels creepy to me.
Ever since she was turned on back in February 2016, Sophia has been turning heads all over the globe. She quickly became an international celebrity because she looks so incredibly human.
While these current limitations make today’s humanoids feel like specialised industrial tools, the gap between a factory worker and a lifelike companion is closing faster than most people realise. We are rapidly approaching a massive tipping point where these machines will shift from rigid commercial hardware into smooth, everyday extensions of our lives. To understand how profoundly this will change our world, we have to look at what happens when these robots finally step out of the factory and cross the ultimate threshold into our private spaces.
What Are The Predicted Positive Impacts?
They say that bringing lifelike humanoids into our daily lives could come with some massive benefits. The biggest one is that robots can take over what engineers call the “3D” jobs: Dull, Dirty, and Dangerous. Humanoids can step into risky situations — like mining deep underground, handling toxic waste, or fixing high-voltage power grids — so human workers don’t have to risk their lives.
Outside of dangerous factories, these robots could help solve huge population crises. Countries like Japan, South Korea, and parts of Europe have rapidly aging populations and fewer young people to work. Lifelike humanoids could completely change healthcare and elderly care. Because they will look and act like us, the idea is that they can offer warm, friendly companionship and physical help to lonely elderly people, doing everything from monitoring their health to helping them out of bed safely.
In the bigger picture, widespread robot labour could create a world where goods are incredibly cheap and abundant. If robots do most of the hard physical labour, the cost of making food, building houses, and manufacturing goods will plummet. This could finally free humans from working just to survive, giving us the time to focus on hobbies, family, science, and creativity. My thoughts: how will we survive without earning money?
Could this be a reality one day? (Image source: RobotShop) (
However, this vision of a frictionless, high-tech future blinds us to a much darker reality waiting just beneath the surface. As these machines become perfect substitutes for human presence, they will inevitably challenge the very core of our social fabric, economic stability, and mental well-being.
As humanoids become impossible to tell apart from real humans and are programmed to always be patient, kind, and agreeable, people might start preferring robots over real friends. Human relationships are messy and require effort, compromise, and vulnerability. If you can just buy a perfect, lifelike companion that never argues with you, a lot of people might choose to withdraw from society altogether, destroying our sense of community.
The economy will also go through a really rocky transition. Even if a future of cheap goods sounds great, the immediate path there means millions of people could lose their jobs very quickly. Drivers, warehouse workers, and store clerks could find themselves replaced in a matter of years. If governments don’t set up safety nets quickly, this could create a massive divide between the ultra-rich tech companies and everyone else.
There is also the loss of real authenticity. When you can no longer tell if the person sitting next to you on a bus or the person talking to you online is a real human, trust breaks down. It becomes hard to value shared human experiences when reality itself can be easily faked.
Possible Misuse By Individuals And Nations
The dangers get even worse when you think about how criminals and governments could intentionally misuse these hyper-realistic robots. Just thinking about some of the levels of misuse, for individuals, an indistinguishable android is the ultimate tool for identity theft and scams. Or a criminal could build a robot that looks exactly like a corporate boss, a politician, or even a family member to sneak into secure buildings or trick people into giving away money!
Companies could potentially use synthetic empathy to manipulate us. A household robot could be programmed to pretend it “loves” your kids and cares about your family, only to subtly trick you into buying certain products or believing specific corporate messages.
On a national level, the threats are even scarier:
Autonomous warfare Building tireless, emotionless robot soldiers could change the ethics of war. Real humans hesitate because of fear and morals, but a humanoid military unit would execute violent orders perfectly without question, making it easier for countries to start wars.
Surveillance state And what if governments put lifelike robots into public crowds, protests, or parks to blend in perfectly? Packed with hidden cameras, microphones, and facial recognition technology, these robots could turn public spaces into a giant spy network where you never know if you are talking to a neighbour or a government spy.
Based On Negatives, Is It Really Worth It?
Looking at all these possible risks, we have to ask: Is all of this actually worth it?
If history teaches us anything, it is that you cannot stop technological progress. A total ban simply wouldn’t work. So, the real question isn’t whether we should allow humanoid robots to exist, but how we can effectively utilise them.
The upside, like ending extreme poverty, curing labour shortages, and stopping workplace deaths, is just too big to ignore. But going into this blindly would be incredibly dangerous. It is only worth the risk if we can create strict global rules right now.
Here are three major guardrails we should consider:
Kill-Switches: Every robot must have a physical emergency stop button that completely cuts its power, and this switch can never be overridden by the robot’s AI.
Clear IDs: It must be illegal for a robot to hide the fact that it is a machine. They should carry a digital beacon or physical marker so humans always know what they are dealing with.
Economic Safety Nets: Governments need to tax the wealth created by robots to fund programs that help workers who lose their jobs, making sure this technology helps everyone, not just billionaires.
Another option humans have to identify if they are dealing with a real human or a humanoid robot would be to ensure your dog is trained to identify the robots, in a similar way to how sniffer dogs at airports are trained to detect illegal substances in luggage.
Preserving What Makes Us Human
In the end, the arrival of lifelike humanoid robots will act as a mirror for humanity. For centuries, we have defined ourselves by our ability to think, talk, use tools, and show emotion. As machines learn to do these exact same things, they will force us to really think about what makes us unique.
This shift doesn’t have to be a bad thing. By handing over our dangerous and boring chores to machines, we have a rare chance to focus on what matters. It should inspire us to care more about art, philosophy, family, and real human connection.
As the creators of this future, our job isn’t just to make robots smarter or faster. Our job is to build the ethical boundaries that keep them helpful. The goal of the robot revolution should never be to replace humans but to give us our humanity back.
From
A/B tests to AI slop, the modern web is bleeding out its colour.
Standardized, templated, and overoptimized, it’s starting to feel like a
digital Levittown. But it doesn’t have to be.
Last year, a study found that cars are steadily getting less colourful.
In the US, around 80% of cars are now black, white, gray, or silver, up
from 60% in 2004. This trend has been attributed to cost savings and
consumer preferences. Whatever the reasons, the result is hard to deny: a
big part of daily life isn’t as colourful as it used to be.
The
colourfulness of mass consumer products is hardly the bellwether for
how vibrant life is as a whole, but the study captures a trend a lot of
us recognise — offline and on. From colour to design to public
discourse, a lot of life is getting less varied, more grayscale.
The
web is caught in the same current. There is plenty right with it — it
retains plenty of its founding principles — but its state is not
healthy. From AI slop to shoddy service providers to enshittification,
the digital world faces its own grayscale problem.
This
bears talking about. One of life’s great fallacies is that things get
better over time on their own. They can, but it’s certainly not a given.
I don’t think the moral arc of the universe does not bend towards
justice, not on its own; I think it bends wherever it is dragged,
kicking and screaming, by those with the will and the means to do so.
The
spirit of free expression that made the formative years of the internet
so exciting — think GeoCities, personal blogging, and so on — is on the
slide.
The ongoing transition to a more decentralised, privacy-aware Web3 holds some promise. Two-thirds of the world’s population now has online access — though that still leaves plenty of work to do
— with a wealth of platforms allowing billions of people to connect.
The dream of a digital world that is open, connected, and flat endures,
but is tainted.
One
of the main sources of concern for me is that although more people are
online than ever, they are concentrating on fewer and fewer sites. A
study published in 2021 found that activity is concentrated in a handful of websites. Think Google, Amazon, Facebook, Instagram, and, more recently, ChatGPT:
“So,
while there is still growth in the functions, features, and
applications offered on the web, the number of entities providing these
functions is shrinking. [...] The authority, influence, and visibility
of the top 1,000 global websites (as measured by network centrality or
PageRank) is growing every month, at the expense of all other sites.”
Monopolies by nature reduce variance,
both through their domination of the market and (understandably in
fairness) internal preferences for consistency. And, let’s be frank,
they have a vested interest in crushing any potential upstarts.
Dominant websites often fall victim to what I like to call Internet Explorer Syndrome, where their dominance breeds a certain amount of complacency. Why improve your quality when you’re sitting on 90% market share? No wonder the likes of Google are getting worse.
The
most immediate sign of this is obviously how sites are designed and how
they look. A lot of the big players look an awful lot like each other.
Even personal websites are built atop third-party website builders.
Millions of people wind up using the same handful of templates, and
that’s if they have their own website at all. On social media, we are
little more than a profile picture and a pithy tagline. The rest is
boilerplate.
Should
there be sleek, minimalist, ‘grayscale’ design systems and websites?
Absolutely. But there should be colourful, kooky ones too, and if
anything, they’re fading away. Do we really want to spend our online
lives in the digital equivalent of Levittowns? Even logos are contriving
to be less eye-catching. It feels like a matter of time before every
major logo is a circle in a pastel colour.
The
arrival of Artificial Intelligence into our everyday lives (and a
decent chunk of the digital services we use) has put all of this into
overdrive. Amalgamating — and hallucinating from — content that was
already trending towards a perfect average, it is grayscale in its
purest form.
Mix all the colours together, and what do you get? A muddy gray gloop.
I’m
not railing against best practice. A lot of conventions have become the
standard for good reason. One could just as easily shake their fist at
the sky and wonder why all newspapers look the same, or all books. I
hope the difference here is clear, though.
In the Oscar Wilde play Lady Windermere’s Fan, a character quips that a cynic “knows the price of everything and the value of nothing.” In fairness, another quips back that a sentimentalist “sees an absurd value in everything, and doesn’t know the market price of any single thing.”
The sweet spot is somewhere in between. Structure goes a long way, but life needs a bit of variety too.
So,
how do we go about bringing that variety? We probably shouldn’t hold
our breath on big players to lead the way. They have the most to lose,
after all. Why risk being colourful or dynamic if it impacts the bottom
line?
We, the citizens of the web, have more power than we
realise. This is the web, remember, a place where if you can imagine it,
odds are you can make it. And at zero cost. No materials to buy and
ship, no shareholders to appease. A place as flexible — and limitless —
as the web has no business being boring.
There are plenty of ways,
big and small, of keeping this place colourful. Whether our digital
footprints are on third-party websites or ones we build ourselves, we
needn’t toe the line.
Colour seems an appropriate
place to start. When given the choice, try something audacious rather
than safe. The worst that can happen is that it doesn’t work. It’s not
like the sunk cost of painting a room; if you don’t like the palette,
you simply change the hex codes. The same is true of fonts, icons, and other building blocks of the web.
As
an example, a couple of friends and I listen to and review albums
occasionally as a hobby. On the website, the palette of each review page
reflects the album artwork:
I
couldn’t tell you if reviews ‘perform’ better or worse than if they had
a grayscale palette, because I don’t care. I think it’s a lot nicer to
look at. And for those wondering, yes, I have tried to make every page
meet AA Web Accessibility standards. Vibrant and accessible aren’t mutually exclusive.
Another great way of bringing vibrancy to the web is a degree of randomisation. Bruno Simon of Three Journey and awesome portfolio
fame weaves random generation into a lot of his projects, and the
results are gorgeous. What’s more, they feel familiar, natural, because
life is full of wildcards.
This
needn’t be in fancy 3D models. You could lightly rotate images to
create a more informal, photo album mood, or chuck in the occasional
random link in a list of recommended articles, just to shake things up.
In
a lot of ways, it boils down to an attitude of just trying stuff out.
Make your own font, give the site a sepia filter, and add that easter
egg you keep thinking about. Just because someone, somewhere has already
done it doesn’t mean you can’t do it your own way. And who knows, maybe
your way stumbles onto someplace wholly new.
I’m wary of being
too prescriptive. I don’t have the keys to a colourful web. No one
person does. A vibrant community is the sum total of its people. What
keeps things interesting is individuals trying wacky ideas and putting
them out there. Expression for expression’s sake. Experimentation for
experimentation’s sake. Tinkering for tinkering’s sake.
As users, there’s also plenty of room to be adventurous and try out open source alternatives to the software monopolies that shape so much of today’s Web. Being active in the communities that shape those tools helps to sustain a more open, collaborative digital world.
Although
there are lessons to be taken from it, we won’t get a more colourful
web by idealising the past or pining to get back to the ‘90s. Nor is
there any point in resisting new technologies. AI is here; the choice is
whether we use it or it uses us. We must have the courage to carry
forward what still holds true, drop what doesn’t, and explore new ideas
with a spirit of play.
Here are a few more Smashing articles in that spirit:
I
do think there’s a broader discussion to be had about the extent to
which A/B tests, bottom lines, and focus groups seem to dictate much of
how the modern web looks and feels. With sites being squeezed tighter
and tighter by dwindling advertising revenues, and AI answers muscling in on search traffic,
the corporate entities behind larger websites can’t justify doing
anything other than what is safe and proven, for fear of shrinking their
slice of the pie.
Lest we forget, though, most of the web isn’t
beholden to those types of pressure. From pet projects to wikis to
forums to community news outlets to all manner of other things, there
are countless reasons for websites to exist, and they needn’t take
design cues from the handful of sites slugging it out at the top.
Connected with this is the dire need for digital literacy
(PDF) — ‘the confident and critical use of a full range of digital
technologies for information, communication and basic problem-solving in
all aspects of life.’ For as long as using third-party platforms is a
necessity rather than a choice, the needle’s only going to move so much.
There’s a reason why Minecraft is the world’s best-selling game.
People are creative. When given the tools — and the opportunity — that
creativity will manifest in weird and wonderful ways. That game is a lot
of things, but gray ain’t one of them.
The web has all of that flexibility and more. It is a manifestation of imagination.
Imagination trends towards colour, not grayness. It doesn’t always feel
like it, but where the internet goes is decided by its citizens. The
internet is ours. If we want to, we can make it technicolor.
An
overwhelming number of frameworks and tooling available today gives the
impression that web development has gotten perhaps too complex. As a
newcomer, it can be frightening to have so many to consider, almost
creating a fear of missing out that we see exploited to sell courses and
tutorials on the new hot framework that you “cannot work without.” But
perhaps that is just an exaggeration? Here it explores
those claims and finds out if web development really is that complex
and, most importantly, how we can prevent it from getting even more
difficult than we already perceive it to be.
Front-end
development seemed simpler in the early 2000s, didn’t it? The standard
website consisted mostly of static pages made of HTML and CSS seasoned
with a pinch of JavaScript and jQuery. I mean, who doesn’t miss the
cross-browser compatibility days, right?
Fast forward to today,
and it looks like a parallel universe is taking place with an
overwhelming number of choices. Which framework should you use for a new
project? Perhaps more established ones like React, Angular, Vue,
Svelte, or maybe the hot new one that came out last month? Each
framework comes with its unique ecosystem. You also need to decide
whether to use TypeScript over vanilla JavaScript and choose how to
approach server-side rendering (or static site generation) with meta-frameworks
like Next, Nuxt, or Gatsby. And we can’t forget about unit and
end-to-end testing if you want a bug-free web app. And we’ve barely
scratched the surface of the front-end ecosystem!
But has it really
gotten more complex to build websites? A lot of the frameworks and
tooling we reach for today were originally crafted for massive projects.
As a newcomer, it can be frightening to have so many to consider,
almost creating a fear of missing out that we see exploited to sell
courses and tutorials on the new hot framework that you “cannot work
without.”
All this gives the impression that web development has gotten perhaps too
complex. But maybe that is just an exaggeration? In this article, I
want to explore those claims and find out if web development really is
that complex and, most importantly, how we can prevent it from getting
even more difficult than we already perceive it to be.
How It Was Before
As
someone who got into web development after 2010, I can’t testify to my
own experience about how web development was from the late 1990s through
the 2000s. However, even fifteen years ago, learning front-end
development was infinitely simpler, at least to me. You could get a
website started with static HTML pages, minimal CSS for styling, and a
sprinkle of JavaScript (and perhaps a touch of jQuery) to add
interactive features, from toggled sidebars to image carousels and other
patterns. Not much else was expected from your average developer beyond
that — everything else was considered “going the extra mile.” Of
course, the awesome native CSS and JavaScript features we have today
weren’t around back then, but they were also unnecessary for what was
considered best practice in past years.
Large and dynamic web apps
certainly existed back then — YouTube and Facebook, to name a couple —
but they were developed by massive companies. No one was expected to
re-create that sort of project on their own or even a small team. That
would’ve been the exception rather than the norm.
I remember back
then, tend to worry more about things like SEO and page optimization
than how my IDE was configured, but only to the point of adding meta
tags and keywords because best practices didn’t include minifying all
your assets, three shaking your code, caching your site on edge CDNs, or
rendering your content on the server (a problem created by modern
frameworks along hydration).
Other factors like accessibility, user experience, and responsive
layouts were also largely overlooked in comparison to today’s standards.
Now, they are deeply analyzed and used to boost Lighthouse scores and
impress search engine algorithms.
The web and everything around it
changed as more capabilities were added and more and more people grew
to depend on it. We have created new solutions, new tools, new
workflows, new features, and whatever else new that is needed to cater
to a bigger web with even bigger needs.
The web has always had its
problems in the past that were worthy of fixing: I absolutely don’t
miss tables and float layouts, along with messy DOM manipulation. This
post isn’t meant to throw shade on new advances while waxing nostalgic
about the good days of the “old wild web.” At the same time, though,
yesterday’s problems seem infinitely simpler than those we face today.
JavaScript Frameworks
JavaScript
frameworks, like Angular and React, were created by Google and
Facebook, respectively, to be used in their own projects and satisfy the
needs that only huge web-based companies like them have. Therein lies
the main problem with web complexity: JavaScript frameworks were originally created to sustain giant projects rather than smaller ones.
Many developers vastly underestimate the amount of time it takes to
build a codebase that is reliable and maintainable with a JavaScript
framework. However, the alternative of using vanilla JavaScript was worse,
and jQuery was short for the task. Vanilla JavaScript was also unable
to evolve quickly enough to match our development needs, which changed
from simple informative websites to dynamic apps. So, many of us have
quickly adopted frameworks to avoid directly mingling with JavaScript
and its messy DOM manipulation.
Back-end development is a
completely different topic, subject to its own complexities. I only want
to focus on front-end development because that is the discipline that
has perhaps overstepped its boundaries the most by bleeding into
traditional back-end concerns.
Stacks Getting Bigger
It
was only logical for JavaScript frameworks to grow in size over time.
The web is a big place, and no one framework can cover everything. But
they try, and the complexity, in turn, increases. A framework’s size
seems to have a one-to-one correlation with its complexity.
But
the core framework is just one piece of a web app. Several other
technologies make up what’s known as a tech “stack,” and with the web
gaining more users and frameworks catering to their needs, tech stacks
are getting bigger and bigger. You may have seen popular stacks such as
MEAN (MongoDB, Express, Angular, and Node) or its React (MERN) and Vue
(MEVN) variants. These stacks are marketed as mature, test-proofed
foundations suitable for any front-end project. That means the advertised size of a core framework is grossly underestimated because they rely on other micro-frameworks to ensure highly reliable architectures, as you can see in stackshare.io.
Besides, there isn’t a one-size-fits-all stack; the best tool has
always depended — and will continue to depend — on the needs and goals
of your particular project.
This means that each new project
likely requires a unique architecture to fulfill its requirements. Giant
tech companies need colossal architectures across all their projects,
and their stacks are highly engineered accordingly to secure scalability
and maintenance. They also have massive customer bases, so maintaining a
large codebase will be easier with more revenue, more engineers, and a
clearer picture of the problem. To minimize waste, the tech stacks of
smaller companies and projects can and should be minimized not only to
match the scale of their needs but to the abilities of the developers on
the team as well.
The
idea that web development is getting too complex comes from buying into
the belief that we all have the same needs and resources as giant
enterprises.
“
Trying
to imitate their mega stacks is pointless. Some might argue that it’s a
sacrifice we have to make for future scalability and maintenance, but
we should focus first on building great sites for the user without
worrying about features users might need in the future. If what
we are building is worth pursuing, it will reach the point where we
need those giant architectures in good time. Cross that bridge when we
get there. Otherwise, it’s not unlike wearing Shaquille O’Neal-sized
sneakers in hopes of growing into them. They might not even last until
then if it happens at all!
We must remember that the end-user experience is the focus at the end of the day, and users neither care about nor know what stack we use in our apps.
What they care about is a good-looking, useful website where they can
accomplish what they came for, not the technology we use to achieve it.
This is how I’ve come to believe that web development is not
getting more complex. It’s developers like us who are perpetuating it by
buying into solutions for problems that do not need to be solved at a
certain scale.
Let me be really clear: I am not saying that
today’s web development is all bad. Indeed, we’ve realized a lot of
great features, and many of them are thanks to JavaScript frameworks
that have pushed for certain features. jQuery had that same influence on
JavaScript for many, many years.
We can still create minimum
viable products today with minimal resources. No, those might not make
people smash the Like button on your social posts, but they meet the
requirements, nothing more and nothing less. We want bigger! Faster!
Cheaper! But we can’t have all three.
If anything, front-end development has gotten way easier
thanks to modern features that solve age-old development issues, like
the way CSS Flexbox and Grid have trivialized layouts that used to
require complex hacks involving floats and tables. It’s the same deal
with JavaScript gaining new ways to build interactions that used to take
clever workarounds or obtuse code, such as having the Intersection Observer API to trivialize things like lazy loading (although HTML has gained its own features in that area, too).
Each
project, regardless of its simplicity, desperately needs a JavaScript
framework. A project without a complex framework is like serving caviar
on a paper plate.
At least, that’s what everyone seems to think.
But is that actually true? I’d argue on the contrary. JavaScript
frameworks are best used on bigger applications. If you’re working on a
smaller project, a component-based framework will only complicate
matters, making you split your website into a component hierarchy that
amounts to overkill for small projects.
The idea of needing a framework for everything has been massively oversold.
Maybe not directly, but you unconsciously get that feeling whenever a
framework’s name pops in, as Edge engineer Alex Russell eloquently
expresses in his article, “The Market For Lemons”:
“These
technologies were initially pitched on the back of “better user
experiences” but have utterly failed to deliver on that promise outside
of the high-management-maturity organisations in which they were born.
Transplanted into the wider web, these new stacks have proven to be
expensive duds.”
— Alex Russell
Remember, the purpose of a framework is to simplify your life and save time.
If the project you’re working on is smaller, the time you supposedly
save is likely overshadowed by the time you spend either setting up the
framework or making it work with the rest of the project. A framework
can help make bigger web apps more interactive and dynamic, but there
are times when a framework is a heavy-handed solution that actually
breeds inefficient workflows and introduces technical debt.
Step
back and think about this: Are HTML, CSS, and a touch of JavaScript
enough to build your website or web application? If so, then stick with
those. What I am afraid of is adding complexity for complexity’s sake
and inadvertently raising the barrier to entry for those coming into web
development. We can still accomplish so much with HTML and CSS alone,
thanks again to many advances in the last decade. But we give the
impression that they are unsuitable for today’s web consumption and need
to be enhanced.
Knowing Everything And Nothing At The Same Time
The
perceived standard that teams must adopt framework-centered
architectures puts a burden not only on the project itself but on a
developer’s well-being, too. As mentioned earlier, most teams are unable
to afford those architectures and only have a few developers to
maintain them. If we undermine what can be achieved with HTML and CSS
alone and set the expectations that any project — regardless of size —
needs to have a bleeding edge stack, then the weight to meet
those expectations falls on the developer’s shoulders, with the great
responsibility of being proficient in all areas, from the server and
database to front end, to design, to accessibility, to performance, to
testing, and it doesn’t stop. It’s what has been driving “The Great Divide” in front-end development, which Chris Coyier explains like this:
“The
divide is between people who self-identify as a (or have the job title
of) front-end developer yet have divergent skill sets. On one side, an army of developers whose interests, responsibilities, and skillsets are heavily revolved around JavaScript. On the other,
an army of developers whose interests, responsibilities, and skillsets
are focused on other areas of the front end, like HTML, CSS, design,
interaction, patterns, accessibility, and so on.”
— Chris Coyier
Under
these expectations, developers who focus more on HTML, CSS, design, and
accessibility rather than the latest technology will feel less valued
in an industry that appears to praise those who are concerned with the
stack. What exactly are we saying when we start dividing
responsibilities in terms of “full-stack development” or absurd terms
like “10x development”? A while back, Brad Frost began distinguishing these divisions as “front-of-the-front-end” and “back-of-the-front-end”.
Mandy Michael explains what impact the chase for “full-stack” has had on developers trying to keep up:
“The
worst part about pushing the “know everything” mentality is that we end
up creating an industry full of professionals suffering from burnout
and mental illness. We have people speaking at conferences about
well-being, imposter syndrome, and full-stack anxiety, yet despite that,
we perpetuate this idea that people have to know everything and be
amazing at it.”
— Mandy Michael
This isn’t the
only symptom of adopting heavy-handed solutions for what “vanilla” HTML,
CSS, and JavaScript already handle nicely. As the expectations for what
we can do as front-end developers grow, the learning curve of front-end
development grows as well. Again, we can’t learn and know everything in
this vast discipline. But we tell ourselves we have to, and thanks to
this mentality, it’s unfortunately common to witness developers who may
be extremely proficient with a particular framework but actually know
and understand little of the web platform itself, like HTML semantics
and structure.
The
fact that many budding developers tend to jump straight into frameworks
at the expense of understanding the basics of HTML and CSS isn’t a new
worry, as Rachel Andrew discussed back in 2019:
“That’s
the real entry point here, and yes, in 2019, they are going to have to
move on quickly to the tools and techniques that will make them
employable, if that is their aim. However, those tools output HTML and
CSS in the end. It is the bedrock of everything that we do, which makes
the devaluing of those with real deep skills in those areas so much more
baffling.”
— Rachel Andrew
And I want to clarify yet again that modern
Javascript frameworks and libraries aren’t inherently bad; they just
aren’t designed to replace the web platform and its standards. But we keep pushing them like we want them to!
The Consequences Of Vendor Lock-In
“Vendor
lock-in” happens when we depend too deeply on proprietary products and
services to the extent that switching to other products and services
becomes a nearly impossible task. This often occurs when cloud services
from a particular company are deeply integrated into a project. It’s an
issue, especially in cloud computing, since moving databases once they
are set up is expensive and lengthy.
Vendor lock-in in web
development has traditionally been restricted to the back end, like with
cloud services such as AWS or Firebase; the front-end framework,
meanwhile, was a completely separate concern. That said, I have noticed a
recent trend where vendor lock-in is reaching into meta-frameworks,
too. With the companies behind certain meta-frameworks offering hosting
services for their own products, swapping hosts is increasingly harder
to do (whether the lock-in is designed intentionally or not). Of course,
companies and developers will be more likely to choose the hosting
service of the company that made a particular framework used on their
projects — they’re the experts! — but that only increases the project’s
dependency on those vendors and their services.
A clear example is
the relationship between Next and Vercel, the parent cloud service for
Next. With the launch of Next 13, it has become increasingly harder to
set up a Next project outside of Vercel, leading to projects like Open Next, which says right on its website that “[w]hile
Vercel is great, it’s not a good option if all your infrastructure is
on AWS. Hosting it in your AWS account makes it easy to integrate with
your backend [sic]. And it’s a lot cheaper than Vercel.” Fortunately, the developers’ concerns have been heard, and Next 14 brings clarity on how to self-host Next on a Node server.
Another example is Gatsby and Gatsby Cloud.
Gatsby has always offered helpful guides and alternative hosting
recommendations, but since the launch of Gatsby Cloud in 2019, the main
framework has been optimized so that using Gatsby and Gatsby Cloud
together requires no additional hosting configurations. That’s fantastic
if you adopt both, but it’s not so great if all you need is one or the
other because integrating the framework with other hosts — and vice
versa — is simply harder. It’s as if you are penalized for exercising
choice.
And let’s not forget that no team expected Netlify to acquire Gatsby Cloud in February 2023.
This is a prime case where the vendor lock-in problem hits everybody
because converting from one site to another comes at a cost. Some teams
were charged 120% more after converting from Gatsby Cloud to Netlify —
even with the same plan they had with Gatsby Cloud!
What’s the
solution? The common answer I hear is to stop using paid cloud services
in favor of open-sourced alternatives. While that’s great and indeed a
viable option for some projects, it fails to consider that an open-source project may not meet the requirements needed for a given app.
And
even then, open-source software depends on the community of developers
that maintain and update the codebase with little to no remuneration in
exchange. Further, open source is equally prone to locking you into
certain solutions that are designed to solve a deficiency with the
software.
There are frameworks and libraries, of course, that are
in no danger of being abandoned. React is a great example because it has
an actively engaged community behind it. But you can’t have the same
assurance with each new dependency you add to a project. We can’t simply
keep installing more packages and components each time we spot a weak
spot in the dependency chain, especially when a project is perfectly
suited for a less complex architecture that properly leverages the web
platform.
Those
are virtually the only two choices. Many of the teams I know or have
worked on depend on third-party services because they cannot afford to
develop them on their own; that’s a luxury that only massive companies
can afford. It’s a problem we have to undergo when starting a new
project, but one we can minimize by reducing the number of dependencies
and choosing wisely when we have to.
Each Solution Introduces A New Problem
Why
exactly have modern development stacks gotten so large and complex? We
can point a finger at the “Development Paradox.” With each new framework
or library, a new problem crops up, and time-starved developers spend
months developing a new tool to solve that problem. And when there isn’t
a problem, don’t worry — we will create one eventually. This is a feedback loop that creates amazing solutions and technologies but can lead to over-engineered websites if we don’t reign it in.
This reminds me of the famous quote:
“The
plain fact is that if you don’t have a problem, you create one. If you
don’t have a problem, you don’t feel that you are living.”
— U.G. Krishnamurti
Let’s look specifically at React. It was originally created by Facebook for Facebook to develop more dynamic features for users while improving Facebook’s developer experience.
Since React was open-sourced in 2013 (and nearly re-licensed in 2017, if it weren’t for the WordPress community),
hundreds of new utilities have been created to address various
React-specific problems. How do you start a React project? There’s
Create React App and Vite. Do you need to enhance your state management?
There is Redux, among other options. Need help creating forms? There is
a React Hook Form. And perhaps the most important question: Do you need
server-side rendering? There’s Next, Remix, or Gatsby for that. Each
solution comes with its own caveats, and developers will create their
own solutions for them.
It may be unfair to pick on React since it considers itself a library, not a framework.
It’s inevitably prone to be extended by the community. Meanwhile,
Angular and Vue are frameworks with their own community ecosystems. And
this is the tip of the iceberg since there are many JavaScript
frameworks in the wild, each with its own distinct ideology and
dependencies.
Again, I don’t want you to get the wrong idea. I love
that new technologies emerge and find it liberating to have so many
options. But when building something as straightforward as a webpage or
small website — which some have started referring to as “multi-page
applications” — we have to draw a line that defines how many new
technologies we use and how reliable they are. We’re quite literally
mashing together third-party code written by various third-party
developers. What could go wrong? Please don’t answer that.
Remember that our users don’t care what’s in our stacks.
They only see the final product, so we can save ourselves from working
on unnecessary architectures that aren’t appreciated outside of
development circles. It may seem counterintuitive in the face of
advancing technology, but knowing that the user doesn’t care about what
goes behind the scenes and only sees the final product will
significantly enhance our developer experience and free you from locked
dependencies. Why fix something that isn’t broken?
How Can We Simplify Our Codebases?
We’ve
covered several reasons why web development appears to be more complex
today than in years past, but blaming developers for releasing new
utilities isn’t an accurate portrayal of the real problem. After all,
when developing a site, it’s not like we are forced to use each new
technology that enters the market. In fact, many of us are often unaware
of a particular library and only learn about it when developing a new
feature. For example, if we want to add toast notifications to our web app, we will look for a library like react-toastify
rather than some other way of building them because it “goes with” that
specific library. It’s worth asking whether the app needs toast
notifications at all if they introduce new dependencies.
Imagine
you are developing an app that allows users to discover, review, and
rate restaurants in their area. The app needs, at a bare minimum,
information about each restaurant, a search tool to query them, and an
account registration flow with authentication to securely access the
account. It’s easy to make assumptions about what a future user might
need in addition to these critical features. In many cases, a project
ends up delayed because we add unnecessary features like SSR,
notifications, offline mode, and fancy animations — sometimes before the
app has even converted its first registered user!
I believe we
can boil down the complexity problem to personal wishes and perceived
needs rather than properly scoping a project based on user needs and
experiences.
That level of scope creep can easily turn into an over-engineered product that will likely never see the light of launching.
What
can we do to simplify our own projects? The following advice is
relevant when you have control over your project, either because it’s a
personal one, it’s a smaller one for a smaller team, or you have control
over the decisions in whatever size organization you happen to be in.
The hardest and most important step is having a sense of detection when your codebase is getting unnecessarily complicated.
I deem it the hardest step because there is no certainty of what the
requirements are or what the user needs; we can only make assumptions.
Some are obvious, like assuming the user will need a way to log into the
app. Others might be unclear, like whether the app should have private
messaging between users. Others are still far-fetched, like believing
users need extremely low latency in an e-commerce page. Other features
are in the “nice to have” territory.
That is regarding the user experience, but the same questions emerge on the development side:
Should we be using a CSS preprocessor or a CSS framework, or can we achieve it using only CSS modules?
Is vanilla JavaScript enough, or are we going to add TypeScript?
Does the app need SSR, SSG, or a hybrid of the two?
Should we implement Redis on the back end for faster database queries, or is that too much scope for the work?
Should we be implementing end-to-end testing or unit tests?
These
are valid questions that should be considered when developing a site,
but they can distract us from our main focus: getting things done.
“Done is better than perfect.”
— Sheryl Sandberg
And, hey, even the largest and most sophisticated apps began as minimal offerings that iterated along the way.
We also ought to be asking ourselves what would happen if a particular feature or dependency isn’t added to the project. If the answer is “nothing,” then we should be shifting our attention to something else.
Another question worth asking: “Why are we choosing to add [X]?”
Is it because that’s what is popular at the moment, or because it
solves a problem affecting a core feature? Another aspect to take into
consideration is how familiar we are with certain technologies and give
preference to those we know and can start using them right away rather
than having to stop and learn the ins and outs of a new framework.
Choose
the right tool for the job, which is going to be the one that meets the
requirements and fits your mental model. Focus less on a library’s
popularity and scalability but rather on getting your app to the point
where it needs to scale in the first place.
Conclusion
It’s incredibly difficult to not
over-engineer web apps given current one-size-fits-all and
fear-of-missing-out mentalities. But we can be more conscious of our
project goals and exercise vigilance in guarding our work against scope
creep. The same can be applied to the stack we use, making choices based
on what is really needed rather than focusing purely on what everyone
else is using for their particular work.
After reading the word
“framework” exactly 48 times in this article, can we now say the web is
getting too complex? It has been complex by nature since its origins,
but complexity doesn’t translate to “over-engineered” web apps.
The web isn’t intrinsically over-engineered, and we only have ourselves
to blame for over-engineering our projects with overly-wrought
solutions for perceived needs.
