Modern Frontend Development – Vanilla vs. Frameworks
Are React and other frameworks the best choice for your tech stack in 2024?
Every software development company must ask itself how to build the client-side components, app, or the front end.
Technologies to create user-faced apps range from JavaScript, Kotlin, PHP, and more. Do you remember ActionScript in Flash 😀? But only one language shines with cross-platform capabilities: modern JavaScript. JS successfully established itself on all major platforms and devices, both front and back.
But JavaScript isn’t just one thing. There are a lot of facets to it. Use it with a library? Use it with a framework? In which environment will it be developed and run?
I would suggest it’s not an easy decision-making process since there are a lot of aspects to it, and I want to write about those aspects today.
Modern JavaScript - A Mature Way Of Developing Software
When I started with JavaScript about 25 years ago, it was hard to get easier features done. There was no common “JS”. There was JScript, running in Internet Explorer (🪦 June 15, 2022), and JavaScript, initially developed for Netscape Navigator 2.0 by Brendan Eich1 in 1995.
Later, Mozilla Firebird (Or Firefox today) was the first browser I was happy with. It followed the ECMAScript 3 standard back then. The first platform for JS actually aimed for real standardization during browser wars.
Back then, we needed libraries like prototype.js to have a bit of commonality between browsers. I don’t wish myself back to those days!
The Era Of jQuery
jQuery (John Resig2, 2006) took over and became the most popular JS library around 2008, and it’s still used. I suppose WordPress still does this on the internet. I was never a big jQuery fan and wasn’t a real adopter. But undoubtedly, it paved the way for the idea of common libraries and frameworks everyone works in instead of plain JavaScript, considered a language with no real standards.
🍪 Still, the term “Frontend” wasn’t widely used in this era. The front is still generated by the Backend in the “full-stack” idea, like with PHP, Java, or ASP.NET. jQuery wasn’t used to create standalone clients; it is still a way to enrich HTML/CSS pages with dynamics.
Frontend Became Reactive
The era of reactive frameworks is generally considered to have started in the early 2010s. This period shifted from traditional server-side page rendering to more dynamic client-side single-page applications (SPAs).
React was released by Facebook in 2013 and quickly gained popularity for its virtual DOM and reactive data flow, which made it easier to build dynamic user interfaces. Its popularity surged significantly after its initial release in 2013 due to its innovative virtual DOM and component-based architecture, which addressed many challenges developers faced with updating complex user interfaces.
Although initially released as AngularJS by Google in 2010, Angular introduced its reactive features more prominently with the complete rewrite of Angular 2 in 2016, which embraced reactive programming principles with RxJS and two-way data binding.
🍪 With the introduction of reactive libraries, frontend development became a standalone and widely adopted discipline, similar to the one of “Mobile Development.” When planning a tech organization, frontend and backend teams started to separate, and the “Fullstack Engineer” idea went more into the background.
The Mature Frontend Era
Today, we have dedicated Frontend development with solid libraries, frameworks, and human resources specialized in specific fields. Typescript was especially influential here. It is a superset of JavaScript developed by Microsoft and released in 2012. It has evolved into a widely adopted language providing static typing and advanced features for large-scale application development.
Thanks to TypeScript, JS lost its negative trait of being a loosely typed language, often considered error-prone and immature compared to languages like Java or C#. The same applied to PHP. TS helped a lot with the “Principle of Least Astonishment3.”
🍪 I can even recall many C# and Java engineers back in the day discussing whether JavaScript should even be considered a programming language, as it was primarily viewed as a scripting language for HTML.
Vanilla JS vs. Frameworks & Libraries
In the last 2-3 years, I have recognized several tech organizations and individuals on LinkedIn, like Marc van Neerven4 (Fractional CTO), who aim for the approach to return to web fundamentals.
For example, use web components instead of React Components (Custom Elements5). The idea behind that is that JavaScript has evolved after several decades like no other language out there, and coming with that, the need for heavy libraries and frameworks isn’t really there anymore.
One significant drawback of libraries like React is the considerable amount of code that needs to be downloaded by the client before the “First Contentful Paint (FCP)6” occurs. This becomes particularly problematic in regions with underdeveloped internet infrastructure or less advanced devices, as the delay in loading can degrade the user experience. Moreover, the initial load time can negatively impact Search Engine Optimization (SEO) for websites, as search engines may penalize slower-loading pages, which can, in turn, lower their ranking in search results.
🍪 The push towards Vanilla JS and native web components is also fueled by the desire to streamline development processes and make web applications more sustainable and easier to maintain.
By reducing dependencies on external libraries and frameworks, developers can achieve greater control over the performance and behavior of their applications. Furthermore, as web standards continue to evolve and browsers become more capable, the gap that frameworks once filled is narrowing, making Vanilla JS a more viable and attractive option for many.
However, it's essential to note that while the shift towards Vanilla JS and web components can offer significant benefits, especially for simpler applications, frameworks and libraries still have their place. They provide structured ways of building applications on scale, offer community support, and can significantly speed up development in complex projects. Therefore, the choice between Vanilla JS and frameworks isn't one-size-fits-all but should be made based on each project's specific needs and context.
Conclusion - Would I Pick Vanilla JS or React for the next Stack as CTO?
My very personal opinion:
The front-end engineering and the business aspects of a tech company are part of my core competencies. So, I understand why there’s a shift back to Vanilla JS, yet I tend to pick reactive libraries as a foundation.
For most of my career, I worked with Vanilla JS (salted with Prototype.js), and I don’t miss it. I speak as a Senior Frontend Engineer now, and I really dislike the clunkiness all grown Vanilla Projects have.
I personally believe that JavaScript alone isn’t a foundation when it comes to Web App Development. It’s just a language with features. To perform well as a company, tech organization, and team, we must aim for narrow and common standards.
JS is a standard, but it isn’t narrow at all; As wide as a barn door 😀
My professional and objective opinion as CTO:
👉 I just deleted the section where I explain why to pick react over vanilla because of three reasons:
I want to discuss this with other Frontend Engineers during the coming week.
I want to hear your audience’s opinions, as well as my streaming partner
have to say about this on Wednesday's 16CET Episode of Our Tech JourneyI want to rethink myself during the coming week since this will be the major topic, including polls and much discussion.
🍀 The newsletter that follows that one next Sunday will conclude everything!
Have a great Sunday!
Adrian
Join us to discuss this topic:
Live on LinkedIn, YouTube & Twitter.
https://en.wikipedia.org/wiki/Brendan_Eich
https://johnresig.com/
https://en.wikipedia.org/wiki/Principle_of_least_astonishment
https://www.linkedin.com/in/mvneerven/
https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements
https://developer.chrome.com/docs/lighthouse/performance/first-contentful-paint