So we now have React/Webpack + Redux + Apollo + GraphQL + Node + Pogstgres where once we had Rails/PHP/Django + Postgres. Someone hit me over the head because I don't get how all this is progress. There's no way I can teach web development to a beginner if there are so many layers between request and response.
Rails/PHP/Django embody the MVC paradigm, where in reality it's just model and controller, and very little view.
React+Redux is bringing view to another level, and node is there just so you can render server-side the same things you render in the browser. When I saying bringing to another level, I don't just mean it's more feature-rich, I mean it's more maintainable, testable, and it's a paradigm designed to scale the team working on it by reducing complexity.
Back to the MVC comparison, Apollo+GraphQL bring the same concept of evolution to the API (controller maybe?). In the MVC world you learn how to build one API, not how to keep it working, maintain and upgrade it for years. GraphQL is a solution to that, Apollo (as said in other comments) is just a tiny layer.
Finally, the model in the MVC to me is just an academic abstraction, I've seen 0 large-scale deployments using joins and integrity constrains.
So yes, before it was MVC, with different implementations in different languages, now people are looking into JS because it's supported in the browser and moving towards more scalable architectures, both in terms of infrastructure and team.
If you're making a 4 page brochure website, you can use react or rails. A beginner can handle that. If you're making a full web application where the user interface had good UX and is performant with non-trivial user interface logic and also there is non-trivial backend logic and eventually you would like to release mobile apps, I don't think you should expect to be able to teach a beginner all of that. But using react+express (I prefer feathersjs, but you can sustitute rails or any other backend) will be the shortest path to the more complicated scenario I mentioned.
Your comment is based on a grossly misleading presentation of the comparison though. React is a powerful view layer with an ecosystem around it. Rails is a full framework. You've misrepresented rails as simple and easy to learn by using only one term to describe it, and misrepresented the alternative to rails by separating it's components into named parts to scare us into thinking "Wow, 7 things? That's way more complicated than 2 things!" The reverse misrepresentation would be "So we now have react + postgre, but you're still using rails router + rails templates + rails graphql + rails rest + rails ORM + rails http client + jQuery + jQuery UI + gem + Ruby + macbookpro. How can you manage to train anyone on so many complicated tools?"
Why is this progress? Rails has it's limits in terms of full potential (complicsted backend + complicated UI + fast path to cross platform apps). You can add react to rails and reach the full potential. You can also do less than the full potential without react. React has some alternatives growing to also give you full potential, some not even in JS. It's 100% progress all across the board.
I don't really understand this criticism. If your web app is simple/static enough, then by all means use Rails. Everything will be simpler. But there are an entire class of applications that can't be built with that stack.
That's a very bold statement: "can't be built with that stack".
A large portion of apps aren't built with Node or React, they're built with, say, Rails, Java/Spring or .NET backends and a front end framework like Angular.
I get the theory behind React, the reality is that it is often a complete mess.
Since when was Rails limited to "simple/static" sites? I see the opposite all over the place these days - React + entourage for the most basic dynamic sites.
I totally agree! We keep adding more layers to the web stack. Even Django and Rails themselves were added complexity!
I've actually built a solution to this problem called Statebus: https://stateb.us
It takes a unique approach to the problem — instead of building more layers in the web stack, it builds support for change directly into HTTP itself! It turns out that if HTTP supports changing pages, and keeping things synchronized, you don't need web frameworks at all anymore.
Check out the jobs. React + entourage is all over the place. If I'm teaching a beginner who wants to enter the job market he's going to have to learn the whole stack.
Only if the beginner wants to get into richer client-side applications, which is only part of the whole web application market. And GraphQL is rare.
There are plenty of 100% server-side jobs. Maybe you should be pointing those out to beginners instead of suggesting that they need to learn even niche tech like GraphQL before having a shot in the job market.
if it helps, Apollo has Redux built into it so you don't need a store. With this I reduced the size of my small app quite significantly by removing reducers, actions and the store files.
I've been using React + Apollo + GraphQL on the frontend and Graph.cool as a BaaS which has been great so far.... admittedly I'm a beginner (starting from my experience as a Java developer 7 years ago)
