Every so often there's an article I'll read that's like, "You don't need a JavaScript Framwork! Just use vanilla JS, it's so much better! Why can't we all just use jQuery again?" Obviously these people are intelligent in their own right, but I respectfully but strongly disagree. In this blog post, I'll share my experience building a fullstack CRUD chat app with Bootstrap, Alpine.js, and Pocketbase. (Spoiler alert: It f██kin' sucks)
Code: https://github.com/Gravy59/petite-fullstack
Edit 3/7/23: It seems that I haven't been clear in this article, I decided to create a fullstack application in vanilla not to show that "yOU DON'T nEEd a fRamEWoRk" but to show how difficult it is in relation to something like react. And still, I was not using vanilla. I was using Alpine, which is still a framework. I hope y'all understand.
Getting Started
To get started, I created a new project folder and created an empty html file. I chose not to use npm and instead opt for link and script tags from CDNs. I threw in Bootstrap and Alpine.js. Alpine is basically the modern version of jQuery, and I'm more comfortable with Alpine from the copious amount of classes my school had on it that one year. Bootstrap provided me with a pre-built user interface that I could customize, and Alpine.js allowed me to add interactivity to my app.
For the back-end, I chose Pocketbase, which is a cloud-hosted database service that can be accessed through a simple REST API. Pocketbase is easy to use and integrates well with front-end frameworks like Bootstrap and Alpine.js, making it a great choice for this project.
Creating the User Interface
After setting up the project, I started creating the user interface using Bootstrap. I designed a simple chat interface with a list of messages on the top and a message input field on the bottom. In about five minutes I had a basic chat interface without any interactivity.
Next, I added tried to add interactivity to the interface using Alpine.js. Full stop here, I'm not a programming God. I don't know too much about data fetching with vanilla JS. After pouring to the Alpine docs for a bit longer than I want to tell you, I settled on a function called pageData that would fetch data, subscribe to messages, and expose important variables to the client. I also bound the chat form with x-model to the text variable on my pageData function. This is important because Alpine has a weird form paradigm. Now, I can use @submit.prevent to run a function on pageData to grab this.text and submit it to pocketbase. As a final touch, I used x-transition for some smoother animation.
Data modeling
Pocketbase is awesome because it allows me to abstract security rules. I created a messages collection with one column: text. Pocketbase automagically sets an id, relation to a user, and creation/update dates. In my API rules, I unlocked List/search, view, create, update, and delete. For creating, updating, and deleting, it's important to restrict those actions to the user who created the message. I copied user.id = @request.auth.id to all of these. This forces PB to only allow logged in users to send messages and only allows the creator of a message to edit or delete.
User Authentication
User Auth with PB's SDK is easy. It saves sessions in localstorage and verifies them with the server. All I needed to do was use Alpine's x-show directive to show and hide login, sign up, and the actual app based on the authentication state.
R & D
For reading messages, I had to subscribe to them to get realtime communication. To do that, I used PB's SDK to subscribe and add a callback function to determine what to do with the UI when a message was changed.
client
.collection("messages")
.subscribe("*", async ({
action,
record
}) => {
if (action === "create") {
const user = await client.collection("users").getOne(record.user);
record.expand = {
user: [user]
};
this.messages.push(record);
}
if (action === "delete") {
this.messages = this.messages.filter((m) => m.id !== record.id);
}
});
Final Thoughts
Here's the deal: Yes, it's possible to not use a framework. Is it easy? HELL NO! Personally, If you want some level of interactivity that needs dynamic UIs, you can try to use something like Alpine or petite-vue, but if you need more than that, something like svelte or anything from pnpm create vite will make your life so much easier.
Thanks for reading, y'all!
Top comments (84)
I don't quite get the point you're trying to make. What's the supposed difficulty here? You're using some libraries and have to look up how they do certain things, but the same is just as true for frameworks.
This whole long-winded explanation seems to come down to is that you post some text to a server and subscribe to messages from it. This isn't exactly rocket science and there's probably plenty of stack-overflow answers on how to do this easily.
At the end of the day, vanilla JS is just another way of doing things that you have to familiarise yourself with, not unlike any specific framework. I don't think that points towards the necessity for frameworks, just the necessity to know the tools your working with.
Friend we are not talking about a simple landing page that has just 4 lines of JavaScript for it's burger menu in nav bar. We are talking about building useful and real projects, and the guy how posted this don't say it's impossible he is saying "it sucks" and "not easy".
If we talk about the job market and 99% of real projects they all use a framework like react or angular etc... So you have to learn it at some point there's no way around.
Why am I writing this long response to you As I'll get nothing from this comment? Because at some point i believed these YouTubers that you don't need a framework and this sentence wasted too much of my time and effort.
If anyone thinks that you don't need a JavaScript framework please make more research about "what's uses of a framework" and "what can a framework do that's impossible to do with JavaScript"
Hope you get my point ma man love you all ❤️
Nothing. Literally nothing. By definition, anything a framework can do is possible with vanilla JS.
The question is how much harder will it be, and I am just not convinced that 90% of modern frameworks is needed. The overwhelming majority of the usefulness of frameworks, to me, seems just bridging the small gap between generic web APIs and a more usable interface, which is like a few hundred lines of code on a bad day.
If the UI is simple vanilla JS is just fine. It even can be a simple chat. Please have a look at the Firebase official tutorials. There is a simple chat built by vanilla JS tools. What if your UI is complex, a single page application? You practically need a framework to do this or a UI library and a rooting library at least like React and react-rooter. This could be done in vanilla JS because these are written in JS. It is practically impossible or very long time.
Really though? Most examples of "oh vanilla JS is so cumbersome" are usually people just fumbling around and intentionally writing everything out at every place, but lots of things you can just write a function for. Sure, there's nothing wrong with using a framework that already does it, but that's just to save a bit of time re-writing the same thing for the 20th time, and even then, you can just roll your own micro-framework as an in-between step.
So no, you really don't need a framework, and not using one won't make your life incredibly difficult either, it's just a bit of convenience that adds up over time.
You will not know until you build these things yourself. I built a couple of vanilla JS apps and even a really simplified copy of Facebook by React and Redux and Firebase. That one has a messanger functionality inside too. Even you can register and say hello. Fakebook where you can register and try.
This kind of thing would not have been possible practically only with vanilla JS. Theoretically it is possible but when you use a library like React, you actually use the experience of those developers, who built it. I certainly do not have all that experience yet and perhaps you do not have it either unless you were there to develop React.
And another aspect is that when you work on a big project with several developers that will come and go... Having a popular framework with established design patterns will help tremendously when it comes to code consistency
Commercial development is a strong competition. If other companies use a framework and they can achieve their goal with that faster and the quality is better our company cannot just simply use vanilla JavaScript, because we would have a huge disadvantage. The market has its laws and we cannot go against that, otherwise we fail. We can choose the best possible framework, which leads to the best possible product in the shortest possible time. This is the truth about this, but a Facebook complexity UI cannot be developed practically with simple vanilla JavaScript. It is not economical and actually practically impossible without our own framework. There is usually no need to develop our own library or framework, because several great choices are available on the market, from React to Angular or even Svelte. The companies make their decisions on economical bases and they are not crazy. There is a good reason to use these frameworks or libraries above a certain UI difficulty.
I do hope that you understand, I wasn't bashing on frameworks! I think that devs should at some point program in vanilla with maybe Alpine or petite-vue to get a better appreciation for frameworks.
Sorry for miss understanding you. My answer goes to all devs that say frameworks are useless or you don't need them, there's a lot of people saying this you know just wanted to make things clear to them a little bit
It also seems I miscommunicated - I was saying that vanilla absolutely sucks.
you had me until the latter half then your thought train kinda went Ruby off Rails.
Everyone was going "you don't need a framework" so he went "you don't need - a you don't need a framework".
The point is that frameworks let you concentrate on implementing the actual business logic of your app, instead of spending time figuring out how to optimize DOM manipulation in vanilla JS, or how to write that selector that you need to select that specific node... The people who made the frameworks did all that work for us. So we can focus on what the client actually asks for.
Can't we use web components? I mean, maybe something like Lit. It is lighter and doesn't use a framework. Sure it isn't as easy as using
npm init vite, but React (or whatever you use) also has it's own share of problems, isn't it?
TL;DR: Great article. A framework is needed for ease of development but we should consider other options as well instead of following the 'bandwagon'.
I agree wholeheartedly! I wrote another article comparing react with svelte, and it was interesting to see how a simple counter app in Svelte is 96% smaller than React, even with vite. Mainly, I haven't used lit because I don't see the purpose of web components, though I do know that google uses them extensively for products like YouTube.
Lit is the best library for js/ts right now. And all the lambs still uses react, blindly following the main stream. I pity them.
I also pity the article auther. I feel like he just started developing a year ago and he write on a subject that he knows nothing about - js...
I haven't actually tried Lit. I'll take a look. Still, I believe that all libraries and frameworks have different strengths and weaknesses. React is a popular choice for good reason, and it's still a cash cow for Facebook, Instagram, Airbnb, Discord, Pinterest, Netflix, etc. And I stated in the article that I'm a mediocre dev at best.
Exactly. Also, if people find something they don't like about Lit, they can take steps to see those in future releases. React was not so massive when it started, contributors kept supporting it to make it massive. If we see such contributions in Lit, surely it will flourish and show better performance.
See you building production grade app with lit. Good luck to shoot your legs double, then triple shot.
But that's what I'm doing for 4 years now after we moved from a react disaster.
And by the way YouTube is not production grade?
Lit is similar syntax to old React... Its different in what it targets and what it generates... Lit just outputs web components where React outputs js code. The problem with web components is that they can't deliver (yet) on what they promise.... You can't just blindly use them anywhere, except in vanilla HTML code which hardly anyone still uses... Frameworks like Lit (which really is just another framework) offer adapters to use your Lit components with other frameworks like React or Angular... The fact these adapters exist already speaks volumes. Maybe many years from now when the web is not dominated by a non-vanilla HTML framework... I don't see that happening for atleast another 5 years and probably more like a decade.
I'm getting a lot of mixed messages from you.
If it's "just outputs webcomponents" how is it "just another framework" ?
Wecomponents are also just js code... So it's outputing js code same as react?
I can't use them blindly everywhere? But Google can. You know in Gmail YouTube and everything they build...
If you referring lit components inside js frameworks you can. Even in astro or preact. The only need for an adapter is in react and i never used it.
The output from web component frameworks like Lit is not just js code, its html/js/css, in contrast to React that only outputs js code.
Google cannot blindly use web components in angular or react code either, they need an adapter, same as everyone else.
You cannot blindly use web components in astro: navillus.dev/blog/web-components-i...
Take note of the word "blindly" you can use web components anywhere, but not blindly. for most js frameworks, you need to follow framework specific config, or use an adapter in some cases.
I still don't get you, sorry.
lit compiles the css & html into the js so it only outputs js.
Who said google use angular or react in YouTube? They could just use webcomponents.
The article is nice but seems really straight forward to me. All he says is also correct for vanilla js... I don't know maybe I can agree about not blindly.
The web components framework they use is called spf-js.
I'm saying that IF google were to use angular or react, they too cannot blindly insert web components into it.
Over the past years, many different web component frameworks have popped up, and most of them have some way of exporting their components, so they can be used in frameworks like React, so appearantly there's a need for that.
Tbh I think 99% of the people here arguing against frameworks, are using some kind of framework or library themselves... It's just not React or Angular, or one of the other well known ones. Vanilla appears to be a highly subjective term. The only thing that matters is the JS (ecmascript) language spec and devs using frameworks like React are just as aware of it as "vanilla JS" devs.
Or AtomicoJS. But really these are just other frameworks as well. Nobody except insane people want to do everything manually with vanilla JS anymore. Unless you're building a framework of your own...
Here's the actual deal: Yes it's possible to not use a framework. Is it easy? Objectively speaking, this entirely depends on your level of experience with JavaScript.
If you've only ever been exposed to frameworks, you will struggle. If you've ever scratched the itch and decided to better understand how things work, it will become progressively easier.
If you're using a js framework you ARE using JavaScript. What you mean is probably experience with manual DOM manipulation and i can guarantee you that you have less experience in that than the people who wrote these frameworks whose sole reason for being is because manual DOM manipulation sucks ass and takes up time that can be used to build actual value for the customer.
2 points:
As the proverb goes; one man's trash is another man's treasure. Your definition of value is definitely not the same as mine.
Ok... Not sure why you feel so attacked...
You could chose your words more careful if you didnt mean to imply that working with JS frameworks doesnt give you experience with JS.
says i should choose my words more carefully, but continues to be passive aggressive. but hey, whatever hits you where the good lord splits you buddy!
see... anyone can be passive aggressive. you should try being progressive. it accomplishes so much more.
Why do you persist in attacking my person?
for someone who has been at this for as long as you have, and with your industry background, you'd think you would carry yourself with a bit more decency and not feign victimhood at the earliest opportunity. though if you honestly don't see how you've barrel-rolled into this entire thread with a holier-than-thou attitude toward everyone and their varying opinions of react, then perhaps it's time for a bit of introspection.
Perhaps you should do the same.
i do. often. can't expect to better myself or better help the people around me otherwise. just try it. you might surprise yourself.
Heyo! Please avoid personal attacks. It's okay to disagree on the topic at hand, but keep it civil and in line with our Code of Conduct. No more of this, please!
no issues from me
What you missed is that true vanilla modern JavaScript is not that complicated to use. We have native things that work even better than most libraries. I have two examples:
Most companies want to use react for the ability to create components and reuse them as an html tag. The truth is, when you open your browser's dev tools you only see a bunch of divs with classes. If people put as much time learning vanilla instead of react, they would see that native components exist and are not that bad. Even better, if you open your dev tools you really see them in the html. They also are treated as classes, so you can play with all HTMLElement methods, make getters, setters, static methods, private attributes, inheritance, etc. Just look at the doc and you'll love it.
You mentioned jQuery and data fetching, but the native querySelector, addEventListener fetch... functions are just as powerful (especially fetch. You don't need a complicated library) you just need a few more characters than jQuery, not that bad.
The next time, look at what JS can do for real instead of thinking it's just a moving back to ES5.
This is really not vanilla JS you're talking about. You're talking about HTML tags and you can use all of them in React. You can also use querySelector in React (you probably shouldn't though). And you can use event listeners as well in React and people do... I'm not seeing the point you're trying to make except that maybe you don't know a whole lot about React?
The author said some people say "why can't we juste use jQuery" and tries to make a point about not using frameworks being difficult by using libraries instead of vanilla.
When people like me say "we don't need frameworks", we mean "use vanilla".
Also, the goal of react is to use JSX, an html syntax inside of JS allowing the use of handmade components (using their html tag). But when you open the dev tools, you only see divs with classes. My point is that native html element registering using a JAVASCRIPT class extending HTMLElement is way better in my opinion. Like react, you can use your component in html (event in js, using innerHTML for example). The difference is your component is an actual element showed in dev tools with its own class, properties, methods...
The goal of React is not JSX. JSX is not even a React only thing. Its just a way to use html style code inside javascript (a syntax extention to javascript). You can use React without JSX but its cumbersome and very not recommended.
React doesnt make up anything that you don't tell it to. If you use a
, it will output a , if you use it will output , etc.Are you talking about web components? The web-component API (if you use it barebones/vanilla) is actually quite similar to React without JSX. (Document.createElement vs React.createElement)...
I'm talking about custom elements web.dev/custom-elements-v1/
Yes, thats web components. The problem with web components is the same as other vanilla JS solutions, they require you to write your own DOM manipulation logic, for data driven apps.
If you use getters and setters (especially well made in JS) and use the class to hold the logic, it's not that much of a problem. For example:
In the constructor, you can simply do
this.innerHTML = '<span id=name>${name}</span>\'(with backtics) and such things to construct your component content with data. There are even VScode libraries that add html autocomplete, text highlighting and formating without needing any js library.You can also add a
get name_span()that usesthis.querySelector("span#name")so you can writethis.name_spanto access it. Then, you can add aset name(str)that just doesthis.name_span.innerText = str.It took two minutes max to allow the use of
this.name = "joe"to change the name. I know that some people like to just describe the content and have a reactive behavior right off but I personally think react is too much (the lit library would do the work if I really needed)I don't really know any valid reason to choose react most of the time in companies and never settle with vanilla. It really belongs to personal preferences and what you're used to.
The problems start when you want to dynamically add new DOM nodes after a user interaction and attach all kinds of event listeners to make those new nodes interactive as well... Thats a lot of JavaScript code, that you're just going to end up repeating over and over, so you abstract that code into some library and BAM new React is born. 😛
I don't see where the necessity of adding event listeners to new nodes is different in vanilla and react?
React adds event listeners automatically based on your components code.
You just do it the way it was done before react (and how react does it). Use event delegation.
You mean that inside you component code you add your event listeners like "when I click this component, alert hello" so that every time you create one, this event is added automatically?
I think I misunderstood (In fact I didn't go that far with react projects) because that's what you can do with a native component since it's a class. In the constructor you can call "this.addEventListener"?
developer.mozilla.org/en-US/docs/L...
So just events? I don't see the difference between react and native components for event listeners?
Yes, that becomes a nightmare to manage in apps with lots of user interaction. That's exactly why frameworks like React were created because most devs dont care about manually managing event listeners.
My main issue with React is the use of made-up events (synthetic) instead of native browser events. This is what makes React incompatible with the native web technologies known as web components.
React sets up event listeners on the rendering root using event delegation to create synthetic events.
Indeed.
They're very different, for one. React uses synthetic events and you don't have to manage event listeners manually. In React you create a component and you handle the events that you want to handle by using the onClick prop for example. After that, you don't care how that component is used or how many times it is mounted. With vanilla js you have to reattach the event listeners that you need for each DOM node that you add.
You don't really have to manage it by yourself if you use another framework like Solid, Svelte, Lit or Vue either.
I don't mind React. It's ok but I feel it's a bit outdated these days.
But working against native web technologies is quite bad imho.
Yes but that was the point of the original article. You need a framework or library to manage DOM manipulation for you. React may eventually become obsolete yes, but for the time being, it still adds value for the developers using it.
you don't need shoes to walk but it helps
I LOVE THIS
I'm really surprised at all the hate I'm seeing in the comments from what is usually such a positive community. I thought this was a great demonstration of how frameworks aren't "necessary" but allow you to speed up value creation.
I'd add that even though some commentators seem to look down on those who go along with the "popular" frameworks (react/Vue) that there's one big perk popular frameworks have over cutting edge strategies... everyone knows them!
If you're only working on a hobby project then by all means use whatever system you want (and that include vanilla... In fact I like going no framework for hobby stuff because it feels calming to plink it out step by step). But if you're doing this professionally you have to think about your next 4 hires that will have to continue what you started.
I guess that you are a react senior, but a vanilla JS junior.
I've been with JS since 20 years ago. Have lived all his changing steps and I almost always work with vanilla JS. I even have my own MVC.
Still I like react a lot, but I work way faster with vanilla JS than using any framework I'm not used to, specially nowadays with modern JS. And with the browsers having implemented the modules features, I don't even use webpack or similar now.
Yes, it is possible to work efficiently without frameworks. You just need to learn to do so (if you want to) the same way I spent time learning react.
You seem like those kind of people that couldn't live without a library or framework, because even when you tried to do so, you still picked frameworks to do the job lol. Trust me, JS is more than just frameworks.
React is js. You cannot be a React senior and not know JavaScript. What you probably mean is: junior at knowing how to manually manipulate the DOM.
As for trying to shame someone for using what is already there and building on it, instead of trying to do everything yourself... Good job 👍
Yes, I said junior vanilla JS (Note the "vanilla" keyword). I was implying that has low experience without working with frameworks/libraries (that's what vanilla means), which he does as his vanilla JS tryout still has libraries xD
Is just experience, trying and discovering what fits you most. Shaming the other part is dumb, but showing alternatives and how to try them properly (obviously zero libraries/frameworks as per vanilla definition) is not, and nowadays vanilla JS is the alternative. There was a day where react, angular and so on were the alternatives, and the Internet was full of "why you need frameworks". Still they were comparing against jQuery and not vanilla, though.
What I mean is, if you truly want to try vanilla, learn to work with vanilla and see if vanilla fits you, you must go zero framework/library, just to test it. Although you are a "framework developer", it helps so you can understand better how they work under the hood and how you may be abusing the npm. I understand the use of libraries, I even use them but come on, there's even an is-array library that people install on purpose nowadays. There are senior react devs out there that they still don't know how the virtual DOM works.
"using what is already there and building on it, instead of trying to do everything yourself" is just the contrary of what "try vanilla" means.
Everything that ever existed, was made for a reason. Everything that was ever popular, was popular for a reason. Frameworks and libraries and anything else on npm exists, because someone thought it was a better idea to make something generic, than having to reinvent the wheel each time for every project. Everything thats popular on npm is popular because other developers also did not want to reinvent that particular wheel for every project. There are only so many times you can reinvent the wheel before it starts to become really boring and tedious.
Your assumption that people who use frameworks, do not know everything that you know about javascript is wrong and frankly, also quite arrogant. Many of us have been around for a long time and have used vanilla when frameworks didnt exist yet and climbed our way up through jquery, backboneJS and other early frameworks and libraries, until angular JS came along and later ReactJS. Even in the oldest days, when we would google for code snippets on javascriptkit, people have wanted to reuse things that other people came up with. You are only ONE person, you dont know everything. Its better to build on the collective knowledge and time-investment of thousands of developers world-wide.
"Your assumption that people who use frameworks, do not know everything that you know about javascript is wrong" I never said that. Don't put words into my mouth because I even use libraries and frameworks (even have PRs in popular libraries like Highcharts). I think that my point is pretty clear and you are distorting it from your very first comment, I don't know if in purpose or you have reading comprehension problems.
To make this clear: This only applies to people that have never tried vanilla properly. Maybe you discover a world unknown to you. Both "framework" and "no framework" developers are right. Just check the other side properly, just in case. I've seen jQuery people try react and still access the real DOM and doing modifications with jQuery. That's an example of trying the "react approach" badly, and is good to point that out as you are going to have a bad unreal experience of what it would be if you do it properly.
The point is that JavaScript used to be not that good alone, so jQuery and other libraries / frameworks arrived to make it better. But JavaScript has evolved alot and even gets better vanilla than with some frameworks.
The fact is that most people who have been using frameworks for decades didn't see most of the new vanilla features, because they didn't need them. Now companies want react devs, so online courses want you to start using react as soon as possible without really getting into vanilla JS.
During my last job interview, I got to speak to a senior react dev, and he didn't even know we could just create a class expending HTMLElement and register a new component that can be used directly in html. Which was his point about why react was better (he ended up using vanilla)
That's a really strange react senior then, if they don't see the benefit of using a framework for DOM manipulation. Not sure why they were using React in the first place... Did they build data driven apps at all?
That's the exact point. Now he knows this "new" thing, and may use it. Now has another point of view that he may apply in his next projects.
I'm really curious why they chose react in the first place if they don't see value in what it does 😅
U TOTALLY NEED A FRAMEWORK 😂
You don’t need a framework.
Will using a framework deliver some combination of improved DX, saved time, helpful abstraction of low level boilerplate etc etc? Sure.
Will using a framework also introduce its own overheads and trade offs to consider? Yep.
Do the benefits outweigh the drawbacks? Depends on the project and the framework.
These sweeping “you don’t need”/“you must have”/“serious developers should always” debates about frameworks are reductive, gatekeepery and ultimately pointless.
The tools you need will always be dependant upon the requirements of the work you are doing.
This is a fairly good objective analysis 👍
I didn't read, or even see, the posts that inspired you to write this post. Unfortunately, most of what I see in my feed are posts about how to do something in React, 23 react extensions that "every developer MUST know [in 202x]", or "I discovered a new framework that will change your life" or one of those recent let's rediscover the DOM (but let's give it a new trendy name and concept as well).
It seems that the other posts criticized frameworks for the wrong reason.
There is nothing wrong with using tools and frameworks. There is a reason we have React, Vue, Angular, Svelte, and jQuery. There is a reason that we have Webpack, Snowpack, Parcel, Gulp, Grunt, Rollup, etc. There is a reason that we have Symfony, Laravel, Cake, etc., and there is a reason for Drupal, Webflow, and WordPress.
Use the tools when it makes sense! But don't use them when it doesn't!
Too many people have been using React for everything frontend-related, only to discover server-side rendering later, only to discover something else and reinvent the wheel again and again. Maybe the never used Vanilla JS for DOM manipulation, so they use overengineered logic like "controlled input" for a simple web form that should have been fine (and probably even more accessible and backward compatible) in plain HTML 5, CSS 3, and some lines of Vanilla JavaScript for form validation fallback, if necessary at all.
So let's say I agree with your point, but I disagree with the implicit conclusion some readers came up with. Some people tend to use JS frameworks "simple landing page that has just 4 lines of JavaScript for it's burger menu in nav bar", and that's just as bad as not using a framework for a complex web application.
You do realise React isn't a framework right?
Vanilla JS is pretty straight forward, but it depends on how much vanilla JS you've done. Yes libraries (and even more so frameworks) give you an accelerator if you're happy with the boundaries and implementations they impose.
Like most of the times, the truth lies in the middle and the answer is more complicated than a simple yes/no
First of all take my words with a grain of salt I've never worked with JS or any other web language, but my experience may still count.
I agree that without a framework the work may get a little harder, but after all that's the whole point of a framework. It provides a series of prebuilt constructs/APIs/utilities to simplify our job.
There are downsides too of course, the bundle size of your app, which seems to be especially important in frontend from what I see. It's usually less versatile because...well you gotta use what the framework provides just how the framework intends to. While on the other hand if you make your own yon can re-factor, adapt and extend as much as you like.
Then there's also another factor that many programmers seem to ignore all the time, and it's very important to me. Learning new things.
I get it I get it, you just want to finish your app, show it to the world and get appreciation for your job. Just use pre-made things and get it done quickly. But at the end of the day did you really learn something?
It's always fun and interesting to understand new things, especially when it's about your passion.
So, just sometimes, why not reinvent the wheel, challenge yourself and try coding new things.
Not so long ago. I needed to create a List component from scratch because the one provided by the GUI framework was kinda bad. How many of you knows how Lists(and similar) work?
Well, I had to learn about virtualization to display a ton of items without lagging, and I had to build a virtualization API from scratch that could also be easily adapted to lists, grids and tables.
It was so damn hard, learning such a low level concept/component. But after quite some time I got it right and it is now super efficient, well documented and we'll organized. It is just so satisfying and I can say to be proud of my hard work.
So, my final point is. Yes, frameworks must be used, they simplify our jobs and it would be stupid to avoid them at all costs. But... Sometimes why don't challenge ourselves and try learning something new, it will be fun!
I've been a JavaScript developer for 15 years now and I think the biggest problem that we have is twofold:
1) Frontend has a low barrier to entry
2) Nobody actually learns Vanilla JS anymore
The barrier to entry is now so low that anyone with any minimum almount of programming experience can build a webpage in a matter of minutes. You have countless frameworks, you have copilot/stack overflow and a plethora of boilerplate starter kits to choose from - with more and more becoming a 'one command' starter with npm create XXX
People starting to develop don't know any better and just run with it, jury-rigging whatever examples they find to get the intended result.
Does the code work? Probably.
Is it efficient? Bug free? Accessible? Probably not.
The whole purpose of frameworks is to make our lives easier. Unfortunately it also makes it easier for developers to be lazy about what they learn (e.g. becoming a React developer versus a JavaScript developer)
This then circles into the second point. The general lack of Vanilla JS knowledge means that people are not able to make an educated decision on when to use a framework (or even what one to use)
I think this is the root cause of the discussion, leading to people with more experience saying 'you dont need a framework' to junior devs or just in general. What they actually mean is probably more along the lines of 'you should probably learn how to do this with Vanilla JS so you understand why you need the framework'
Having knowledge of Vanilla JS helps pick up new frameworks quickly, debug issues in open source projects (no project is free of bugs, no matter how big or popular it is)
There is no doubt in my mind that you should probably use a framework of some description for every project you're building, but you should take the time to understand why you're using it first and not just always stick with what you know or are comfortable with
There are a lot of things that you don't need to build a website, here's a list of some:
IDE,
OS with GUI,
Mouse,
Internet Connection (you need it just to upload it),
CSS,
JS....
We end up that you just need an index.html file to create a website 😁
You don't need stack overflow either, or a database. Just keep everything in memory or use fs to write to disk. Dont need localstorage or cookies either, just ask the user to login for every request :p
sorry, I do need
To each their own.