React is a library, when do you consider a library “learned”? If they already knew JavaScript why couldn’t they “learn” React in two days?
I’ve been using Python regularly for a decade and I’m continuously using new libraries and learning new things, I can’t think of when I would have considered Python “learned”.
React, Vue, Solid, … are a lot more complex than your average JavaScript library, because they contain so many abstractions and basically require a separate “way of thinking” in addition to what you know from JS itself. There’s a separate state and UI model, hooks are a foreign concept at first, and component memoization and re-rendering takes some getting used to as well.
Now, I only have two years of experience with React, but ten in JavaScript overall, and I will say that using React/JSX required the biggest “mental model shift” for me. That’s not to say that it’s difficult to work with or particularly hard to learn, but it takes time to understand and really internalize this language-within-a-language library.
The way you’re asking that question seems to imply that because the API of some Python libraries can be learned in two days, the same must be possible for React, and that seems rather dismissive.
There are plenty of Python libraries that are similar complexity to React, and not just for web development. Huge frameworks aren’t unique to JS, but depending on your background you can totally “learn” how to use them in two days, at least at a base level while you google how to do everything else (but let’s be honest, we’re doing that ten years in too lol).
But my point was more that gatekeeping “learning” a new tool isn’t really a conversation you can win, because when do you actually consider it “learned”?
How do you know what is similar in complexity to React? As far as I can tell you aren’t familiar with it.
at least at a base level while you google how to do everything else
Ah, there’s the problem. Your definition of learning doesn’t include having an appropriate mental model, which is key to actually retaining and internalizing the way it works. I don’t think it’s unreasonable to say that is a prerequisite for claiming to have “learned” something like a language or framework.
This post got the issue exactly. To use either React or Vue, the first thing you (should) learn from them is about the render mechanisms, which are introduced under the concept of component lifecycles, which only exist because both render things using a Virtual DOM. This is NOT hard, not even close, but it’s also non-trivial and it’s not immediately learnable with just hands-on code experience. It’s also boring to go through it first, so “first thing” has a ton of quotation marks most of the ways you learn it. It’s the kind of stuff that explains why the code is the way it is, and it makes sense of the thing, but can be new and weird.
I think a better way to relate to the issue is to ask people to recall how they learned git, specially those who tried to learn by doing. I’ve known SVN before I learned git, so when I had to sit down and actually understand it, some of the concepts were transferrable. But I’ve seen many, many people try to learn it and completely fumble to understand what the hell they were doing until they were presented with some visual representation such as https://user-images.githubusercontent.com/1256329/117236177-33599100-adf6-11eb-967c-5ef7898b55dc.png A diagram such as that is basically a shorthand to learning the mechanics of git, a sense-maker.
Because anyone worth their salt knows that the superficial hello world example covers the tip of the iceberg. So to say you learned it in two days means you either don’t get that you barely scratched the surface or you dont get what other developers really need when they hire someone with knowledge in a specific framework.
You mean print “hello world”; doesn’t work in JavaScript? Well whatever, I bought the book I can put it on my resume right?
I’m saying that the work they would be doing in two days isn’t the same as solving an actual problem. The way to really learn a language/framework/library is to actually use it in a real project. You run into pitfalls, you get compile errors and have to figure out how to debug in said tech, you find out how extentions to the tech work so you can create your own. Making a Todo Front End isn’t going to cover the vast majority of the stuff I’d expect one to know or experience when you say you “know” a language/framework/library/etc.
“Learned” means you can make code for production that other people won’t go “wtf are they doing, this isn’t how react works”
That’s just how we look at eachothers’ code, and even our own code that we forgot we wrote lol.
Whenever I have to dredge up an old project to make a change or just to check something, I’m hit with the temptation to rewrite the entire thing. I’m constantly learning, and I subscribe to the notion that there are endless ways to do something and none of them are right. Hell, I’ve brought 3 fairly large Vue projects to term and all of them were done the “right way” at the time, but completely differently. There’s what, 3 different approaches in Typescript for components?
Like programming languages, it depends on the context. “Learned” in a casual conversation would mean that one can write programs/libraries and achieve what they want in that language. “Learned” in a more professional manner, like a resume, would mean you can write good, maintainable code and know much of the language underlying stuff and other tools. But practically, in my experience, on a job, knowing a language/library means being better than or equal to your boss if they’re a dev.
The boss of my father, for example, is gonna challenge you with his knowledge until you agree you’re wrong, if you claim you “know” something. To him, “knowing” would mean you read the docs, source code and used it for many years, so actually know all quirks known to mankind of that language/library. Which isn’t really humanly possible.
Learned of
I can use react to build something, but fuck is it inefficient. Still learning though, as i’m just creating my first frontend and it’s for a hobby project anyway, so performance doesn’t matter.
One day to learn how to make stuff in React, one day to learn the degree to which the React developers despise you.
To be fair it took me couple of days to learn the basics of react. But I had years of programming experience, including other frontend frameworks like angular, angularjs, knockoutjs etc.
Eh, lots of stuff can be easy to learn, difficult to master.
Most languages only take a few minutes to do a “hello world” app.
When you announce you’re comfortable with something, it probably depends on the scale of the apps you’re used to working on.
So a junior dev could very well feel they’ve learned something like react after two days of cramming.
