In this article we will explore top fundamental Javascript concepts necessary to know in order to have an effective first learning cycle of React /...
For further actions, you may consider blocking this person and/or reporting abuse
I would strongly suggest building a website without using a framework/library first, so you can understand what problem they are actually solving and gain an understanding of what goes on 'under the hood'. I've interviewed wayyyyyy too many developers who can throw something together in React, but are totally clueless when I ask them to do some basic stuff in vanilla JS. This problem is steadily getting worse and worse.
I have to respectfully disagree with this recommendation.
I concur it’s valuable for devs to understand the basics of JS, but these frameworks exist specifically to accelerate development. Unless I’m hiring engineers to build a framework, I don’t need them to be experts in all the nuances that come with interfacing directly with browsers.
Thanks for the valuable suggestion !
I agree. Building an application with plain HTML, CSS and adding some interactivity with JS should be part of any curriculum before learning React. I would also throw in the usage of a template engine to fully appreciate the power of React.
Thanks for this. You have exposed an area I can exploit as a noob dev.
hi, nice post, but you could highlight js code more specifically to get colorful examples (read the editor doc).
It's always the same problem. Many aspiring devs think they know the language while they don't. They may use progress bars to describe their progression, but you can't master "80% of js" if you don't know how to achieve very common programs without using a framework and tons of add-ons.
The list you provided is great, and these are only basics of js.
Thank you !
@theaccordance I have to respectfully rebuff you here. Your statements are incorrect.
So is repeatedly calling a library a framework a tactic you use to weed out the fakers and posers? I mean, as an expert, you know we're talking about a library right? I think someone who understands computing enough to claim expertise should know the difference between these fundamental concepts.
I'm very curious to see how your way of doing things would be able to define a select element with values, handling a change event that mutates global document state in fewer lines than these:
This the point @natescode is making: It's impossible to implement the above in React without injecting hundreds of lines of boiler plate into your project and a layer of complexity that is mostly not required.
Even if we discount the technical debt maintaining your boilerplate code adds to your workload, this is your codebase:
Only the red outlined box in the middle represents actual project code... And even then, only a sliver on the far right hand side of the box... Most of
app
is polyfills because you used some CRA template and nobody knows how to Babel properly... If you had access to an expert instead of a bunch of React monkeys, maybe you could fix it...Point is, that if you were paid based upon how many lines of code you have to maintain, then you and your React monkeys would be making it rain compared to those silly novices who work with plain old JS.
I agree you have valid points, but I see one major flaw in your rebuttal:
We're clearly not building apps at the same scale here. You view all the overhead as a burden, whereas I have tangible savings in labor and code we maintain.
Yeah - your simple example proves your point, but my enterprise applications? They tell a different story.
Thanks. Um, destructuring, please; not destructing 🤣.
😂😂 I have corrected it ,,,,,thanks for mentioning,,,
The point is correct, it is very important to strengthen the basics before learning anything, and these frameworks can't be learned in 2 days, we need to practice for many days, with that we need to make the basics strong, then we can do well. Thanks for the comment
Awesome for begginers
Thank you !
Greatt Post, its help and understant the overview thank you jack
This was very helpful, thanks!
Awesome! A lot of these are used a lot in React so knowing these beforehand will definitely improves the experience of a beginner reading some React code without getting overwhelmed
Thank you !
I agree that it is important to understand basic array methods before jumping into React. Unless React is required in school or on the job I suggest skipping it altogether because in my opinion React is way too much overkill. Plain Vanilla JS is the way to go for simple apps. Nice to understand some of the React basics though.
I wrote a Dev.to piece on 17 reasons why I prefer Plain JS over React. U can read it here at
dev.to/rickdelpo1/react-vs-plain-j...
Thanks this is great ☺️👍
Awesomee! 💯💯
Thank you !
Sensational article 😮
Nice article
Thank you !
I think it’s good to learn at least two frameworks. ReactJS will fade away in years to come. It’s very bloated and you have to write more code to get things done. Web development should be simple not adding complexity. Svelte is a much better option then ReactJS and much faster.
This whole thread is “not getting the point”, so I’ll be a little clearer about considerations your point isn’t mentioning: the impact of infinite scrolling on the DOM tree, efficiency with the DOM, Shadow DOM, virtual scrolling, matching UI state to canonical URLs, having to track different navigation stacks across different tabs within your own UI (PWAs), maintaining scrolling position when navigating to a prior state, or backwards compatibility with old browsers to name just a few. Delivering a fluid UI on par with what people expect with native apps involves many nuances with the browser, many of which are not easily understood or mastered by the majority of web engineers today. That’s where frameworks show their value.
But hey, like I said, you’re probably not authoring complex apps or working with teams at the same scale I have, so you probably haven’t experienced when someone in your engineering org tries to be smart with plain JS instead of RTFM and you end up with compounding tech debt by time the pain is discovered. Pain is a good educator.
Congrats on your 1 million lines of code, it’s a lot! Perhaps you’ll relate more to my perspective when after you author 10 million lines of code. Im gonna set this thread to ignore going forward, have yourself a splendid day.
Who said they need to be experts? I did.
Bold statement, I know, but it’s a statement derived from over a decade building teams, products, and teaching students how to code. It comes from experiences working on projects before and after frameworks became popular, and watching too many engineers think they were being creative with plain JS instead of RTFM with the framework. Those engineers never stick around long enough to see how poorly their solutions age.
You’ve got your way of doing things, but it sounds like it involves maintaining way more code than myself or my teams do. If only we were paid by the number of lines we authored in a project…
I think he was referring to:
which you specifically said they didn't need to be, rather than being experts in React.
You forgot TypeScript. React is unusable without TypeScript... unless you hate yourself...
I don't think they need to be experts.
It's very useful to know the build of basic framework. Building a framework from scratch is extremely useful. Those are the same principles used when optimizing framework code. Despite their power, abstractions have become crutches for lazy developers who aren't engineers.
💯