[allover]

Stopped reading half-way through, as lots of incorrect stuff off the bat.

> In the react world though you can’t mutate your data

Sure you can.

> If you get 3 people react will end up re-rendering 3 times because of the code above. Each call to `setState` triggers a re-render.

Nope, calls to setState are batched.

[ryanbrunner]

I think sometimes you need an outsider view to call out that the emperor isn't wearing any clothes, and that's going to result in botched details. I don't think it impacts the overall point the author is trying to make.

I teach web development at a part-time course, and we recently redesigned our curriculum to use React + Node instead of Rails with JQuery. With the new technologies, the students are profoundly less productive or effective by the end of the course - they're doing well if they have the barest skeleton of a CRUD app up, whereas the Rails apps were all fleshed out and far more engaging.

There's something rotten with the state of development these days - we're dealing with far more complexity and being less productive for what's usually the same result.

[vim_wannabe]

One problem is people reach out to client-side code earlier than they should.

90% of websites have no need for Javascript. Of those that do 90% won't be needing any "take over the world" frameworks, just little sprinkles of Javascript or jQuery.

Not to mention most required uses of Javascript are interaction related. At least let me read the landing page without having me enable javascript instead of greeting me with a blank page.

[ryanbrunner]

I agree. I think 90% of the "problem" with React or Redux is that people espouse using "the right tool for the job", but almost never practice it when the right tool is unsexy.

[brightball]

Most of the problem, IMO, is that everybody seems to think that everything needs to be a SPA.

The reality is that 99% of web applications are "open, check, close" experiences which benefit very little, if at all, from a front-end framework of any kind.

The remaining applications that people actually keep open for long periods of time where the DOM needs to update over long periods of time are the only places where this approach really provides a huge benefit. Things like a chat system or actual web based software that people would be expected to keep working on throughout their day. For those types of application, React is a good fit.

The biggest issue is people jumping on this "we need a front-end framework" train when...you really don't for most things.

[andybak]

I'm a Django guy and I still feel that the ascent of Django and Rails was the high-point of productivity in web development.

I still advocate for "progressive enhancement" as a development philosophy but the javascript kids seem to have taken over the show and regard back-end code as there for nothing more than building an API.

For the vast majority of javascript use-cases Turbolinks/PJAX gives you most of the benefit of a client-side framework (which usually boils down to faster response times by avoiding full page loads with the advantage that you get to keep most of your logic in nice server-side languages with non-pathological ecosystems.

Also see http://intercoolerjs.org/ - which follows a similar philosophy.

[allover]

> but the javascript kids

> with non-pathological ecosystems.

That's just like, your opinion, man.

[mamp]

React + Redux has plenty of great principles behind it: functional approach to front-end dev, understanding the importance of one way data flow, components, immutable data stores etc. Also the separation of data from UI that allows rendering abstractions that result in React Native. There's a lot of material a good engineer should understand, and it's well thought out in React/Redux.

If you are trying to put up a few web pages quickly, then the learning curve is steep and it's probably overkill.

However, for complex single page apps with complex data that involve a team, then the payoff is huge. Especially with TypeScript (or other). The reliability, testability and extensibility of our complex applications is amazing compared to our previous attempts over the years.

[crispyambulance]

It makes me wonder what it is that actually makes a framework "take off".

Clearly it is not ease of use nor cogency of the code one needs to write, nor even how well the developer can express their intent.

I sometimes suspect that all this churn and complexity in the latest frameworks is some kind of unintentional group-think that optimizes for job-security by making work much more difficult than it really needs to be.

[franciscop]

Has the complexity mostly come from React or from Node? I'm doing a small Node library from a similar but casual teaching perspective (all those manual middleware should be there by default IMO) so I'm quite interested in leaning your Node.js pain points.

[ryanbrunner]

Node (well Express) is not a problem at all, save maybe authentication and database concepts (which are a slog no matter what language you're working with for new developers). I think Express is actually more suited in some ways for complete beginners than Rails is.

[littlecranky67]

Then why don't you stick with Rails and jQuery? Modern frameworks like react (or even SPA alltogether) evolved for certain types of web applications (read that again: web applications, not websites). If your web application has requirements like offline funtionality (think mobile appstore deployment), very nice UI (think animations) or responsive UI (in terms of response times to clicks, drags etc.), you would not get far with Rails, or end up with a mixed backend/frontend code soup for HTML rendering and DOM manipulation.

Another aspect is enterprise grade websites, where jQuery just does not scale as well or will make your code end up in an unmaintainable state. "Get beginners going fast" is a nice feature, but sometimes its more favorable to have "scales for teams with >10 developers".

If you are making a simple website, blog or whatever, please do not use SPA but stick with the server-side frameworks we had for years.

[mgkimsal]

> Then why don't you stick with Rails and jQuery?

They're teaching classes about web development and trying to react to the perceived market demands.

You're talking here about "if you're building X or Y, use ABC", but the class doesn't make that call, and they're trying to be attractive enough to students to choose them.

If I was a student, and was looking to "learn web development", and I search around for what I should learn to make myself attractive to employers... I'm very likely going to find unbounded recommendations for Angular, React and Node, almost without exception. Probably not even 'likely' - it really is what I see touted weekly in many groups that I'm a part of (user groups, online forums, etc).

The current situation for new folks trying to get in feels like a big echo chamber with bad recommendations reinforcing poor choices leading to more confused (and less productive) jr devs coming in to the field.

[ryanbrunner]

I agree that there's web applications that aren't going to be feasible with a server-generated HTML stack. Anyone trying to build Spotify or Google Docs without Javascript driving the show is in for a bad time. But 90% of the "applications" I use (read: not blogs but your average SaaS app) don't require that level of complexity.

[boubiyeah]

They're not always batched. They're only batched within the context of an Event listener. A fairly odd distinction made necessary because React rendering was made synchronous initially but I guess it works for most apps.

[andrewingram]

The fact that it's currently within the context of an event listener is probably the wrong way to think about it. The only sane and safe way to work with setState is to think of it as scheduling a change to be made at some point in the future, and that batching will occur if possible.

It's clear from the post that the author didn't learn how setState works, he's not aware of either batching or the callback form, which neatly address most issues related to setState.

I didn't pay much attention to the second half of the article, because I avoid heavy use of Redux anyway. Ultimately the author shouldn't have even been looking into Redux before understanding how React works, so presumably he's been misinformed somewhere along the way.

[VeejayRampay]

First thing that struck me as dishonest. The Facebook put a lot of thought in making sure all updates to the DOM are as scarce and optimized as possible, so naturally it batches them.