DEV Community

Mikhail Karan
Mikhail Karan

Posted on • Originally published at htmlallthethings.com

Would You Use Vanilla JavaScript (No Framework) On a Project?

What is HTML All The Things?

HTML All The Things is a web development podcast and discord community which was started by Matt and Mike, developers based in Ontario, Canada.

The podcast speaks to web development topics as well as running a small business, self-employment and time management. You can join them for both their successes and their struggles as they try to manage expanding their Web Development business without stretching themselves too thin.


What's This One About?

This week, Matt and Mike discussed whether vanilla JavaScript is viable on modern projects. Vanilla JavaScript is of course the language that the browser understands, but with the increasing complexity in many of today's web development projects, frameworks like React, Vue, and Svelte have seemingly taken over as the tools of choice for web developers. Should you use a framework, or should you use vanilla JavaScript?

Topics and Timestamps

  • Introduction | 2:00
  • Why use a JavaScript Framework? | 11:40
  • Matt and Mike Discuss when and why they use/don't use frameworks | 36:00

Reference Tweet

Thank you!

If you're enjoying the podcast consider giving us a review on Apple Podcasts or checking out our Patreon to get a shoutout on the podcast.

Support us on Patreon

You can find us on all the podcast platforms out there as well as

Instagram (@htmlallthethings)
Twitter (@htmleverything)
TikTok

Top comments (10)

Collapse
 
joelbonetr profile image
JoelBonetR šŸ„‡ • Edited

React is not a framework, it's a lib and thats a huge point to choose the tech stack for a project. If you talk just about frameworks you can change React for Angular in the sentence.

Answering the question yes, I used vanilla JS sometimes if the project suits (i.e. my portfolio).
Let me quote myself from a comment I just wrote on another post:

For the same features and behavior, the complexity is always the same and every time you add more features you add more complexity as well. The question is not if it's complex or not, the question is where do you want the complexity to be.

Do you re-upload the podcasts to youtube? I think it's more fun to watch the faces along the hearing of voices šŸ˜‚

Collapse
 
mikehtmlallthethings profile image
Mikhail Karan

I think there's a lot of arguments between React being a framework or a lib, I think it can for sure be treated as both depending on how you use it.

I've gotten so fast at developing with something like Svelte that even for a small website I usually reach for it šŸ˜…

We don't upload video of us yet to youtube. It's something we are looking into though!

Collapse
 
joelbonetr profile image
JoelBonetR šŸ„‡ • Edited

I'll take a try to the podcast then :)

By the other hand, the rule of thumb for something being a FW or a lib is IoC (inversion of control, a concept where general application flow is inverted), which is achieved by using a service locator pattern, dependency injection pattern, contextualized lookup or a couple of techniques more, depending on the tool.

In Angular or Vue, is Angular or Vue who's calling your code to interpret and do whatever they need to do.

In React you're the one telling React what to render ReactDOM.render(<App />, document.getElementById('app')); plus in React's homepage hero it states clearly "A JavaScript library for building user interfaces"

There are some wrappers to apply IoC to React Apps (check this one) that serves more the purpose on adding dependency injection capabilities to avoid issues
i.e.

  • With Redux having to import it everywhere which is a nonsense.
  • Passing props through components that don't use them (breaking SOLID)*
  • Other issues that can be either a bad app design decision or anything else.

I never needed it though but knowing that it exists is nice just in case šŸ˜‚ just to clarify, adding a third party lib to handle IoC and DI inside a React App doesn't make it a framework, still it's not part of the core API.

Best regards, and please, ping me if you upload things to youtube šŸ˜

Collapse
 
youssefmic profile image
Youssef-mic

I am also guilty of using react for everything but the thing about vanilla JavaScript is that itā€™s so hard to use you have to grab from the dom and do a bajillion things to make it barely work, so I am usually not considering that. šŸ˜

Collapse
 
jaeming profile image
jaeming

I would if the views were relatively small or didn't need much reactivity. But as soon as I start querying for a bunch of id's in the DOM to the point I have trouble keeping track of them or asking myself what was '#post-action' again? etc, then I'm going to shift over to a framework.

Collapse
 
jonrandy profile image
Jon Randy šŸŽ–ļø • Edited

Most of my projects use Vanilla JS

Collapse
 
sharathmohan007 profile image
sharath mohan

I guess it boils down to the team, if the developement team is comfortable is doing it the framework way or the vanilla way, as long as we get things done

Collapse
 
bwca profile image
Volodymyr Yepishev

I wouldn't use vanilla js for anything, I'd use typescript :)

Collapse
 
stojakovic99 profile image
Nikola Stojaković • Edited

I don't see a reason to do it. So far Svelte was the most lightweight option to build something fast and without unnecessary complex stuff for me.

Collapse
 
rickdelpo1 profile image
Rick Delpo

For small projects I just default to plain vanilla. I wrote a Dev article on 17 reasons why I use Plain Vanilla JS vs React. U can view it here.
dev.to/rickdelpo1/react-vs-plain-j...