7 ms·

html, css, and jQuery work just about exactly the same as they did a decade ago, nothing stops you from using tools you already understand. If it was up to fac

html, css, and jQuery work just about exactly the same as they did a decade ago, nothing stops you from using tools you already understand. If it was up to facebook then react would be the only framework used on the web; problem solved right? In reality, there are different tools for different needs and if you don't understand the specific problems a tool was made to solve then of course you're going to find it confusing. Just because a tool exists doesn't mean you have to use it. These tools were created to solve specific problems that the creators encountered, if you don't have that problem or don't like the solution then why did you pick the tool? The most baffling part is the strange sense of entitlement as if people releasing their work for free on the internet is a burden to some because now they have to decide if they should use this free option. If you want ES6, typescript, flow, components, css modules, SSR, hot code reloading, "universal" code re-use, postcss, bundling, automatic-code splitting, dead code elimination blah blah blah then that's on YOU. Don't blame the tools because you are enticed by their capabilities but not willing to understand why and how they work. If you don't care about that stuff then problem solved: don't bother with them.

tonyedgecombe 9y ago
I do wonder how much of the problem is that most of the tools and libraries comes out of organisations like Facebook and Google who have completely different constraints to the majority of us. React might suit Facebook but it probably isn't a good solution for someone who's application only gets a few hundred hits a day.
- adventured 9y ago
  It's a complete bifurcation of the Web's technology underpinnings. That will keep getting more dramatic. Developers and their pay will bifurcate similarly more and more as time goes on. AWS has 150 services or so now. How many of those does a 12 employee small business need? None most likely. That business's site gets maybe 1,000 or 3,000 or 10,000 hits per month. It's an absurdity to throw all the new tools, libraries, cloud tech etc. at that. Most of the Web looks like that small site, most sites on the Web get very little traffic. So little that you could run it on a $5 Digital Ocean instance and have over 95% of the droplet's use capacity to spare. Does my insurance agent, who operates his own small business, need machine learning? No. And to the extent he does, it'll be built into the tools provided by various insurance carriers, entirely hidden from his daily business operation activities. So who actually needs all of these tools? You nailed it, it's almost entirely isolated to the 0.1% group, the Facebooks, et al.
  - victor106 9y ago
    “Does my insurance agent, who operates his own small business, need machine learning? No” If he has a fixed mindset you are right. But if he has a growth mindset and has the intellectual curiosity to learn what ML is and if he can apply it to his business and finds out that he could maybe he can increase his business 10 fold. Even if you take a stance that he is not interested in growing just the fact that living in this age and time gives him(or his kids) the option to learn/play with powerful tools at a click of a button is worth appreciating on so many levels
    - PeterisP 9y ago
      A major difference here is simple economies of scale. E.g. a particular technology feature might cost $100k to implement in your business and get you a 10% revenue increase. For a large business, doing so is a no-brainer; for a one-person business doing the same thing is clearly a waste of money and effort. And there are many things like that, causing the bifurcation between the needs and common practices in large companies vs small.
      - victor106 9y ago
        That’s exactly what today’s cloud technologies bring to any small business. You don’t have to invest $Y to know if you can increase profits by x%. You can invest $Y/10 (even less in some cases) to figure out if this works. If you zoom out and think about it for a second what most technology is doing today is making a small guy look big
  - graycat 9y ago
    > Does my insurance agent, who operates his own small business, need machine learning? I have a friend who has his own navy. It's a small navy. He does like boats. Once he had a men's yacht trip. There I met a guy and his son who ran an insurance agency. Well, AI or not, one of the keys to his insurance business success was his ability to separate good customers from risky ones. Basically he knew nearly everyone in town, or at least every one of his customers, down to what they ate for breakfast or some such. That knowledge helped him get a good loss ratio and made good bucks for his business. So, maybe what he did was not AI but real I!! I'm sure that if someone had an AI tool that would help his loss ratio, then he'd us it! For a second example, my father in law was on the local bank board. So, a guy in the community applied for a home loan. Well, at that bank, the loan application went to the BoD of the bank -- no joke. Then at the BoD meeting, everything about the applicant got exposed and discussed right down to the details of his lifestyle. So, again, if some AI application could help that bank make better loan decisions, then likely they'd use it. Lesson: That local insurance agent and that local bank both were really big on gathering, analyzing, and using all the data they could get. If AI could help, then they'd use it.
- ccachor 9y ago
  Regardless of hits, React is designed for UIs that need to "React". That's the motivation behind the library. It's better suited to social networking applications than it would be to say an eCommerce store or a dashboard CRUD web app. You can still use it of course, but you probably won't be getting any of the main benefits because there's not much interaction with VDOM.
saas_co_de 9y ago
> blah blah blah The real problem here is that all these comp sci "geniuses" want to make a name for themselves with a "real" project and so they create all these garbage tools (compilers, pre-processors, etc) that make things worse by introducing and encouraging more complexity when just using plain JS would work better. A lot of them are Java/C++ people with no experience in web development who see the simplicity of JS as a flaw and want to recreate the s--tshow they are used to working with because the complexity makes them feel smart and special. That is just human nature though. The same argument has been going on for decades between C and C++ people. Nothing new here.
- mratzloff 9y ago
  JavaScript static typing, promises, and modularization via imports are very useful—you just pay for them with a compile step. If you don't want those features, don't pay for them.
- wsy 9y ago
  As many people here already said, just stick with your simple JS. No need to complain about anything because plain JS still works exactly as it always did.
- Can_Not 9y ago
  > want to make a name for themselves with a "real" project I think the ones doing it to make a name for themselves rather than solve a real problem are a lot less common than you're making it out to be.
victor106 9y ago
“The most baffling part is the strange sense of entitlement as if people releasing their work for free on the internet is a burden to some because now they have to decide if they should use this free option.” Agree with this 100%. I keep hearing coworkers trash a particular open source project/framework with no understanding of what kind of problems it solves.
- dboreham 9y ago
  >I keep hearing coworkers trash a particular open source project/framework with no understanding of what kind of problems it solves. Also I often think: I keep hearing coworkers adopt particular open source project/framework with no understanding of what kind of problems it solves.
  - bonesss 9y ago
    For me it's "premature optimization is the root of all evil". Very often teams will use ages getting up on new frameworks to avoid a little hard programming, only to end up with hard programming wrapped in a huge framework they don't really grok and lots of incidental complexity. Wordpress or whatever will make an email widget easy to source, but if that's only 1% of your project, why impact the other 99% without considering its impact? It's so easy for intuitive maps of the "hard parts" to dictate insanity across the whole development process.
    - wsy 9y ago
      I agree, but the opposite also happens: teams start by implementing something small themselves because the framework is so 'huge'. Over time, they end up with a semi-huge custom framework because they run into the same issues and feature requests the 'huge' open-source framework ran a few years before them.
      - bonesss 9y ago
        That's a really good point. It's a spectrum of complexity over numerous components, inside the context of a greater development environment which also impacts decision making. As boring as it sounds this is why I force myself to estimate as close to "everything" as best I can early in the project... Not so much to use as an estimate, but to map out areas where my intuitive understanding is inadequate, and to give some rough data to drive decision making. Mapping out the pain points at least gives you a semi-objective breakdown of where the actual work lies, and to what degree that pain will be mitigated/exacerbated by major frameworks. DIY has its limits ;)
colllectorof 9y ago
>Just because a tool exists doesn't mean you have to use it. Most developers don't just grab their tools based on what they want to play with at the moment. Actual software engineering today involves working with other people and their code. Code reviews, integrations, maintenance, enhancements, technology overhauls, system decommissioning, working with vendors. The fact that this simple reality didn't even cross your mind tells me everything I need to know about your opinions on tooling.
- root_axis 9y ago
  > Most developers don't just grab their tools based on what they want to play with at the moment. Actual software engineering today involves working with other people and their code. Code reviews, integrations, maintenance, enhancements, technology overhauls, system decommissioning, working with vendors. And? What's that point you're making? If it's not your job to pick the tools then the point is moot because you'll work with whatever the technical leads decide, all you have to do is get to work.
lazyjones 9y ago
> html, css, and jQuery work just about exactly the same as they did a decade ago, nothing stops you from using tools you already understand. A decade ago, the requirements for supporting all/most clients (devices) were radically different. Different requirements mean different solutions and perhaps new tools must be used.
- striking 9y ago
  This isn't really true. jQuery's compatibility can stretch all the way back to IE8, up to the newest devices. If you require the web to be more than a document viewer, then you might in fact need some different tools; but HTML/CSS/jQuery didn't solve those if you're going back that far, Flash did. But HTML/CSS/jQuery still work to solve the problems they always did. And they're still used in production today. According to W3Techs, jQuery is still present in 96.2% of the sites they could determine a JavaScript framework for in the Alexa top 10M.[1] And the very popular CSS framework Bootstrap still has it as one of its dependencies.[2] "If it ain't broke, don't fix it." 1: https://w3techs.com/technologies/details/js-jquery/all/all https://w3techs.com/technologies/details/js-jquery/all/all 2: https://getbootstrap.com/docs/4.0/getting-started/introduction/#js https://getbootstrap.com/docs/4.0/getting-started/introducti...
  - lazyjones 9y ago
    > According to W3Techs, jQuery is still present in 96.2% of the sites they could determine a JavaScript framework for But that doesn't mean jquery was used exclusively on these sites. Look at any major website, in addition to some modern framework, they will often include jquery for just a few old hacks (I've seen popular sites include 3-5 different jquery versions on the same page).
    - marpstar 9y ago
      Also, WordPress includes it by default, but rarely are the site admins actually doing anything with jQuery.
    - tyingq 9y ago
AznHisoka 9y ago
ES6 is elasticsearch 6, right?
- striking 9y ago
  ECMAScript 6, an expansion to JavaScript. A concise feature list can be found here: http://es6-features.org http://es6-features.org
- deleted 9y ago
  [deleted]
- quiq 9y ago
  > ES6 is elasticsearch 6, right? It's EMCAScript [0], the spec of which JavaScript is an implementation. New features will come out in the spec, and it takes a bit for browser's JS engines to implement them. [0] https://en.m.wikipedia.org/wiki/ECMAScript https://en.m.wikipedia.org/wiki/ECMAScript
mitchdoogle 9y ago
Like the author pointed out, many of the new "solutions" are just the same old solutions in a new wrapper. There may be edge cases that the new solutions helps with that the old solution couldn't handle, but that begs the question, why didn't we just improve the old tool instead of making a brand new one? This leads to a lot of outside pressures that fall upon developers/companies who are trying to stay relevant in the field. When everyone around you is moving to "B", do you want to be the one that is still using "A" because it works just fine? Do you want to risk being irrelevant in a few years to prove your point? Naturally, many people don't want to take that risk, and so they go on learning the new technology even though it's not really necessary for 95% of developers, and they start using it in their new projects and they get comfortable with it and then the whole cycle starts again.
- root_axis 9y ago
  > Like the author pointed out, many of the new "solutions" are just the same old solutions in a new wrapper Nothing is new under the sun, something old becomes something new in a different context in a different time, same thing happens in music and fiction... so what? > There may be edge cases that the new solutions helps with that the old solution couldn't handle It's pretty condescending to reduce the work of many smart and passionate programmers down to "a bunch of edge cases". People put real work and thought into these projects based on their professional experiences and it's depressing to me that others can be so cynical that they're unwilling to imagine that maybe there's something they aren't seeing about why so many of their colleagues are excited about what these tools make possible. > but that begs the question, why didn't we just improve the old tool instead of making a brand new one? Setting aside the clearly obvious reasons why we don't (and can't, and often aren't welcome to) contribute to existing tools rather rather than roll our own - who is worthy enough to determine which projects deserve eternal tribute and which projects are allowed to even exist? Your question is absurd. Why don't all these hugely popular tools with active open source communities just disappear? Umm, why should they have to? Why don't all the people who have a problem with it disappear back to a world where they can manipulate individual DOM nodes to match their application state with imperative instructions... you know, the present world they live in right now? > This leads to a lot of outside pressures that fall upon developers/companies who are trying to stay relevant in the field I'm not understanding the complaint. "Pressure to stay relevant in the field" sounds a lot like "keeping up with advances in the field". I understand you don't agree that they are advances, but a lot of people disagree, including many individuals leading companies and organizations highly regarded for their engineering talent. > When everyone around you is moving to "B", do you want to be the one that is still using "A" because it works just fine? Do you want to risk being irrelevant in a few years to prove your point? If you're tasked with the responsibility of deciding which technologies are the most appropriate choices for a project and you decide to pick "B" because it's popular, rather than "A" because its a tool that you understand and claim is "just as good" as "B", YOU are to blame; by your own logic you're just giving yourself an intentional handicap so you can look cool. > Naturally, many people don't want to take that risk, and so they go on learning the new technology even though it's not really necessary for 95% of developers Who's to say what 95% of developers need? Some would say 95% of developers don't need javascript at all, so I guess that settles that.
OkGoDoIt 9y ago
Every job I've had in recent years has required I use an overcomplicated toolchain involving React or Angular. For personal projects I avoid them like the plague but unfortunately I don't have that luxury when working on a team at a company. Please, point me to any full stack web developer job listing that doesn't mention React or Angular!

tonyedgecombe 9y ago

I do wonder how much of the problem is that most of the tools and libraries comes out of organisations like Facebook and Google who have completely different constraints to the majority of us. React might suit Facebook but it probably isn't a good solution for someone who's application only gets a few hundred hits a day.

adventured 9y ago
It's a complete bifurcation of the Web's technology underpinnings. That will keep getting more dramatic. Developers and their pay will bifurcate similarly more and more as time goes on. AWS has 150 services or so now. How many of those does a 12 employee small business need? None most likely. That business's site gets maybe 1,000 or 3,000 or 10,000 hits per month. It's an absurdity to throw all the new tools, libraries, cloud tech etc. at that. Most of the Web looks like that small site, most sites on the Web get very little traffic. So little that you could run it on a $5 Digital Ocean instance and have over 95% of the droplet's use capacity to spare. Does my insurance agent, who operates his own small business, need machine learning? No. And to the extent he does, it'll be built into the tools provided by various insurance carriers, entirely hidden from his daily business operation activities. So who actually needs all of these tools? You nailed it, it's almost entirely isolated to the 0.1% group, the Facebooks, et al.
- victor106 9y ago
  “Does my insurance agent, who operates his own small business, need machine learning? No” If he has a fixed mindset you are right. But if he has a growth mindset and has the intellectual curiosity to learn what ML is and if he can apply it to his business and finds out that he could maybe he can increase his business 10 fold. Even if you take a stance that he is not interested in growing just the fact that living in this age and time gives him(or his kids) the option to learn/play with powerful tools at a click of a button is worth appreciating on so many levels
  - PeterisP 9y ago
    A major difference here is simple economies of scale. E.g. a particular technology feature might cost $100k to implement in your business and get you a 10% revenue increase. For a large business, doing so is a no-brainer; for a one-person business doing the same thing is clearly a waste of money and effort. And there are many things like that, causing the bifurcation between the needs and common practices in large companies vs small.
    - victor106 9y ago
      That’s exactly what today’s cloud technologies bring to any small business. You don’t have to invest $Y to know if you can increase profits by x%. You can invest $Y/10 (even less in some cases) to figure out if this works. If you zoom out and think about it for a second what most technology is doing today is making a small guy look big
- graycat 9y ago
  > Does my insurance agent, who operates his own small business, need machine learning? I have a friend who has his own navy. It's a small navy. He does like boats. Once he had a men's yacht trip. There I met a guy and his son who ran an insurance agency. Well, AI or not, one of the keys to his insurance business success was his ability to separate good customers from risky ones. Basically he knew nearly everyone in town, or at least every one of his customers, down to what they ate for breakfast or some such. That knowledge helped him get a good loss ratio and made good bucks for his business. So, maybe what he did was not AI but real I!! I'm sure that if someone had an AI tool that would help his loss ratio, then he'd us it! For a second example, my father in law was on the local bank board. So, a guy in the community applied for a home loan. Well, at that bank, the loan application went to the BoD of the bank -- no joke. Then at the BoD meeting, everything about the applicant got exposed and discussed right down to the details of his lifestyle. So, again, if some AI application could help that bank make better loan decisions, then likely they'd use it. Lesson: That local insurance agent and that local bank both were really big on gathering, analyzing, and using all the data they could get. If AI could help, then they'd use it.
ccachor 9y ago
Regardless of hits, React is designed for UIs that need to "React". That's the motivation behind the library. It's better suited to social networking applications than it would be to say an eCommerce store or a dashboard CRUD web app. You can still use it of course, but you probably won't be getting any of the main benefits because there's not much interaction with VDOM.

saas_co_de 9y ago

> blah blah blah The real problem here is that all these comp sci "geniuses" want to make a name for themselves with a "real" project and so they create all these garbage tools (compilers, pre-processors, etc) that make things worse by introducing and encouraging more complexity when just using plain JS would work better. A lot of them are Java/C++ people with no experience in web development who see the simplicity of JS as a flaw and want to recreate the s--tshow they are used to working with because the complexity makes them feel smart and special. That is just human nature though. The same argument has been going on for decades between C and C++ people. Nothing new here.

mratzloff 9y ago
JavaScript static typing, promises, and modularization via imports are very useful—you just pay for them with a compile step. If you don't want those features, don't pay for them.
wsy 9y ago
As many people here already said, just stick with your simple JS. No need to complain about anything because plain JS still works exactly as it always did.
Can_Not 9y ago
> want to make a name for themselves with a "real" project I think the ones doing it to make a name for themselves rather than solve a real problem are a lot less common than you're making it out to be.

victor106 9y ago

“The most baffling part is the strange sense of entitlement as if people releasing their work for free on the internet is a burden to some because now they have to decide if they should use this free option.” Agree with this 100%. I keep hearing coworkers trash a particular open source project/framework with no understanding of what kind of problems it solves.

dboreham 9y ago
>I keep hearing coworkers trash a particular open source project/framework with no understanding of what kind of problems it solves. Also I often think: I keep hearing coworkers adopt particular open source project/framework with no understanding of what kind of problems it solves.
- bonesss 9y ago
  For me it's "premature optimization is the root of all evil". Very often teams will use ages getting up on new frameworks to avoid a little hard programming, only to end up with hard programming wrapped in a huge framework they don't really grok and lots of incidental complexity. Wordpress or whatever will make an email widget easy to source, but if that's only 1% of your project, why impact the other 99% without considering its impact? It's so easy for intuitive maps of the "hard parts" to dictate insanity across the whole development process.
  - wsy 9y ago
    I agree, but the opposite also happens: teams start by implementing something small themselves because the framework is so 'huge'. Over time, they end up with a semi-huge custom framework because they run into the same issues and feature requests the 'huge' open-source framework ran a few years before them.
    - bonesss 9y ago
      That's a really good point. It's a spectrum of complexity over numerous components, inside the context of a greater development environment which also impacts decision making. As boring as it sounds this is why I force myself to estimate as close to "everything" as best I can early in the project... Not so much to use as an estimate, but to map out areas where my intuitive understanding is inadequate, and to give some rough data to drive decision making. Mapping out the pain points at least gives you a semi-objective breakdown of where the actual work lies, and to what degree that pain will be mitigated/exacerbated by major frameworks. DIY has its limits ;)

colllectorof 9y ago

>Just because a tool exists doesn't mean you have to use it. Most developers don't just grab their tools based on what they want to play with at the moment. Actual software engineering today involves working with other people and their code. Code reviews, integrations, maintenance, enhancements, technology overhauls, system decommissioning, working with vendors. The fact that this simple reality didn't even cross your mind tells me everything I need to know about your opinions on tooling.

root_axis 9y ago
> Most developers don't just grab their tools based on what they want to play with at the moment. Actual software engineering today involves working with other people and their code. Code reviews, integrations, maintenance, enhancements, technology overhauls, system decommissioning, working with vendors. And? What's that point you're making? If it's not your job to pick the tools then the point is moot because you'll work with whatever the technical leads decide, all you have to do is get to work.

lazyjones 9y ago

> html, css, and jQuery work just about exactly the same as they did a decade ago, nothing stops you from using tools you already understand. A decade ago, the requirements for supporting all/most clients (devices) were radically different. Different requirements mean different solutions and perhaps new tools must be used.

striking 9y ago
This isn't really true. jQuery's compatibility can stretch all the way back to IE8, up to the newest devices. If you require the web to be more than a document viewer, then you might in fact need some different tools; but HTML/CSS/jQuery didn't solve those if you're going back that far, Flash did. But HTML/CSS/jQuery still work to solve the problems they always did. And they're still used in production today. According to W3Techs, jQuery is still present in 96.2% of the sites they could determine a JavaScript framework for in the Alexa top 10M.[1] And the very popular CSS framework Bootstrap still has it as one of its dependencies.[2] "If it ain't broke, don't fix it." 1: https://w3techs.com/technologies/details/js-jquery/all/all https://w3techs.com/technologies/details/js-jquery/all/all 2: https://getbootstrap.com/docs/4.0/getting-started/introduction/#js https://getbootstrap.com/docs/4.0/getting-started/introducti...
- lazyjones 9y ago
  > According to W3Techs, jQuery is still present in 96.2% of the sites they could determine a JavaScript framework for But that doesn't mean jquery was used exclusively on these sites. Look at any major website, in addition to some modern framework, they will often include jquery for just a few old hacks (I've seen popular sites include 3-5 different jquery versions on the same page).
  - marpstar 9y ago
    Also, WordPress includes it by default, but rarely are the site admins actually doing anything with jQuery.
  - tyingq 9y ago

AznHisoka 9y ago

ES6 is elasticsearch 6, right?

striking 9y ago
ECMAScript 6, an expansion to JavaScript. A concise feature list can be found here: http://es6-features.org http://es6-features.org
deleted 9y ago
[deleted]
quiq 9y ago
> ES6 is elasticsearch 6, right? It's EMCAScript [0], the spec of which JavaScript is an implementation. New features will come out in the spec, and it takes a bit for browser's JS engines to implement them. [0] https://en.m.wikipedia.org/wiki/ECMAScript https://en.m.wikipedia.org/wiki/ECMAScript

mitchdoogle 9y ago

Like the author pointed out, many of the new "solutions" are just the same old solutions in a new wrapper. There may be edge cases that the new solutions helps with that the old solution couldn't handle, but that begs the question, why didn't we just improve the old tool instead of making a brand new one? This leads to a lot of outside pressures that fall upon developers/companies who are trying to stay relevant in the field. When everyone around you is moving to "B", do you want to be the one that is still using "A" because it works just fine? Do you want to risk being irrelevant in a few years to prove your point? Naturally, many people don't want to take that risk, and so they go on learning the new technology even though it's not really necessary for 95% of developers, and they start using it in their new projects and they get comfortable with it and then the whole cycle starts again.

root_axis 9y ago
> Like the author pointed out, many of the new "solutions" are just the same old solutions in a new wrapper Nothing is new under the sun, something old becomes something new in a different context in a different time, same thing happens in music and fiction... so what? > There may be edge cases that the new solutions helps with that the old solution couldn't handle It's pretty condescending to reduce the work of many smart and passionate programmers down to "a bunch of edge cases". People put real work and thought into these projects based on their professional experiences and it's depressing to me that others can be so cynical that they're unwilling to imagine that maybe there's something they aren't seeing about why so many of their colleagues are excited about what these tools make possible. > but that begs the question, why didn't we just improve the old tool instead of making a brand new one? Setting aside the clearly obvious reasons why we don't (and can't, and often aren't welcome to) contribute to existing tools rather rather than roll our own - who is worthy enough to determine which projects deserve eternal tribute and which projects are allowed to even exist? Your question is absurd. Why don't all these hugely popular tools with active open source communities just disappear? Umm, why should they have to? Why don't all the people who have a problem with it disappear back to a world where they can manipulate individual DOM nodes to match their application state with imperative instructions... you know, the present world they live in right now? > This leads to a lot of outside pressures that fall upon developers/companies who are trying to stay relevant in the field I'm not understanding the complaint. "Pressure to stay relevant in the field" sounds a lot like "keeping up with advances in the field". I understand you don't agree that they are advances, but a lot of people disagree, including many individuals leading companies and organizations highly regarded for their engineering talent. > When everyone around you is moving to "B", do you want to be the one that is still using "A" because it works just fine? Do you want to risk being irrelevant in a few years to prove your point? If you're tasked with the responsibility of deciding which technologies are the most appropriate choices for a project and you decide to pick "B" because it's popular, rather than "A" because its a tool that you understand and claim is "just as good" as "B", YOU are to blame; by your own logic you're just giving yourself an intentional handicap so you can look cool. > Naturally, many people don't want to take that risk, and so they go on learning the new technology even though it's not really necessary for 95% of developers Who's to say what 95% of developers need? Some would say 95% of developers don't need javascript at all, so I guess that settles that.

OkGoDoIt 9y ago

Every job I've had in recent years has required I use an overcomplicated toolchain involving React or Angular. For personal projects I avoid them like the plague but unfortunately I don't have that luxury when working on a team at a company. Please, point me to any full stack web developer job listing that doesn't mention React or Angular!