By Tim Vermaelen, 19-12-2024
With over 20 years of experience in web development, I have witnessed the evolution of the industry firsthand. I remember resolving cross-browser issues with Internet Explorer (IE) 5.5, IE6, IE7, Opera, and Safari, and eagerly awaiting the day when these problems would become a thing of the past. I vividly recall the era where CSS hacks were a necessary evil—a labyrinth of browser-specific workarounds that often left our codebases tangled and our sanity tested. These hacks were as unpredictable as the browsers themselves, and with every major version release, our carefully crafted code quickly became outdated.
In 1995, Brendan Eich created JavaScript while working at Netscape, marking a significant milestone in web development. Around 2006, the era of JavaScript libraries began, promising salvation from the chaos of cross-browser compatibility. Libraries like Prototype (first released in 2005 by Sam Stephenson), jQuery (created by John Resig in 2006), and later Underscore (released by Jeremy Ashkenas in 2009) swooped in, offering a standardized approach to DOM manipulation and event handling, liberating developers from the shackles of browser quirks. It seemed like a golden age of unprecedented progress and innovation.
The era of mobile optimization ushered in significant advancements. HTML5 (introduced in 2008 and standardized in 2014) and CSS3 (first released in 1999 and widely supported by 2012) became the new web development standards. According to StatCounter, mobile web usage surpassed desktop usage for the first time in October 2016, with 51.3% of web pages accessed via mobile devices. This shift underscored the importance of mobile optimization. Responsive web design (proposed by Ethan Marcotte in 2010) introduced concepts like fluid, liquid, and adaptive design, alongside the now-ubiquitous "mobile-first" approach. Techniques such as media queries, flexible grid layouts, and responsive images became essential for ensuring websites functioned well on a variety of devices. However, explaining these new concepts to clients accustomed to traditional desktop-centric designs was a challenge.
At this point, everything made sense. We had our MVC backend and our SoC frontend. However, in the quest to support a growing range of browsers, developers began creating their own frontend frameworks. While these frameworks aimed to simplify development, they often introduced new layers of complexity. Let’s explore why this is the case.
Some frameworks and libraries, such as Knockout and certain uses of AngularJS, utilize HTML data attributes to store and manipulate data. These data attributes are often utilized for bindings, state management, and event handling. However, introducing logic into these data attributes presents significant concerns. The development community was on the verge of mastering Separation of Concerns (SoC) when frameworks started promoting two-way data binding as a necessity. This approach can blur the clear boundaries between different layers of an application, making the code harder to maintain and debug. Instead of enhancing simplicity and maintainability, the use of data attributes for logic often complicates the architecture and undermines the principles of SoC. Isn't this a step backward, complicating the clean architecture we had just achieved?
With each framework update came breaking changes, forcing developers to constantly refactor their codebases to stay up-to-date. The simplicity we craved was replaced with a dependency on external libraries, and the freedom to innovate was overshadowed by the constraints of framework conventions.
Consider the common Separation of Concerns (Soc) approach is a vertical structure. You have your HTML, CSS and JavaScript in separate folders. Easy to search and find!
In a Single Page Application (SPA) framework, SoC is introduced horizontally. You have your web components each in a folder, where HTML, CSS and JavaScript is tangled together. Also easy to search and find! But we were not developing Single Page Applications. Hold on to this thought as this comes back as an important point.
Frameworks, while powerful, often clash with the intricacies of Content Management Systems (CMS) integration. Platforms like Sitecore, Kentico, and Umbraco have their own ecosystems, finely tuned to work with vanilla web technologies. Introducing a framework into this ecosystem can disrupt the delicate balance, leading to compatibility issues and rendering discrepancies.
Imagine you spend tons of effort and budget on the coolest latest functionality with the latest technology. Fast forward 2-4 years and all of a sudden, your so called “coolest thing” has been surpassed by its competitors. Maintenance becomes a burden. Hiring resources with the right knowledge will be challenging. You have lost the long-term benefit of a code-base. Something we used to take pride over.
For smaller teams like ours, the overhead of a framework often outweighs its benefits. With only a handful of developers, communication is direct, and guidelines are informally enforced. Adding a framework introduces unnecessary complexity, hindering rather than aiding our development process.
When working with various JavaScript frameworks, developers often face a recurring challenge: each framework comes with its own set of conventions, syntax, and peculiarities. This means that for every new project or framework, time must be spent rediscovering how to accomplish tasks that may have been routine in another environment. The learning curve associated with mastering a new framework can delay the ability to address business requirements effectively.
The constant churn of new frameworks and updates can be exhausting, as developers need to stay up-to-date with the latest changes and best practices. This not only consumes valuable time but can also lead to frustration and burnout. Sticking to vanilla HTML, CSS, and JavaScript can mitigate these issues, providing a stable foundation that doesn't require constant relearning and adaptation.
While frameworks tend to drive developers into writing the same way, in practice this is hardly the case. Of course everyone wants to have colleagues who write like themselves. But then again, I don't even write the same way myself. We're all learning and growing and so are our solutions to problems.
Have you ever tried to update your dependencies on a code base of 10 years ago? I have! I tried! I failed!
It is truly mind blowing what a tangled mess outdated packages become.
Truthfully, that's my lack of knowledge. But don't ask me to investigate, learn the old framework and the new framework just to get a simple build started. How many story-points is that? Euhm…
If you master the basics, you can learn any frontend framework you want.
If you master only a specific framework, good luck once it has fallen of the bandwagon. Frameworks come and go. It is inevitable. The basics are more likely to stick around longer.
Almost all our projects inherit a .Net infrastructure since we are experienced with CMS/DXP Integration. These software packages are written in a certain server language, hence the servers are configured to support this. Frontend in this regard is always the top-off layer. The cherry on top. The part that makes things smooth and fun to interact with.
A particular trick to understand in SPA frameworks is optimization comes at page load. Leveraging only those building-blocks for the so called page which is active. How does it determine which page is active? It's all about taking routing to the frontend. Your Webpack configuration together with lazy loaded imports can now tree-shake the page requests.
To this day we are still not developing SPA's. We focus on website integration into Digital Experience Platforms (DXP). This means the customer decides which components are displayed on each page and pages are not pre-configured. They can be templated though but this also means routing is handled server side which is imho a big advantage. This way we can go completely dynamic, we provide the LEGO, you build a house, a plain, a town, … or in this case, a website or a whole lot of websites all on the same platform. Using the same building blocks but with a different design or theme in mind.
One of the most compelling arguments against frameworks is performance. While frameworks promise efficiency, they often come with a payload of unused features and dependencies, bloating our applications and slowing down load times. By sticking to vanilla JavaScript, we ensure our code is lean and optimized, delivering a snappy user experience.
Understand that using a framework is always, no matter how tiny or optimized your framework really is, but always an extra step to rendering Vanilla JavaScript.
Our approach consistently yields high scores in Lighthouse audits (performance, best practices, accessibility, and SEO). This demonstrates the effectiveness of using vanilla technologies in delivering optimized and high-quality web applications.
You can make the analogy of .Net Framework to assembly. But that leaves a too big of a gap to my knowledge. With JavaScript this gap is rather small in comparison and therefor the argument against a framework is more relevant. Also remember JavaScript is frequently updated and today's browser support is looking very positive.
Frameworks, by their nature, impose a set of conventions and abstractions that can sometimes limit our flexibility as developers. By eschewing away from frameworks, we regain control over our code, allowing us to craft solutions tailored to our specific needs. This simplicity not only improves code readability and maintainability but also fosters creativity and innovation.
In our context, steering clear of frameworks offers a significant benefit: the long-term reusability of our code. This means we can seamlessly transfer modules from past projects to future ones, like drag-and-drop functionality. Frameworks often bind us to their specific ecosystem, where updates and changes between versions and dependencies can disrupt the compatibility of components, making it challenging to reuse them across projects. By adhering to plain HTML, CSS, and JavaScript, our code remains modular and portable. This enables us to tap into existing solutions without the need to start from scratch, ultimately saving time and effort while ensuring consistency across projects.
For small teams, the onboarding process for new developers is crucial. By sticking to vanilla web technologies, we ensure that new hires can hit the ground running without the need to learn a complex framework. This reduces ramp-up time and allows new team members to contribute effectively from day one.
While it's true that young developers may not yet have mastered all the basics, foundational knowledge in web development, such as understanding HTML, CSS, and JavaScript fundamentals, is timeless and invaluable. These core skills form the bedrock upon which developers build their expertise over time. Unlike framework-specific knowledge, which can quickly become outdated with new releases or changing industry trends, mastering the basics provides a lasting framework for continuous learning and adaptation. It fosters a deeper understanding of web technologies and principles of software development, enabling developers to tackle a wide range of challenges throughout their careers. In contrast, relying solely on framework-related skills may limit developers' adaptability and growth as they become dependent on specific tools rather than fundamental problem-solving abilities. Investing in foundational knowledge ensures that developers not only excel in current technologies but also remain agile and capable of embracing future innovations in the ever-evolving landscape of web development.
HTML, CSS, and JavaScript are the building blocks of the web. By avoiding frameworks, we simplify our build steps and code management processes, reducing overhead and increasing productivity. This streamlined approach ensures our codebase remains clean and maintainable, even as projects evolve over time.
All major CMS systems follow the MVC (Model-View-Controller) pattern, inherently promoting a clear separation of concerns (SoC). By using vanilla HTML, CSS, and JavaScript, we reinforce this separation, making it easier to maintain and debug our codebase. This clarity improves maintainability and fine-tuning once a project reaches its final stage.
Depending on what you are building. Frameworks are well-suited for large and complex applications that require scalable architecture and robust state management. They provide structure and consistency, making it easier to manage and maintain extensive codebases. When building SPAs that require dynamic content updates without page reloads, frameworks like React, Angular, and Vue are ideal. They offer efficient client-side routing and state management. For web applications that need real-time features such as live updates, chat functionalities, or collaborative tools, frameworks can simplify the implementation of websockets and other real-time technologies.
Depending on your skill sets. Frameworks come with pre-built components and libraries, enabling rapid prototyping and quicker iterations. This can be particularly beneficial in startup environments or for projects with tight deadlines. The ability to reuse components across projects can significantly speed up development. Frameworks often provide a rich ecosystem of third-party components that can be easily integrated.
If your development team is already proficient in a particular framework, leveraging that expertise can lead to faster and more efficient development. Familiarity with the framework’s tools and best practices can reduce the learning curve and improve productivity. Frameworks with a large community and extensive documentation can make it easier to onboard new developers, as they can quickly get up to speed with standardized practices and tools.
For customers who demand highly customized and polished solutions, frameworks can provide the necessary tools to create sophisticated and feature-rich applications. However, this often comes with increased development time and costs. If the primary goal is to deliver a functional solution quickly without extensive customization, using a framework can still be beneficial due to its out-of-the-box features and components that handle common tasks efficiently.
Custom solutions tend to be more expensive due to the additional development time required for fine-tuning and customization. Frameworks can help manage costs by streamlining the development process and leveraging existing components. Consider the long-term maintenance implications. Frameworks can simplify ongoing maintenance with their structured approach and community support, but they can also introduce dependencies that need to be managed over time.
The applicability of frameworks depends on several factors including project complexity, development speed, team expertise, and the nature of the solution being created. For large-scale, complex applications, and real-time features, frameworks provide essential tools and structure. They enable rapid prototyping and efficient development, especially when the team is familiar with the framework. However, for projects requiring highly customized solutions or where simplicity and maintainability are paramount, a more tailored approach using vanilla technologies might be preferable.
The choice ultimately depends on balancing the project's requirements, the team's skill sets, and the desired outcome.
Ready to take your digital experience to the next level? Feel free to contact us to learn more about our services and how we can help you leverage the full potential of your digital marketing.
Get in touch with one of our consultants to find the perfect match that fits your needs and enables you to grow.