Isn't React just a small[1] library that essentially does only one single thing? (And does it well) Takes a component definition, a state object, and then renders (and maintains) the component as a DOM structure?

Unless I was looking into some other React that everyone's talking about, or I've had my eyes looking somewhere else and missed something giant - I'm sure it is. Then, how come everyone's doing everything with what's just an evolution of the templating libraries? I mean, even a simplest CRUD front-end webapp isn't only about the UI.

Not trolling, I really don't get it.

____

[1] Well, technically it's not really small, because it does not of stuff under the hood to implement those virtual DOM and make things efficient. But it's end-user (=web developer who isn't hacking on React internals) functionality isn't wide-scoped. It's a library after all, not Angular or another we-do-it-all framework.

Say you're just doing a single page application, with some basic logic. You can just use React on its own to create components, as you don't need an entire state life-cycle. We do this a lot to 'enhance' our statically generated sites.

Or completely on the other end of the spectrum, you can use Redux, isomorphic rendering with Nodejs for example, react-router, and you can create a complete, dynamic site, with state, storage, authentication, whatever you need.

Then you have everything in between.

So you really can use React "for everything" in my view, and that's partly why I love it so much.

I don't think React is just an "evolution of template libraries", I think React is a concept, I know React didn't invent this concept of 'components', far from it, but I think it brought about the most clear-cut, concise way of creating web components, largely thanks to React's use of JSX, I think. When you team that up with Webpack (which you totally should btw), you can house all of that components dependencies in the same directory, and call them within the component, a truly modular approach.

(I promise you I don't secretly work for Facebook, I just love React).

Not trying to argue here, but don't you think for a simple static SPA, using React and creating components is too much overhead ? Why not just create the good-ol' html pages with css and js ?

I always take into account something I call as a effort-to-gain ratio. i.e.- If I have to give a certain amount of effort, I need to see proportional gain. I just don't see a proportional gain with using React in static SPAs.

But I get your point too. At a certain point when you are too familiar with a certain style of development, its hard to let it go.

Yes, that's the good part about it. Don't get me wrong, I'm very pleased with React for what it does. However, I only see it as a piece that does one certain thing (UI components), but still needs a lot of other pieces to make a whole.

I've actually first used it exactly this way - to just animate what previously was a static server-processed <form>. Much less work, compared to what I'd have to do if I'd wanted to use some large framework (and bend to its way of doing all things). Still, I was quite confused, as React got marketed as a sort of panacea, and when I started to actually learn what it does, I found out it's essentially just an UI library and I need other pieces for my project.

> I think React is a concept

Aha! I see your point then.

To me it's different. I see React just as glorified and fancy templating system evolution that can update the rendered object DOM in a smart way (rather than how it's with, e.g., Mustache where you have to discard the whole tree and place a new one over), properly preserving the DOM nodes and their internal states.

It really looks like an evolution to me:

- First, we had, e.g. Mustache (and myriad of others). They had one global template-wide state and rendered to a monolithic string without nodes.

- Then came Backbone (and then Angular) that had layered states. A monolith broken to pieces. Not yet atoms, though.

- Then came React and every node had its internal state, nicely propagated through the tree. To me it seems like a logical evolution. I'm not saying it's any trivial or an obvious step (it must've required a lot of effort to come with a nice implementation that React is), but not something ground-breaking either.

Then there's Redux that does some FRP state transformations. But to me it's not React, as it doesn't even really depend on it (although very few use it otherwise, and even those who do probably do so only as proof-of-concept "hey, look, I can use it with [e.g.] Vue!").

Then there's, say, Immutable.js that does data structures that play nicely with FRP. Or, say, various communication libraries (ranging from jQuery.ajax and whatwg-fetch to Restful.js or Socket.IO). To me, such things are certainly not part of React. That's why I was surprised at "React" doing "everything".

Guess, it's just a terminology issue then. Seems that many just call everything "React"...

I mean, stuff like persistence layer (communications with some sort of storage), data model and front-end form validation, etc. I don't think React or Redux provide those.