The web was not designed using React, Vue, Angular or any other modern JavaScript framework in the back of your mind. It was created for documents, linked together, continually enhanced and available by default. Yet, the web of today is heavily influenced by build tools, frameworks and abstraction layers that are built on top of each other.
How did we arrive here? What does this mean for the way we create the web of in the present?
This isn’t so much an issue and more of an observation from someone who creates for the web of today but still respects the source of their work.
At its heart, the web was built upon three technologies:
HTML to create structure
CSS to present
JavaScript that allows for behaviour
HTML documents loaded very quickly and worked on nearly every device, and was degraded easily. If JavaScript was not working, the webpage was still functional. Accessibility was not a checklist, it was built into.
You can view the source to understand the page and alter it without any tools. The entry barrier was minimal while the feedback loop was instantaneous.
It wasn’t perfect, but it was a strong and durable product.
As web-based applications became more complicated and more complex, the limitations of plain JavaScript became apparent. The management of states, DOM updates, and interactions with users at a large huge scale was hard and often messy.
Frameworks have been developed to solve the real issues:
Component-based architecture
State management
Reusable UI patterns for UI
Predictable rendering
They helped make larger teams more productive and made complex interfaces more manageable. In the end it felt like the price was worth it.
Frameworks didn’t only enhance the web, they started to replace the web’s mental model at its foundation.
The modern web development process typically includes:
Transpilers and bundlers
Client-side routing
Rehydration and hydration
Dozens of dependencies
In most instances, you’re not sending an actual document, but rather the JavaScript runtime which generates documents after.
It has implications:
Slower initial load times
Cognitive overhead is increased
Pipelines that are fragile to build
The accessibility of information as an added benefit
Performance dependent on device power
The irony? We have worked in order to “improve” the internet that we sometimes fight the web itself.
Frameworks abstract complexity but they also conceal the fundamentals.
New developers might discover:
Hooks prior to events
Virtual DOM prior to actual DOM
Framework conventions preceding web standards
When abstractions leak — and they do, debugging becomes more difficult. It’s no longer about solving web problems, but instead framework-related problems.
Frameworks don’t necessarily mean they aren’t bad. They are powerful tools and power tools require understanding, not blind trust.
It is interesting to note that the industry is undergoing a correction.
There is a renewed emphasis on:
Web standards and APIs for browsers
Edge computing and server-side rendering
Progressive enhancement
Performance-first development
Modern meta-frameworks like modern meta-frameworks, islands architecture and server components accept an undisputed fact: The browser itself is extremely efficient at what it does.
Frameworks are getting thinner. The platform is getting stronger.
It’s a positive change.
I have frameworks, but I don’t believe in them.
I begin by asking:
Could this be solved using semantic HTML?
Does this really requires JavaScript?
What happens If scripts fail?
How fast can this load on a device with a lower-end model?
Frameworks are a way to achieve a goal and not a destination. The purpose is:
Performance
Accessibility
Maintainability
User experience
Sometimes, the most effective solution is an application framework. Sometimes, it’s the web that is used correctly.
The web wasn’t designed for frameworks, but they’re not going away. That’s fine.
The future is in the hands developers who:
Know the web’s fundamentals
Use tools in a thoughtful manner
Be aware of the restrictions
Build for the user not for the latest trends
Web development success isn’t just about the state of your technology. It’s about how your work can be used by real people using real devices on the ground.
In some cases the most innovative option is to keep track of the point at which the web began.
