They forget what it’s like to actually develop apps. I wanted to boost this very relevant tweet from Sophie Alpert, who had been a part of React fo...
For further actions, you may consider blocking this person and/or reporting abuse
Totally agree. At the moment I work on two applications - one is React and one is Vue. The amount of code and complexity on React side to fetch & store data in redux stores is just insane compared to Vue, even though the end result is the same (I use Vuex on Vue side).
It seems like Vue got everything right from the start - Vuex actions are asynchronous so no need for complexity that Redux sagas bring. Vue projects stay lean and easy to expand and maintain.
But Vuex is the official solution for state management in Vue right? Redux is an external library, compatible not only with React, and is not even officially enforced. Also there are a lot of data fetchings libs for Redux since data fetching is also not part of the core of Redux, you could just
fetch(url).then(res => res.json()).then(data => dispatch(action(data)))and that's all you really need.No one enforce you to use Vuex, if you like you can use Redux even MobX. There are also Rx binding provide from the core team to use those fancy operators. I will say they choose different philosophy. Although Redux is claim to be framework agnostic, but does really people use Redux in Angular... uhm. I'm a both end user, depending on who I'm working with, I can switch Vue and React back and forth.
NGRX is redux inspired library for angular state management. So people kinda use it. Not directly though
Vuex is also inspired by Redux and Flux too.
Why are you using Redux? That's your problem...
Great point. A person leading the project or product must periodically go through the same getting started steps as the end user.
For example, DHH does this; he literally builds a small new Rails app after every major release of Rails. On the other hand you can tell when a product's CEO stopped using it. I deployed a new Rails app to a popular PaaS recently, and unfortunately the UX is much worse comparing to 10 years ago.
DDH?
David Heinemeier Hansson, the creator of Ruby on Rails.
XD a ruby newbie. tk!
From his Twitter bio
XD Le Mans 24h class-winning racing driver.
that would have taken me an eternity to know.
Totally agree. Everytime I decide to learn React better, I always stop myself because the ecosystem is so overly complex, it's ridiculous.
As much as I'd like to get my hands dirty in a larger React app at work, I couldn't choose it for any reason other than selfishly wanting to try it out myself, because I feel like you need a large team of front end people to properly leverage it, which we do not currently have. It's been my experience that, React is such a different way of building things that teams used to building server-side MVC apps with compiled languages have a hard time grasping its concepts.
React itself isn't super difficult to learn basics in (though Hooks / Suspense / Portals definitely make it harder to digest) but the way Redux / Sagas over-complicates handling data is definitely a deterrent for many and React Router no longer being able to programmatically define routes is... strange, to say the least. I'm definitely excited to see what new things React brings to the table in the coming months, but I can't help but think they're definitely catering to a different developer than 90% of us.
React isn't a framework but a view library. Most React devs I know use it as a replacement for jQuery or DOM manipulation. Once you start thinking React will do more than manage the view for you, you're probably using it wrong.
Be that as it may UniWrighte, which difference does it make at the end of the day? I'm not saying the distinction is not important, it is. But the fact that some people perceive React (and/or its ecosystem) as difficult isn't because of the distinction from those two words. The reason isn't the nomenclature per se.
It's quite clear to me that Derek is talking about the ecosystem (or at least React + Redux.
I agree that he may on it the wrong way, I have no knowledge of React so I can't judge the legitimacy of his argument, but as a thirdy party I have seen countless people using the three words "React is hard".
At some point, whatever they actually mean by that, one starts wondering if there's a speck of truth in that. Even if all of them are using React the wrong way or fighting it, it means there could be at least an issue of communication. Why are they all using it wrong? Is it the documentation? Is it the fragmentation? Is it Saturn in the wrong place? I don't know.
Which, in the context of this conversation, is probably the case that Ben is trying to make.
Redux is difficult. I will agree that Redux + React is difficult. However, React on it's own is far too simple compared to something like Angular for me to consider it "problematic" regarding it's usability. If anything, adding more features will only increase the difficulty of learning React. For instance, if Redux was React's default data store, I'd have to say that React is on par in difficulty to Angular.
So the "problem" is Redux and the fact that people tend to treat React and Redux as a package?
Yeah, and that is a commonly recognized problem to many JS developers I interact with. React should be taught with mobx if you're trying to avoid difficulty
Evan You remembered what it was like to be the user of Angular-1/JS, when he created Vue.js.
Nice one, yet true one :)
I can say that Rails is closely monitored by people that are working in companies whose products are built on top of Rails (Basecamp and GitHub at least), which probably helps a lot in that regard.
It's probably the same for React but the problems that Facebook must have had to develop React are probably not the same as those that lead Basecamp to extract Rails from its belly.
React does exactly one thing.
I either maintain or contribute to multiple internal libraries and tools, and I have to say, this is a lot harder than many might think. I'll spend weeks hounding developers for feedback on something, and won't hear anything from them until months later, when that decision is now irrevocably baked into the library.
I don't think that this problem is anyone's fault, but it has shown me that it IS something you have to account for in your planning. As the project maintainer, you have to assume that real developers aren't going to drop everything to give you feedback, you have to get creative in finding ways to encourage them to give feedback. For example, I was working on a library that was going to affect my team and several others, so I ended up going to our director and convincing him to give me a few hours of people's time every week to play with and five feedback on this library. They had always been free to spend that time on things like this (we have several hours a week set aside to things like this, or to professional development), but by having someone in authority grant explicit permission, people felt like it was a priority. I've also seen other developers schedule actual meetings to talk about what they've been working on and solicit feedback on the design choices they've made.
Those techniques have been helpful within my organization, but they don't exactly scale to a large open-source project. You can't just drop a meeting invite onto 10,000 people's calendars! I think that's why a lot of projects issue prereleases, release candidates, feature previews, etc., and then encourage people to try them out and give feedback.
One potential problem with this is that the only people who will carve time out of shipping the next feature on the backlog to test your library are the hard-core users - the ones who know your library inside and out, and who have already learned and come to believe in your projects philosophy. They're often not the run-of-the-mill developers whose lives you're trying to improve.
I think this is why a lot of projects also engage in dogfooding. I personally find a lot of issues when I go write a real app with the tools I work on (which is actually my main job anyway!). Many projects engage in this, but there are pitfalls here too. For example, if your dogfooders aren't a representative sample of your developer population, you're not going to get the kind of feedback you could otherwise. Take the observation about React that started this discussion: I wouldn't be surprised if that problem is a result of the fact that React was originally developed by and for Facebook, and is largely dogfooded there. Facebook is pretty different from most apps in that their state-management problem is vastly more complex than their data-loading problem. So, naturally, the original design and the focus of their thinking and testing is focused around the very hard problem of state management in Facebook-like app. From what I've seen, they do a good job of getting feedback from other developers, but the loudest voices in their ear are often going to be their internal developers.
This whole feedback-from-developers thing can also be pretty hard because of the inevitable backlash that comes when you have to disregard one use case in order to make the rest of them better - I had one project where one developer was very angry because we wouldn't rewrite the core of our project in order to accommodate some of their self-imposed challenges, and how it meant that we didn't care what anybody's needs were and that we were developing in a vacuum and that our year's worth of effort was wasted. We knew from the rest of our feedback that our library worked well for the 95% use case, and their use case was in the other 5%, so we were able to shake it off. We still tried to find ways to help that developer, but we weren't about to make life harder for everyone else just for them!
All of this to say: I don't know how to solve this universally. Projects need to work really, really hard to get feedback from real-world developers, and developers need to somehow find the time to pay attention to and five quality feedback on changes to their tools. Both of these are hard, and there's no silver bullet that can make them easy, but it's certainly a goal worth striving for. Hopefully those projects that do it well can share their secret sauce with the rest of us 😀.
Which is why frameworks like Rails and Laravel are still popular choices in getting an app built and shipped. You're not arguing over patterns or figuring out which state management library to use, you're just building stuff.
The more "library," (rather than "framework"), the harder it is to keep the user in view.
When I was developing vector-concurrent numerical functions, we had little idea how the customer would actually use them. So we just made them as bomb-proof as we could.
PS: If you think the use won't matter, think again. If we'd had some idea what values would be passed in, it would have let us do better optimization. Guessing may not be helpful: one user's optimization is another user's pessimization.
Sometimes building a library w/o imposing requirements can lead to a modular peice of code that can be used in many more situations. There is a partial trade off between short term stability and long term reusibilty.
I don't understand this tweet.
How should this react-fetch package look like?
I'm with you on that. This seems like one of those things where someone isn't learning something fast enough after coming back to it, so they blame the tools. I assume it would be mobx or a fetch request storing in global state or maybe something worse.
No, it's not.
React is not complete yet.
It doesn't underestimate or overestimate anything.
It just solved one hard problem in UI development and still trying to solve it well.
2019 will be a fascinating year for React and since then we'll see tons of Fullstack Backend Framework go down (Rails is so 2006), you don't need Rails to just render html/json, do you ?
I've only just started working with Ruby on Rails, but I keep being pleasantly surprised by how much it works with me instead of against me.
This post should definitely get more comments, maintainer side of the story is not so often heard of.
Why would they want to turn react into a framework? So far React's popularity (imo) is the fact that it's a view library, and not a framework like angular.