Your first point actually hits on my biggest problem with these frameworks.

I don't particularly like anything that is used "to make things easy."

In my experience 'making things easy' is the CLAIM parroted endlessly about these frameworks, that is NOT in any way supported by the actual task or result. They make MORE work, not less. They are something MORE to maintain, MORE to learn, and result in MORE code with MORE complexity.

Whilst this is much more true for the asshat trash that are HTML/CSS frameworks, it most certainly seems to be the case for JavaScript ones -- and even many PHP ones -- as well.

I cannot grasp how starting out with more code than you should have in total before you even write a blasted thing, to then write as much if not more code than you'd have without the framework, all whilst having bad practices and broken methodologies shoved in your face is "easier".

Just doesn't make a lick of sense to me.

Sulu: They say she has transwarp drive

Scotty: Aye, and if my other had wheels she'd be a wagon.

Jason Knight

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.

Jason Knight

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?

I could just do an long xhr request in Vanilla JS, or I could use a single line $.get() in jQuery and call it a day.

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.

I could create my own templating system, or I could lean on things like Handlebars or even Vue components.

Or you could contribute to this specific Web Standards proposal, but overall, yes, Handlebars/Vue is simple and does the job, however this proposal's some implementations already will give you same result faster for much less resources. The question was about "framework like Angular/React", not about rambda, handlebars.

And don't get me started on frameworks like A-Frame that make VR child's play for any developer, rather than forcing them to delve deep into WebGL.

JavaScript and Web APIs were made for a typical scenario, not game development. This question, again, was asked from a "frameworks like Angular/React" perspective which are for this typical scenario and DOM manipulation, not canvas or WebGL or WebAssembly.

At the end of the day, it's not impossible to complete projects without React, but it makes certain tasks easier or more efficient -- like state and DOM management.

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, but I guess, you like everyone else for last years when I asked same question will just chicken out from this conversation without defending their holy garbage called React.

@oscarthegrouch My question was specific to frameworks like 'Angular', 'React' and 'Vue'. Using JQuery and other libraries certainly help in making code shorter. I'm currently learning Angular and building a small application that involves only three components. It took me a whole lot of time and code to make them communicate with each other. I could be wrong but I don't see any advantage in using them.

Few people have mentioned that they enable you to onboard new developers a lot easier. But aren't these things secondary? Are these frameworks making my application's performance better in any way?

I'm still a novice and there's certainly a lot left to learn but so far the only thing I've experienced is that in the name of modularity they're just making small tasks more complicated.

kartik chauhan I think much of this is because you're new at using these frameworks. Of course there is an initial learning curve which will appear to be slowing you down, but someone who has been using Angular for years can slap something together much quicker.

I don't think any frameworks are known for their performance... If you want to get into that then you develop using C, C++, maybe Rust, or even some modules in assembly language.

I wouldn't even say that frameworks are known for security either but you have to keep in mind that they may actually improve performance and security when you have a bunch of novice developers who would otherwise overlook aspects that the framework has taken care of for them. Again, is this the best process for the developers' individual education? probably not. But it all comes down to the requirements and resources of the project.

Matt Strom :D lol

That does not introduce similiar code that a framework like Vue would use.

could you define this? ;D This is basically everything that could handle state and transfer it to a layout? or is it the way it's handled? :D to me due to a lack of precision (maybe on purpose) it's impossible.

Although in my head I have several solution prototypes. for example just creating own dom elements and collections using a classic event dispatch system for propagation.

you could create a tree structure that is component based where the html node is inside of the tress structure and hooked up.

you could try to use declarative model using selectors persist the state in the html.

the tricky part could be string parser. but than again .... a lib can already be just one reusable file Gg ..... it's a trick question to me ;D .... a nice one though.

@j Ha, I had thought about clarifying that, but it seemed like a difficult task. The distinction really hinges on when vanilla JavaScript or a library become a framework, at least to the degree that people here object to.

I'll take a crack at it. "Code similar to Vue or other frameworks" begins, I'd say, when you:

• Introduce some form of bindings, such as Angular's *ngFor or Vue's v:for.
• Introduce the notion of data contexts. So for example, a DOM element bound with an *ngFor binding is situated within a data context containing an array of items to repeat. Data contexts are hierarchical and share a similar shape to the DOM trees annotated with bindings
• Introduce automatic change detection. Some mechanism that can detect inconsistencies between the data model and the DOM and re-renders the component tree when a change is detected. React does this with the virtual DOM, AngularJS with the digest cycle, Angular 2+ with observables and Zones, and Vue with its reactivity system.
• Introduce a templating system that is capable of injecting values other than string literals (so this excludes native HTML templates).

How's that list sound?

Let's consider what I presume is a familiar UI: the Gmail conversation selection checkboxes

Assuming the elements are already on the DOM as:

#selectSome -- the select filled with options

#messageListBody -- the TBODY of a table where there is a TD in each TR that contains an INPUT of type CHECKBOX... since that IS tabular data a table would in fact be the CORRECT semantics!

... and let's for brevety sake assume those input are the first child element.

// we'll be walking DOM rows since tbody has no seperate rows collection :(
function walkChildren(parentNode, callback) {
    var e = parentNode.firstElementChild;
    while (e) {
        callback(e);
        e = e.nextElementSibling;
    }
}

function hookSelectToChecks(selectId, tbodyId, cellIndex, selectCallback) {
// cellIndex is which column (starting at 0) that contains the checkboxes

    var
        selectSome = document.getElementById(selectId),
        messageListBody = document.getElementById(tbodyId);

    selectSome.addEventListener('change', function(e) {
        selectCallback(
            selectSome.options[selectSome.selectedOption].value,
            messageListBody
        );
    }, false);

    walkChildren(messageListBody, function(tr) {
        tr.cells[cellIndex].firstElementChild.addEventListener(
            'change', function(e) {
                if (!e.currentTarget.selected) selectSome.selectedIndex = -1;
            }, false
        );
    });

}

// use 'new' so that locals are preserved for each call
new hookSelectToChecks(
    'selectSome', 'messageListBody', 0,
    function(selectValue, messageListBody) {
        switch (selectValue) {
            case 'all':
                walkChildren(messageListBody, function(tr) {
                    tr.cells[0].firstElementChild.selected = true;
                });
                break;
            // for fun, let's implement another
            case 'none':
                walkChildren(messageListBody, function(tr) {
                    tr.cells[0].firstElementChild.selected = false;
                });
                break;
            /*
                Implement all the rest of your unique conditions here. Note since
                we're iterating the full list of TR from messageListBody you can
                easily pull other data about the posts like read, unread, starred,
                and so forth from the cells off the DOM 
            */
        }
    }
);

Farking DONE. Hooks an existing markup so that you have the possibility of scripting off graceful degradation, leverages the markup and the DOM to do most of your heavy lifting as it SHOULD BE, walks the DOM instead of creating collections reducing the overhead... with a reusable function that gets passed a callback for the one part that needs to be customizable depending on data type.

Not even two minutes worth of coding... untested, may have typos, but this is simple stuff people! Hook the two parents, attach your listeners, walk the DOM. In Soviet Russia, the DOM walks you

Kudos if you can also do so in a manner that is testable without the DOM.

If you aren't working with the DOM what the blue blazes are you doing working with client-side JavaScript?!? What is this paranoid nonsense about bothering to leverage the actual form elements on the page to track what's going on -- that's part of what they're huffing there for PARTICULARLY for your scripting off graceful degradation. (where the select shouldn't even be in the markup and should be added to the script, but the checkboxes for mass actions should remain!)

I've seen a LOT of react/view fans say that, not to use the DOM to track what the user is doing with the DOM... where does this even come from?!? I think that might be a significant part of why I don't understand the react/vue mentality... which to be frank probably should have "more emphasis" on the mental.

Good scripting should be enhancing ALREADY WORKING MARKUP! and LEVERAGE the DOM to do most of the real work and actual data tracking client side! Is that the fundemental difference in attitude that separates the haters from the fanbois?

... because to be frank -- when am I ever anything else? -- all this talk about bindings and "data contexts" and all the rest of the academic double-talk REEKS of overthinking solutions to simple problems... and flipping the bird at the entire purpose of web technologies (in particular accessibility and scripting off graceful degradation) in the bloody process!