Search posts, tags, users, and pages
Wow. A lot of hatred towards front-end frameworks in this thread!
I'll try and keep it light and to the point.
Using a library like React enables you to onboard new developers a lot easier. If they've done React somewhere else, the likelihood is that they can do React at your workplace too. You also have a large community of developers with a lot of documentation out there. Check out the React and Redux docs. They're pretty well done! There's also some very nice tutorials like the ones that can be found on egghead.io
I should preface my next statements by saying that I predominantly use React at work, so the majority of my answers will be focused towards that.
To respond to some of the points made in this thread:
Or you could call a Vanilla JS fetch() and call it a day, or library like axios or Api. It is really sad that you need to include whole, huge jQuery just to do fetch.
A lot of libraries these days are moving to a modular way of doing things. You don't have to import the entire library. Compilers like Babel will just grab the bits that you need and leave the rest. Lodash is a perfect example of this implementation.
No, it doesn't make DOM/state management easier and more efficient. What is YOUR personal, honest life experience or do you just follow the hype, fake news and articles without doing any research? DOM is NOT slow and you DON'T need any new jargon like "state management" to deal with data, stop believing all that marketing bs online. Can you give me a real use case example and I will give you a simple JS code which will solve the problem.
A lot of anger here, but I'll address it. No, the DOM is not slow, but it's not as feature ready as it could (and arguable should) be. If HTML were capable of doing the things that React can do, people wouldn't use React. Unfortunately, it can't. At the moment.
Once you're up to speed with something like React and Redux, it makes DOM manipulation more predictable. I could of course use HTML attributes to achieve the same result, or even use methods like .innerHTML(), but that can get a bit messy. How does your app know that the change has been made? You could argue that it doesn't NEED to know, and that's true in smaller applications, but in a lot of the work that I do it is very much a necessity. If you know of a way to handle state management in a lighter, faster way than Redux then my dev team and I would love to know.
If JavaScript or HTML is missing something community really needs today, you make change in JavaScript/HTML standard itself
I agree. The problem is that changes for these standards are slow because the impact it could have is vast. A library can implement new functionality in a matter of months. Some decisions can take the W3C and ECMA Committee much longer than that to implement.
they don't understand accessibility or user experience
May I ask why you think that using a JavaScript library would affect accessibility or user experience? Do you mean in the case that they could have JS turned off?
May I ask why you think that using a JavaScript library would affect accessibility or user experience? Do you mean in the case that they could have JS turned off?
That's one of the many reasons. Scripting blocked isn't just a thing people do, there's the issue that for a lot of users scripting simply doesn't APPLY to how they use a page. That's why a page that cannot at least deliver its content without client-side scripting is an instant WCAG violation.... and depending on who the site is for -- such as banking, public utilities, healthcare, and government agencies -- those failings can land you with heavy fines and civil court cases.
That's why CSR is halfwitted garbage for the vast majority of websites -- you're flipping the bird at people with accessibility needs AND those who flat you just don't trust JavaScript. There's a reason Ghostery, NoScript, and so forth are popular!
But there's more. All this massive scripting is often a massive waste of CPU power, therefor killing battery life. So many of these frameworks actively encourage directly writing innerHTML style instead of leveraging the DOM causing even more pointless CPU use, doubling down on the memory footprint, and creating lag since that's getting the parser involved...
See the whole "pageloads are evil" whackjob paranoia that's been hot and trendy for around a decade. "Oh it takes too long with a normal pageload to reload and draw" -- Maybe if people weren't wasting megabytes of code in hundreds of separate files to do four to five doezn k of code's job, actually bothering to practice separation of presentation from content they wouldn't have these problems.
I'm sick to death of coming across (and cleaning up for clients) websites using AJAX'd in nonsense wasting megabytes of scripting, ten to twenty times the markup needed, half a megabyte or more of CSS to deliver 5k of plaintext and a half dozen content images! THEN they wonder why they're in court.
A situation exacerbated by these frameworks -- HTML and CSS ones in particular though it creeps into damned near everything now -- ACTIVELY promoting bad practices; like non-semantic markup (again screwing over accessibility), presentational use of classes, using JavaScript to do HTML and CSS' damned job...
Take the mentally enfeebled train wreck of developer ineptitude that is bootcrap -- where to be brutally frank if you don't know what's wrong with this:
<nav class="navbar navbar-expand-md navbar-dark fixed-top bg-dark">
<a class="navbar-brand" href="#">Site Title</a>
<button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarsExampleDefault" aria-controls="navbarsExampleDefault" aria-expanded="false" aria-label="Toggle navigation">
<span class="navbar-toggler-icon"></span>
</button>
<div class="collapse navbar-collapse" id="navbarsExampleDefault">
<ul class="navbar-nav mr-auto">
<li class="nav-item active">
<a class="nav-link" href="#">Home <span class="sr-only">(current)</span></a>
</li>
... do the world a favor, back the F* away from the keyboard, and go take up something a bit less detail oriented like macramé! Gah, the use of classes and div for nothing there is truly terrifying -- living up to the George Carlin joke "Not every ejaculation deserves a name!"
Lifted straight from their Jumbotron example, it clearly illustrates that the people working on bootstrap do NOT know enough HTML or CSS to be telling ANYONE how to build a huffing website! It even relies on this fat bloated JavaScript train-wreck for the mobile hamburger menu with multiple span to do what can be done in CSS WITHOUT JavaScript! Where's their H1? You know, the STRUCTURAL heading that EVERYTHING on EVERY page of the site is a subsection of? Oh wait, they have an anchor with no semantic block level container for that -- can hear them now: HTML structural rules? Say what now?!?
... and bootcrap is one of the BETTER ones, don't even get me STARTED about idiocy like w3.css; though I guess I shouldn't be shocked to see outright HTML 3.2 thinking from the dirtbag scam artists at W3fools. If you don't know what's wrong with class="w3-red w3-border w3-large" you must really miss HTML 3.2 and font/center/align/border... aka crap that has ZERO DAMNED BUSINESS IN YOUR HTML IN THE FIRST BLOODY PLACE!!!
Just like the stupid malfing STYLE tag that has zero malfing business on ANY modern website, the STYLE attribute that should only be used when the style is helping convey meaning and otherwise should be avoided at all costs, and people derping in their external stylesheets without a media target or saying media="all" -- COMPLETELY MISSING THE POINT OF HTML AND CSS!
MAYBE, just maybe, if people STOPPED slopping presentation into the markup, STOPPED slapping classes on everything and leveraged semantic markup and selectors, STOPPED using frameworks that are three times larger by themselves than the total code that should even be used to deliver the bloody content, they wouldn't have these problems!
But no, people HAVE to now convince themselves that writing 100k of markup to do 10k's damned job is somehow magically "easier". Or that using a megabyte of JavaScript on pages that don't even warrant it's presence is "easier". Or that ANY of this GARBAGE somehow magically makes them "more productive" despite every single fact proving the exact opposite!
The people using these dimwitted frameworks by choice universally do not know enough HTML, CSS, or JavaScript to be even working in web technologies!
If they've done React somewhere else, the likelihood is that they can do React at your workplace too.
As opposed to HTML, CSS, and JavaScript? Straw man argument at best, nonsensical propaganda parroting at worst.
Once you're up to speed with something like React and Redux, it makes DOM manipulation more predictable.
If a person don't know what he/she is doing in a math/engineering field where you either have 100% correct answer or not and if he/she can't predict results, probably, software engineering job is not for that person. Would you ever move your butt on a plane if you would know that a pilot doesn't know what exactly he is doing? I suppose you can understand that you wouldn't be able to land in that case and it would be a one way ticket into the heaven. 2 + 2 = 4. Period (I am not talking about higher math tricks). If you need a library to understand it, I am very sorry!
How does your app know that the change has been made?
If HTML were capable of doing the things that React can do, people wouldn't use React. Unfortunately, it can't. At the moment.
I am still waiting for a real use case example where you need to know the change, what exactly kind of change and how it will be used and where this HTML "unfortunately can't do something at the moment", but for now I still hear the same - blah blah React/Redux faster, blah blah DOM manipulation without React/Redux is unpredictable.
a page that cannot at least deliver its content without client-side scripting is an instant WCAG violation
That's simply not true. If the content rendered is non-compliant, sure. If it is, then how is it an instant WCAG violation?
From the React docs (reactjs.org/docs/accessibility.html):
React fully supports building accessible websites, often by using standard HTML techniques.
Please also see: w3.org/TR/UNDERSTANDING-WCAG20/conformance.html
React does nothing at all to stop you from building non-compliant apps, so please stop spreading your own "propaganda" that it does.
where to be brutally frank if you don't know what's wrong with this do the world a favor, back the F* away from the keyboard, and go take up something a bit less detail oriented like macramé!
Could you try not to take such an aggressive stance please? There are people who are new to Web Development who rely on Bootstrap while they're learning who might read your comments. The Web Development community can be a place of encouragement rather than one of elitist bigotry, please try to remember that.
Just like the stupid malfing STYLE tag that has zero malfing business on ANY modern website
I didn't mention the style attribute at any point. What relevance does it have to my response?
MAYBE, just maybe, if people STOPPED slopping presentation into the markup, STOPPED slapping classes on everything and leveraged semantic markup and selectors
Again. No mention of mixing presentation and markup in my response either. Also, why are you mentioning Bootstrap when OP asked about React and Angular?
Or that using a megabyte of JavaScript on pages that don't even warrant it's presence is "easier"
We have a winner. Something I agree with you on.
Does every website need to have JavaScript? No.
Do you need React to build Bob the Builder's portfolio site that has no interactivity whatsoever? You most certainly do not. Should you use it anyway? Probably not. You can do the same job just as easily using HTML and CSS. Probably faster too!
Can you build enterprise level dashboards and data visualisations without JavaScript? Good lord. Maybe? I think I'd be laughed out of the office if I suggested that at tomorrow's stand up though.
It basically boils down to using the best tool for the job. You wouldn't use a sledgehammer to put a thumbtack into your cork board. For a start, it's slower and takes more effort. If you need to hammer a few bolts into concrete well then he's definitely your man for the job.
100k of markup to do 10k's damned job is somehow magically "easier".
Where on earth are you getting those numbers from?
The people using these dimwitted frameworks by choice universally do not know enough HTML, CSS, or JavaScript to be even working in web technologies!
Unnecessarily rude and offensive. They may not have the same HTML, CSS and JavaScript chops that you do, but those skills can be taught. The same cannot be said for soft skills.
One last question for you:
Have you ever built anything with React? I only ask because I'd like to know whether your thoughts come from your own experience, or are you performing your own "nonsensical propaganda parroting?"
If a person don't know what he/she is doing in a math/engineering field where you either have 100% correct answer or not and if he/she can't predict results, probably, software engineering job is not for that person. Would you ever move your butt on a plane if you would know that a pilot doesn't know what exactly he is doing? I suppose you can understand that you wouldn't be able to land in that case and it would be a one way ticket into the heaven. 2 + 2 = 4. Period (I am not talking about higher math tricks). If you need a library to understand it, I am very sorry!
The thing is, it's not just one "pilot." There could be up to fifty of you with your own individual controls. How do you know what DOM manipulation colleague #5 has made? How about colleague #17? Colleague #39? You could make your changes and hope for the best that it doesn't conflict with another member of your team. Or you could dispatch it to your state management and have your components render conditionally based on the changes made. It's a one stop shop to be able to tell exactly what the app is "thinking." I can only assume that you haven't worked on anything large enough to warrant using state management, or something that would provide you with the ability to build a component library like React does. I don't mean this as a criticism, but if it's true then please stop. You are spreading false and damaging information because you haven't found a use case for React or Angular that warrants that sort of library being used.
I am still waiting for a real use case example where you need to know the change, what exactly kind of change and how it will be used and where this HTML "unfortunately can't do something at the moment", but for now I still hear the same - blah blah React/Redux faster, blah blah DOM manipulation without React/Redux is unpredictable.
First of all, please try not to be rude. Second of all, I will provide you with an example:
You are building a list out of raw data (let's say 15,000 or so results) returned to you from an API. You need to paginate the data with 100 results per page and provide search and filter functionality. If the user changes page, or changes any of the filters or the search terms, these changes must persist, even if they move to another part of the site and come back. How do you ensure that your user's changes and the snapshot of data (i.e the 100 or so results for that page) are maintained?
Also, please tell me how I would construct this functionality using HTML.
I guess there is no point to continue this conversation because you hadn't learned mathematical culture, discipline and respect at school. You also have huge problems in organized team work and don't know who is doing what and have 50 people digging same hole in the same time what is physically impossible anyways. I am sorry but no framework or any external tool will ever change that garbage state in your/ your team's mind. Organize yourself.
The only change is possible within, don't seek it outside - unknown
You usually divide tasks in bigger teams to make sure you wouldn't need to solve many git conflicts, you also have a proper software architect responsible for assembling anything into one single piece perfectly like large ships are built as a parts in another parts of the world and than perfectly fitting together at the end. (P.S. 15.000 results is extremely small number and server NEVER will return you 15k records in one API call lol...)
Thank you for your example. I already have DataTable component in ONLY 6kb. ABSOLUTELY NO React or anything else used, nothing but VANILLA JS. I use replaceState() and if you want to use browser back/forward buttons to work with those states as well, you can replace it with pushState(), however as per many conversations and per UX we changed it to replaceState() long time ago. In any case whenever user changes filters, they all are reflected immediately in the URL and if you manually will manipulate URL, you will have same effect. It's called History Web API you can learn about and this is exactly how Angular and all other garbage is doing so.
Myth busted. Good bye.
You are spreading false and damaging information
So we all can now agree that the only one who is spreading here false myths is YOU.
RTFM.
/closed
Goodness me! What a horribly rude person you are. Nevertheless, I will respond with respect and civility which you unfortunately cannot find it within you to extend towards me.
You also have huge problems in organized team work and don't know who is doing what and have 50 people digging same hole in the same time what is physically impossible anyways.
We are very organised as a dev team thank you, but sometimes changes overlap, especially when product can't make up their mind exactly what they want because the client has changed their mind about something. I'm sorry we don't all live and work in your perfect world where everything runs smoothly and nothing changes or goes wrong, but some of us live here, in the real world, where things undoubtedly can and will.
(P.S. 15.000 results is extremely small number and server NEVER will return you 15k records in one API call lol...)
It was an example for the sake of brevity. Please try not to be pedantic.
Attention community, here is a busted myth. Vanilla JS 1 - React 0
Hold your horses there. What's this?
however as per many conversations and per UX we changed it to replaceState() long time ago
You mean to say that you're using something to manage the state of your application. A state management tool if you will?
DOM is NOT slow and you DON'T need any new jargon like "state management"
You're using state management yourself. I never said that it HAD to be Redux, I never said it HAD to be a JavaScript library. Sure, you can use VanillaJS to achieve the same result. I said that state management made DOM manipulations more predictable. You've done nothing more than prove my point.
Myth busted. Good bye.
Not really, no. My argument to you was that state management was a helpful tool for predicting DOM manipulation. I never once said that you couldn't do the same with Vanilla JS.
If you're scoring the discussion we just had, you've just proved my point so...
My argument for state management 1 - 0 Your argument against state management
and via an own goal nonetheless.
RTFM.
Really? Could you try to be a little bit more professional in your responses?
If it is, then how is it an instant WCAG violation? Did you read much less comprehend my post? I was specifically referring to client-side script based rendering, something that means client-side scripting off there is NO content! THAT is INSTANTLY non-compliance and a violation. Which means IF you have to meet WCAG or similar norms such as under the UK's EQA or US ADA, hello Mr. prosecutor!
React does nothing at all to stop you from building non-compliant apps
Interesting then I've NEVER seen it done. "Supports" it is interesting when nobody using any of that stuff seems to bother DOING IT.
Or is this another of those theoreticals like "Oh if you only use the code editor part of Dreamweaver and ignore everything else" that STILL doesn't result in sites that are worth a flying purple fish?
I spend most of my time working for clients ripping garbage like frameworks out IN ORDER to make them meet WCAG and other contractual/accessibility minimums.
NOT THAT I would take seriously any page talking about "accessibility" that starts prattling on about HTML 5's pointless new "structural" tags or brings thetrain wreck of stupidity that is ARIA roles into it; given most blind people can't afford to drop a years income on updating to the latest JAWS and it provides ZERO functionality we couldn't get in HTML 4 if people just learned how to use numbered headings properly!
But of course when the very first tutorial page for react uses examples of scripting only use of the outmoded onevent attributes, slopping scripting only elements into the markup -- is it any wonder nobody using react seems to bother using good practices. THEIR HUFFING TUTORIAL PAGE -- to me at least -- reeks of developer ignorance and ineptitude! EVERYTHING I've ever seen done with it matches that "high standard" of "how not to build a website".
Show me something built with it that isn't crap! Bet you can't!
Could you try not to take such an aggressive stance please? There are people who are new to Web Development who rely on Bootstrap while they're learning who might read your comments.
What, you want me to slap the rose coloured glasses on their head and blow smoke up their arse? MAYBE if a beginner reads this they'll STOP using the idiotic dumbass GARBAGE of these frameworks and SHOCK bother learning the underlying technology instead.
This soft, limp, *wah, wah, somebodies s teh usin's sum hursh wurds" mollycoddling is how the propaganda used by these TRAIN WRECKS of how NOT to build a website are propagated. It's time to fight back against bad practices and making up lame excuses mated to soft language isn't the answer!
If anything it's how you create an environment in which the two bit scammers thrive... from every last dirtbag at the various template whorehouses, to every barker proclaiming Turdpress' greatness, to the people blindly parroting praises about frameworks when they simple do not know enough about the underlying languages to even have a valid opinion of if said frameworks are any damned good in the first place!
I'm SICK OF THIS BULL, ENOUGH!!!*
The Web Development community can be a place of encouragement rather than one of elitist bigotry, please try to remember that.
Like encouraging NOT to use bad practices, to NOT write ten times the code they need to, actually tryintg to make things simpler, easier, and more useful to as many users as possible? NO, you just sound like all the apolists who insist we have to all plaster on a disingenuous smile no matter how much manure is being shovelled by every two bit snake oil peddler!
I didn't mention the style attribute at any point. What relevance does it have to my response?
What part of the word 'like' do you not understand, it is a simile regarding incompetence of the most basic of HTML and CSS concepts. I started laundry listing all the readily apparant and commonplace signs of developer ineptitude so common to people who seem to chose to use frameworks by choice.
Also, why are you mentioning Bootstrap when OP asked about React and Angular?
Well... not to stand around quoting myself but...
What part of the word 'like' do you not understand comprehension, try it!
Much less see how this is a reply to YOUR post, and you SAID
Wow. A lot of hatred towards front-end frameworks in this thread!
Pretty sure bootcrap qualifies as a front-end framework, and it is the POSTER CHILD for everything WRONG with web development today. The sheer idiocy and stupidity of seems to trickle down into damned near everything else in the development process.
I keep bringing these thing up because the ignorance of accessibility norms, the most basic of semantic markup and structural concepts, and any of the underlying languages seem to be part and parcel of everything I've EVER seen churned out with frameworks.
... and if I do keep bringing up bootcrap it's because it is the front end framework I'm most familiar with the stupidity of; and I didn't feel like going back to research herpa-freaking-derpitude like:
<button className="square" onClick={() => this.props.onClick()}>
For those of you who don't know, given the context of the example that's a class for NOTHING. If that's done SSR you're putting a scripting only element in the markup -- something of a no-no. If that's CSR you're either doing that OR worse you're using innerHTML style methodology meaning you fail to leverage the DOM properly. EITHER way you're using the outdated outmoded and blocked by the CSP onevent attribute onclick, that should have gone the way of the dodo twenty years ago.
yes, I know you can turn off the blocking of event attributes in your CSP headers... too bad turning off what CSP does by default DEFEATS THE POINT OF USING IT!!!
Seriously, onclick, onmouseover, and so forth in HTML should have been stricken from the specification a decade ago. JUST like the STYLE tag, JUST like how EMBED should NEVER have been allowed into the language, JUST like how HTML 5 recreated redundancies 4 Strict was trying to get rid of... If you're using those attributes in your markup you might as well go back to writing that HTML 3.2 you so clearly miss.
Can you build enterprise level dashboards and data visualisations without JavaScript? Good lord. Maybe? I think I'd be laughed out of the office if I suggested that at tomorrow's stand up though.
Whilst we likely have a different definition of "enterprise level" (since that's the point I'd be putting down the web technologies and going for "Real" programming language) Even so you might be surprised what you can do without JavaScript. I mean if you're using HTML+CSS to render output why not provide that graceful degradation as your baseline render? THEN enchance it with JavaScript.
Since neither Mev or myself are saying "don't use JavaScript" -- we're just saying don't be stupid about it. We're saying have a fallback plan client-side if you're working on a WEBSITE.
I've seen far, FAR too many projects where people have started out with the scripting before they even thought about the render or semantics, and the result being a bloated inefficient hard to maintain mess. In that context I suspect their overthought solution to data handling is a contributor towards the diving for the frameworks.
I've also listened to far, FAR too many USERS complain about how certain sites and applications suck without being able to articulate why; but when I poke my head under the bonnet the "why" is redily apparent: FRAMEWORKS!
But most of that is when dealing with web applets, not websites... and, well... you touched upon the real issue:
It basically boils down to using the best tool for the job. You wouldn't use a sledgehammer to put a thumbtack into your cork board.
... and therin lies the problem. People are diving for these things for the simplest of tasks that don't warrant their use; then they show up on development forums asking why their result is slow, or how to make it do somethign the framework wasn't designed to let you do easily, or something that neuters their upgrade path when new framework versions come along, or something that in general due to what they are trying to actually accomplish needs to be pitched in the trash and started over from scratch.
That last part being far, FAR too often the case, and it's the last thing anyone wants to hear about their project. -
Where on earth are you getting those numbers from? re: 100k of markup doing 10k's job
Damned near every site I come across that uses these technologies? I actually have a formula for determining how large the markup for a website should be based upon practical norms and good practices.
2048 + content plaintext 1.5 + anchors 128 + media elements * 256
Media elements being things like object/video/audio. If the HTML exceeds those limits, in all likelihood it is utter and complete bloated garbage written by people who have ZERO business writing a single line of HTML.
Again why HTML/CSS frameworks are universally trash belting out two to twenty times that figure. Same for garbage like BEM or this dumbass practice being promoted right now of "every element needs a class"... Even more of a joke when said markup bloat is sold as being "faster" by scams like Google PageSpeed because of some vague claims about render time of child selectors. Because of course using twenty times the classes needed and ten times the markup is "faster" and "easier".
Like this clown I saw the other day who had slopped together off the shelf solutions in complete ignorance resulting in 7.9k of CLASSES on the BODY tag, then waltzed into a forum unable to comprehend why it had a two minute page-load cache-empty on a proper modern broadband connection.
Unnecessarily rude and offensive.
The truth is never unneccessary -- and if you found that rude just be glad I posted the watered down version. If it offends, then it is time for a bit of self reflection as in my experience that truly is the truth of the matter; as evidenced by EVERY system I've ever dealt with built with web frameworks. It has made the past twenty years -- half my programming career -- amount to little more than running around with the pooper scooper and a plastic bag.
They may not have the same HTML, CSS and JavaScript chops that you do, but those skills can be taught.
Then WHY THE BLAZES AREN'T THEY?!? No, seriously, it is the only explanation I can have for choosing one of these frameworks, such a gross lack of understanding ANY of the underlying technologies they are utterly incapable of even knowing if their framework of choice is even doing anything good -- much less anything that should even be done in the first place!
The same cannot be said for soft skills.
Care to explain what those are in something more than a glittering generality?
Have you ever built anything with React? I only ask because I'd like to know whether your thoughts come from your own experience, or are you performing your own "nonsensical propaganda parroting?"
My first attempt at learning react was abortive at best. EVERY single thing in EVERY tutorial was the opposite of how I even THINK about using web technoloigies. The constant bad practices, outmoded concepts, and stuff that should have gone the way of the dodo twenty years ago ALONE made me reject it at the start.
I then ended up being brought into a project where a double entry accounting project was going from a standalone app to having an online component. They had decided to use node.js and react JUST because the suits at the top had read about it in Forbes or some other such source. As I often say, getting tech advice from Forbes is like getting financial advice from Popular Mechanics.
The project was three months deep with fifteen developers, and I was brought in because the front end wasn't passing QA... that's being polite about it. It was a train wreck of ineptitude only matched by the back-end code. A multi-megabyte monstrousity spanning hundreds of files doing what I could have done (and did end up doing) in PHP+HTML+CSS+JS without any stupid framework garbage in less than 200k of code in five files, only around 80k of that in three files going client side... which with the help of one other person took two days to hammer out getting it to talk to their Oracle database and sending/recieving ACH data properly. (since it was integrating to a separate accounts system that talked direct to banks)
Since that time my bread and butter has been going into places and ripping out all this framework crap to fix these types of woes. In forty years of programming I haven't seen practices THIS stupid and painful since the days of programmers intentionally padding their code with unneccessary comments becuase they were getting paid by the K-LoC.
Laughably my first "professional" software went through interpreted code on mainframes (mostly Algol, COMAL, and DiBol) and stripped out the comments, resulting in freeing up disk space AND often doubling or more the performance since it had become so rampant (and ridiculous) a practice. Minification by any other name...
EVERY time now I'm brought in to a client to fix their accessibility problems (what I do) these garbage frameworks are at least partly to blame for the problem; be it the bad practices they promote through their bad tutorials and worse methodologies, or that the people duped into using them didn't know enough about the underlying technologies to realize how badly they'd been saddled up and taken for a ride!
NOT that such issues are really a shock when the majority of people pissing out markup right now can't even be bothered to use H1..H6 properly. The frameworks only excacerbate an already disastrous situation by preying upon ignorance!
Bottom line EVERY one of my experiences with "frameworks" when it comes to web technologies of the past TWO DECADES has been negative. There's like this magical line from when things go from being a 'library of helpful functions' to being a 'framework' that once crossed, pisses on good practices, sane and rational development, and actively encourages people to NOT learn the underlying tech.
... again meaning the folks using these 'frameworks' end up unqualified to even know if what they are using is any good or not!
Really? Could you try to be a little bit more professional in your responses?
Honestly if that's your reaction to Mev's "RTFM" I wonder just what type of slick double-talking two-faced disingenuous used car salesmen you're used to dealing with "professionally". Probably a wonderful mix of soft-spoken "laissez faire" types who sleaze by on as little effort as possible then wonder why they're on their sixth employer in three months, mated to the circus show barkers who will tell you whatever it is you want to hear so long as they can either sell you something, or use/abuse you for all you're worth whilst paying you peanuts.
Never trust a hug, It's just a way to hide your face.
A LOT of developers are getting sick of this "don't ever say anything negative" BULL, as ALL it does is give the dirtbag scam artists their foot in the door. It is becoming frustrating beyond belief watching perfectly good projects flushed down the toilet by mismanagement, incompetence, and ignorance -- and framworks on the whole contribute to this.
There's nothing more aggravating than a suit who knows dick about programming telling you to use six different frameworks they don't even understand, mated to junior developers who "only know the framework" and are incapable of even thinking in any other terms besides "Oh I just Google it and ^C^V"... meaning they don't actually know how to solve any problem.
As such a bit of venting of that frustration should be expected. MORE so when the BS is propped up by the seven classic propaganda techniques and zero real quantifiable benefits... which is why often dealing with framework fanboys ends up more akin to arguing reality with a cultist.
I think a lot of your opinion stems from some very bad experiences and I'm sorry that you've had to deal with that. I'd feel similarly disenfranchised if I'd had to experience a similar set of circumstances. It looks like we agree on a lot of stuff, but I still disagree with your stance that a tool is inherently bad just because people have used it badly. It only serves as an indicator that people need to evaluate their use cases a little better and decide on frameworks accordingly, especially when it comes to CSS frameworks like Bootstrap.
However, OP asked about JS frameworks like React and Angular and my point still stands. If you're building a cut and dry website which boils down to three pages('Home', 'Contact' and 'About'), then no, React is not your answer. Write yourself some good semantic HTML and style it up with CSS. Put some Vanilla JS on there if you need any extra functionality. If you're building something that has a larger scale, and could potentially scale upwards, React could help you out. That's the sort of thing that it was created for.
With regards to saying negative things about frameworks: by all means, please do. It breeds constructive criticism and fosters ingenuity. However, you can catch more flies with honey than with vinegar. Proclaiming that frameworks are bad and slamming anyone who uses them because your experiences with them have been bad isn't a conducive way to communicate your feelings or to bring people on board to your way of thinking.
My reaction to Mev-Rael's comment 'RTFM' was because I would expect someone who has authored a fairly well used JS library to recognise their own impact and influence on the community and use a little more tact than what amounts to "Read the fucking manual."
I think a lot of your opinion stems from some very bad experiences
There's more to it than that though, in that my GOOD experiences with GOOD practices leaves me sitting there looking at even just the simple tutorials for things like react and vue, and thinking "these guys don't know enough HTML or JavaScript to be making a system people will be using to make HTML and work with JavaScript!".
Scripting only elements generated on the markup, innerHTML style methodology with zero concern for XSS vulnerability or performance issues, the onevent attributes we've been told for a decade to stop using for similar reasons, pointless extra wrappers, endless pointless idiotic "classes for nothing" or worse "presentational classes".
THEN when you start pointing out this clear lack of HTML knowledge you get the jokers who say "what's HTML got to do with a front-end JavaScript framework?" (same thing with PHP frameworks) -- What are you then outputting and manipulating with that framework then?!? Marzipan and kittens?
When the people writing the official tutorials CLEARLY don't know enough HTML, CSS, or JavaScript to be telling people how to do any of them, how in the blazes are we supposed to trust that the clowns working on the frameworks are any better?
Clowns to the left of me, Jokers to the right, here I am... stuck in the middle with GNU.
A situation only further clouded by the handful of times anyone tries to include a head to head comparison of vanilla vs. the framework; where their idea of vanilla JavaScript is utter and completely incompetent trash. One can only conclude in these conditions that they are either intentionally sabotaging the vanilla code to manipulate the opinion of beginners, OR that they don't know enough vanilla code to even be writing about the framework, much less actually writing the framework itself! It ends up looking like either intentional card stacking (to go with their glittering generalities, testimonial, plain folks, transfer, bandwagon, etc) or outright incompetence!
... and lately I've been shifting towards Hanlon's razor as the easiest explanation.
to recognise their own impact and influence on the community and use a little more tact
Thing is those of us reacting so vehemently have tried that, for over a decade now. It doesn't work. Sometimes you need to start applying boots to asses PARTICULARLY where "stupid' is concerned.
You drag everyone down to the drum circle led by the rainbow farting unicorns to sing Kumbaya, that's where the snake oil doctors get to peddle shoving jade eggs up steamed clams, tumeric cure-alls, halfwitted fairy tales about a magical man in the sky, a 6000 year old universe, a flat earth, or that making rich people richer is going to help the poor.
Nice has been tried, it doesn't work. Sometimes you need a little negative reinforcement instead of handing everyone a participation trophy.
Well... I'm always going to disagree with you on the idea that nice has been tried and it doesn't work, but maybe I'm a sucker for it. I can't help myself, and I don't think that will ever change. Where you see stupid, I see the potential to teach and to educate. It's a part of the web community that I love and cherish and I don't think that will ever change :)
I'm curious as to what you would propose as a solution for a large scale application like the one that we build at my workplace. For us, React has been an invaluable solution and there are reasons why it was chosen. For reference, we're building large scale, enterprise level network analysis software with admin dashboards containing large amounts of data visualisation. A lot of the parts of the app need to know what other parts of the app are doing at all times. How would you go about solving a problem as large as ours without using any library or framework? Do you still maintain that Vanilla JS is the most viable solution? If yes, why? If no, what tools would you use instead?