4 ms·

React may be an improvement on what came before, but it's still too complex for "draw a UI on the most-widely used platform." It's definitely not helping to de

React may be an improvement on what came before, but it's still too complex for "draw a UI on the most-widely used platform." It's definitely not helping to democratize programming the way that the personal computer did when it simplified the world of computers down to a BASIC interpreter that a child could understand. The "advancements" are necessary, but let's be honest - they are far from ideal, overcomplicated messes that exist solely to paper over the fact that the main software delivery platform is still just a hacked-up document viewer. They make professional programmers' lives easier, but the act of programming becomes generally less accessible with each iteration.

hombre_fatal 6y ago
Don't really buy this. React is a lot simpler than all of the other frameworks/APIs/SDKs I've used like Cocoa/UIKit that draw a UI on a client that only a fraction of people can use. You'd expect it to be simpler, not more complicated, if you get to target a Also, unlike iOS dev (for example), the web still has a trivial `echo "<div>hello world</div>" > index.html` you can use when you want it. I always wonder how many web-client dev critics have done much work building clients on other platforms. Spoiler: it never was simple nor easy. And people's favorite hey day examples only worked for a specific platform.
diffrinse 6y ago
Unclear why React has to service that need. jQuery still exists, is still supported and maintained, and serves that need much more effectively I wager. And taking a step back I think many people in frontend confuse React for a jQuery alternative, the thing you whip up a web project with by default, but it really isn't. That there is a component ecosystem might suggest its a jQuery alternative, but they really are for different scales of application programming. I think it's this idea most harmful about React adoption and to be fair React marketing hasn't exactly said otherwise. So we get web pages with massive JS deps cause most people are probably using React for a productive developer experience rather than a fitting use case that actually justifies resorting to a virtual DOM model for applying view state, and yet React sold itself on "we probably know better than you about efficient DOM updates". That's true if you have lots of Juniors hanging around.
- hajile 6y ago
  I think that depends on how you use react. When I first started using it to replace jQuery, it resulted in different use patterns than when making a greenfield SPA. I just wanted something easier to maintain and it did that in spades. React was an easy drop-in replacement. No state library or whatever else (there weren't a ton of libraries at that time). Just add React CDN, code up some simple components and add them to the page (they'd get a list of elements with the correct classname and inject one copy for each element). Today, I still take a similar approach for the occasional CRUD site I work with. The only change is that now I use the much smaller pReact and use functional components with hooks instead of the old React.createClass() from the early days.

hombre_fatal 6y ago

Don't really buy this. React is a lot simpler than all of the other frameworks/APIs/SDKs I've used like Cocoa/UIKit that draw a UI on a client that only a fraction of people can use. You'd expect it to be simpler, not more complicated, if you get to target a Also, unlike iOS dev (for example), the web still has a trivial `echo "<div>hello world</div>" > index.html` you can use when you want it. I always wonder how many web-client dev critics have done much work building clients on other platforms. Spoiler: it never was simple nor easy. And people's favorite hey day examples only worked for a specific platform.

diffrinse 6y ago

Unclear why React has to service that need. jQuery still exists, is still supported and maintained, and serves that need much more effectively I wager. And taking a step back I think many people in frontend confuse React for a jQuery alternative, the thing you whip up a web project with by default, but it really isn't. That there is a component ecosystem might suggest its a jQuery alternative, but they really are for different scales of application programming. I think it's this idea most harmful about React adoption and to be fair React marketing hasn't exactly said otherwise. So we get web pages with massive JS deps cause most people are probably using React for a productive developer experience rather than a fitting use case that actually justifies resorting to a virtual DOM model for applying view state, and yet React sold itself on "we probably know better than you about efficient DOM updates". That's true if you have lots of Juniors hanging around.

hajile 6y ago
I think that depends on how you use react. When I first started using it to replace jQuery, it resulted in different use patterns than when making a greenfield SPA. I just wanted something easier to maintain and it did that in spades. React was an easy drop-in replacement. No state library or whatever else (there weren't a ton of libraries at that time). Just add React CDN, code up some simple components and add them to the page (they'd get a list of elements with the correct classname and inject one copy for each element). Today, I still take a similar approach for the occasional CRUD site I work with. The only change is that now I use the much smaller pReact and use functional components with hooks instead of the old React.createClass() from the early days.