Vanilla is faster, Vanilla is light. Having a thousand node in a page is not a good idea. May be in some situation you may need it, then possibly a framework can help you better.
@@herrbasanRight. This guy made an insane proposition by claiming that JS frameworks are faster than Vanilla JS. Yet people on internet are trusting this guy, because he just put on a video on the topic!
02:31 - this argument drives me crazy. If a dev is not able to read the code and understand vanilla JS, then the code was either badly written or the dev is not up to par. In that scenario a framework or a library will not help.
what about use TypeScript and HTML allows you to be compliant with old js browsers. Remember Frameworks are not created to solve your problems, but instead are created to solve creator's problems. I rarely use frameworks. and instead use good clean architecture patterns.
How C++, C, Java developers work? Do they don't understand each other's code?really, the thing is web-developers are getting lazy a lot that's why even after using such a High level language like Javascript they don't understand anything. Nice video tho
Whether or not a framework should be used depends on how much JS knowledge a developer has and the particular project. For example, if it's a project involving sensitive information, it's much more secure for me to write my own JS than it is to hand it over to some framework and hope that TypeScript or React has their act together and hasn't missed any important vulnerabilities. XSS is the most prevalent attack surface for hackers, precisely because people don't understand the security implications of using a framework or subset of JS.
@@kidmosey I've been doing software QA for 17 years and my Info Sec master's dissertation was on JavaScript vulnerabilities. Additionally there are some powerful tools out there to keep you right in terms of JS vulnerabilities, and I'm not the only one checking code. That's what a QA team is for, and surely you know it's not the responsibility of a developer to be 100% responsible for testing their own code, right? My whole career and post grad education is literally JS security. Respectfully, I've seen too many fuck ups and "well maybe someone else will check if it's secure" on things like jQuery to trust "thousands of developers", the vast majority of whom don't seem to care about security.
@@kidmosey because Apple and Microsoft are the only owners or contributors to JS frameworks?? That's a false dichotomy. And even proprietary languages like C# and Swift still have vulnerabilities, simply going "well, Microsoft done it, so I guess I can sleep easy" is a pretty reckless attitude to code security. Typescript, for instance, has had known security issues with its transpiling out insecure JS. It's been reported. But so far it hasn't been patched properly. You don't need to be Tony Stark to understanding security risks in good and while it takes effort, to understand the difference between secure and insecure JS. Trusting a third party because you couldn't be bothered to double check everything is precisely why insecure reaches production. Rather than reading what a transpiler does, why not write it myself, or run the Is through the rigourous security checks my colleagues have set up that simply don't exist in things like Typescript.
@@kidmosey It's not some mystical level of achievement though. It's basic, robust security-centred QA and putting some effort it to understanding secure coding. It's not like we're building the next Google. If people don't WANT to put that effort in or don't work for a company that supports it, that's a different story.
@@kidmosey No, it is not more foolish. What is foolish is blindly trusting third party code for example blindly trusting jwt libraries to be secure and what end up happening was that many jwt libraries just foolishly implemented the jwt rfc specs which allow insanity such as valid tokens without jwt signiture. The problem isn't just blindly trusting third party libraries though, as seen with what happened with jwt, blindly trusting industry standards like rfc is also foolish like blindly trusting Oauth as well.
Hence the issue with learning Frameworks at the same time as learning JavaScript. Programmers should understand the basic foundation of programming to be considered a senior, especially a master.
AS a solo developer making small sas projects I find vanilla JS is best for me.I hate depending on 3rd party libraries, I already depend on the language itself.The benefit of frameworks comes with double disadvantages, what happens when react is no longer maintained and there's a new kid on the block, you move everything? I hate when people say "you don't need to understand what happens behind the scenes" of course you do , are you a real programmer or a dork
Once again shadow dom, Custom elements (lit-element is a good class) redux for state, just use simple libraries to get what you need. React is trying to rewrite all the functionality that is now part of every modern browser at the cost of downloading tons of extra script! Do a cost assessment of a simple todo list in react and one using custom elements. and you will see a drastic size difference between the bundles.
Who remembers the good old days when we didn't dump all the business logic into a much slower client side language and make a much slower client device re-render the page on every load? Javascript has become the new Flash, and as soon as we reign it in the better.
Of course it's possible! How do you think frameworks are coded? They are just a bloated layer on top of Vanilla JS. Pretending frameworks are magically "quicker" than Vanilla JS makes no sense!
No React is a framework. You have to build your project around it. You can't add or remove it from an existing project. JQuery is a library, you can add or remove it, you can use it only for the thing you need, it doesn't control how you build your project.
