Hi, Harvey! I get that each of the things you can learn probably feels like a whole new thing, each equally difficult and painful, but let me propose as an alternative, that you can see them as slightly different takes on the same thing. As a metaphor, each (fiction) book you read has a whole new story and whole new characters, but the core part of translating the characters into words and making sense of them is the same, and the part where there's a story is the same, and they all have characters, who probably have some sort of conflict. So the next book isn't the same as the first book, you don't have to learn to read again, you aren't experiencing a plot for the first time. Same thing here, they're all JavaScript at the end of the day (though some of them, JSX, for example, have some fancy ways that they display that JavaScript). If they're web view frameworks, they all have some way to turn the JavaScript into a DOM, probably via HTLM. They all have some way to respond to events and cause the DOM to update. So while the details change, and even the language changes, it's never as big as that first language, or that first framework. And as you learn more of them, you're exposed to more variations and more ideas, so the number of ways that any future one can vary become smaller and smaller. At some point, you've seen so many of them, that you can sort of go into a new one, study an example for a minute or two, and see how it's the same as what you already know and the handful of ways that it differs -- the parts that make it interesting.
One thing that will make this easier is if you understand the two sides very thoroughly. On the one side, you have JavaScript, on the other, you have the browser and its DOM. It's worth investing time to become comfortable in these things, because all the frameworks are translations between the two, when you understand them, then the ways that anything can translate between them get fewer and fewer. Another metaphor: You wrote a blog, I read it and am replying. We both understand English, and there's only so many ways that we can communicate these ideas back and forth. A letter, a book, mail, email, an oral conversation. If someone introduces you to Twitter, you can understand that it's just another way to communicate with the constraint that a given communication is limited to 140 characters. Pretty simple to comprehend, and exploring that constraint leads to interesting insights. Same thing here, you can write HTML that represents the DOM, you can write code that emits HTML that represents the DOM, you can write JavaScript that uses the browser API's to build the DOM, you can write another language like Elm, which can be compiled into JavaScript to create the DOM, you can use React which gives your JavaScript HTML-like syntax to create JavaScript that represents the DOM, but only updates it based on a diff of the current DOM and the new DOM.
As far as how to go about learning these two sides deeply, I've gotten a ton of mileage by writing my own small versions of things. Try writing your own minimal jQuery, your own minimal React or Vue, try writing your own small barely-featured JavaScript interpreter (use an existing parser), these are projects you can do in a weekend (on a good weekend), but that will yield a massive simplification of how you think about and understand things. If you eventually work your way to one of these, then try writing it a second time when you're done to solidify the idea and so you can be shocked by how far you've come!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi, Harvey! I get that each of the things you can learn probably feels like a whole new thing, each equally difficult and painful, but let me propose as an alternative, that you can see them as slightly different takes on the same thing. As a metaphor, each (fiction) book you read has a whole new story and whole new characters, but the core part of translating the characters into words and making sense of them is the same, and the part where there's a story is the same, and they all have characters, who probably have some sort of conflict. So the next book isn't the same as the first book, you don't have to learn to read again, you aren't experiencing a plot for the first time. Same thing here, they're all JavaScript at the end of the day (though some of them, JSX, for example, have some fancy ways that they display that JavaScript). If they're web view frameworks, they all have some way to turn the JavaScript into a DOM, probably via HTLM. They all have some way to respond to events and cause the DOM to update. So while the details change, and even the language changes, it's never as big as that first language, or that first framework. And as you learn more of them, you're exposed to more variations and more ideas, so the number of ways that any future one can vary become smaller and smaller. At some point, you've seen so many of them, that you can sort of go into a new one, study an example for a minute or two, and see how it's the same as what you already know and the handful of ways that it differs -- the parts that make it interesting.
One thing that will make this easier is if you understand the two sides very thoroughly. On the one side, you have JavaScript, on the other, you have the browser and its DOM. It's worth investing time to become comfortable in these things, because all the frameworks are translations between the two, when you understand them, then the ways that anything can translate between them get fewer and fewer. Another metaphor: You wrote a blog, I read it and am replying. We both understand English, and there's only so many ways that we can communicate these ideas back and forth. A letter, a book, mail, email, an oral conversation. If someone introduces you to Twitter, you can understand that it's just another way to communicate with the constraint that a given communication is limited to 140 characters. Pretty simple to comprehend, and exploring that constraint leads to interesting insights. Same thing here, you can write HTML that represents the DOM, you can write code that emits HTML that represents the DOM, you can write JavaScript that uses the browser API's to build the DOM, you can write another language like Elm, which can be compiled into JavaScript to create the DOM, you can use React which gives your JavaScript HTML-like syntax to create JavaScript that represents the DOM, but only updates it based on a diff of the current DOM and the new DOM.
As far as how to go about learning these two sides deeply, I've gotten a ton of mileage by writing my own small versions of things. Try writing your own minimal jQuery, your own minimal React or Vue, try writing your own small barely-featured JavaScript interpreter (use an existing parser), these are projects you can do in a weekend (on a good weekend), but that will yield a massive simplification of how you think about and understand things. If you eventually work your way to one of these, then try writing it a second time when you're done to solidify the idea and so you can be shocked by how far you've come!