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...
Replacing Redux with Mobx simplified and sped up our codebase. I still haven't found a good way to integrate Mobx with hooks yet though.
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
I've used React, React + Redux and Gatsby several times for freelance work, as I enjoy utilizing different technologies and keeping up-to-date on the newest tech. However, from a business standpoint, I've evaluated it at my current company and the last and just couldn't recommend its use to our stakeholders, unless the app would later become a native app and sharing code between React and React Native would be of benefit.
Personally, I'm a big fan of the React library, but most of us rarely work at large tech companies who have large teams of developers segregated to a specific side of the stack and nothing else. I've found it common at every company I've worked at for back end developers to work on the front end when fixing bugs or trying to get an MVP out where resources might be stretched thin. It's also these same developers who built all the "legacy" apps we, as front end devs, all dread to work on, with the spaghetti-code jQuery barely holding everything together.
To a beginner, or a developer not focused on the front end (especially those who learned JavaScript in ES5 and are baffled by all the functional syntax used in React examples), the React documentation is severely lacking and React's lack of structure is the quickest way back to the "wild west" of jQuery. Without significant planning and detail to development standards, a React project will fail or become unmaintainable as soon as it starts to grow in size.
Admittedly, I have no experience with Mobx. It's been on my list to learn, but all the recent React updates have had me at a loss of where to start learning. React's current problem is it's trying to solve too many issues and it's degrading the developer experience because of it, regardless of whether we bring in the ecosystem or not.
Aside from the main issues I've outlined previously, my main concern with bringing React to scale is its instability. I don't mean it's not stable at a functional level, but the team seems to have no idea what they want to do with it and just keep dumping more and more features on top of it to patch design flaws or add things 1% of people needed in the first place. That said - I'm pretty excited about a few of the newer features, just because of their ability to ditch Redux in many aspects... however, I'm not sure I agree with them being built into the library, as it creates even more confusion over the "right" way to do things when there's so many options.
Personally, I'm of the mind that state management and routing should be core functionality in React (not necessarily in the same package, though, because not everyone will need them). The React community is extremely vibrant and there's tons of awesome packages out there for just about anything you'd need, but the two most popular paired packages (Redux & ReactRouter) differ quite a bit from the core concepts of the React library and the simplicity of React is lost on them. Sure, you can choose different packages to replace them, but these are still community-driven and are likely highly susceptible to API instability from one version to the next, or come at the cost of being different than the "typical" React stack, thus having to spend more time ramping up new developers on your project than need be.
As a business choice, I'd be really curious to hear why developers not working at large tech companies would choose React for their team. I realize this is very much dependent on your specific team, but I'm curious, nonetheless, what advantages you felt React had over other options?
It's a good choice for business because: the talent is there, the support is good, there structure/arch doesn't inhibit growth, the componenttization is something occurring in every library and even native in browsers, the ability to make something that is bad is superior to the inability to make exactly what you want, and compared to other libraries, the modularity and choices it opens up are the most expansive.
Further, many of the arguments that are used against React could be used against any technology.
If you look at rigid frameworks like Angular as a "good idea" then, imo, maybe you should just use something like wix or WordPress.
As far as "instability", you don't have to use newer versions of React. However you should, because new features rarely break old code, but when they do there is almost always a way to adapt old code to run the newer version with little effort. Look at it this way: why would you update the version unless you hired a developer to do it, and why would you hire a developer unless you wanted some coding done?
A good example of how react is not the jQuery of our time is Preact. Another good example is Vue. Most frameworks are now copying React. jQuery was its own beast.
I'd also have to argue that React's docs are very thorough, you're just probably looking in the wrong place, or are expecting it to cover things that aren't handled by React. The fact that the docs aren't lengthy in places is a testament to how uncomplicated the idea is.
As far as "the quickest way back to the 'wild west' of jQuery", React encourages OOP, but if you decide to do it wrong or poorly then you could do that with almost any technology. I never make the argument "don't use databases because a person might not normalize correctly".
Lastly, if React included state management and routing, it would no longer be React. It would be something I would advise against using at that point, because it wouldn't handle one job perfectly (managing a view) but do multiple jobs in an opinionated way. The beauty of React is the ability to hone it into your needs. I personally don't use create-react-app anymore, and I rarely use Redux. I bundle with Parcel instead of webpack, and depending on the situation I might add a router or not. I don't ship extra code that isn't used. If React started including routers and state management, would we have to remove it if we didn't need to use it? That seems intrusive and unnecessary.
What do you mean by that? Thank you!
jQuery was never meant to do something conceptually new. jQuery was meant to copy the way DOM manipulation was already done and make the syntax easier and more convenient.
React is the thing that other libraries are copying, like how jQuery copied the DOM manipulation that was already built into the browser.
The fact that so many things are changing because of and evolving from React means that it is an advancement, and not just a library that "makes things easier".
@uniwrighte - Definitely not looking at Angular as a good idea, though I do appreciate the slightly more structured code in something like Vue versus React (Angular has some cool concept, but it seems over-engineered for a lot of things). There's something to be said about structure within a codebase. Many people choose to use a framework because of:
The tools included that allow you to not have to reinvent the wheel on every new app, and
The established file structure and conventions that make anyone who knows the framework able to jump into a new project without any knowledge of it and instantly see what's going on
My comment about jQuery had nothing to do with its features and everything to do with its unstructured nature. While this makes it highly flexible, it also makes it easy to produce messy, unmaintainable code. With companies working in large teams of engineers that already have established style guides on how to produce React applications, using the library totally makes sense, but I've seen a lot of newer companies pick up React just because it's popular and lead themselves down the path of spaghetti code. I'm not saying React is a bad choice for small companies, but it definitely takes more planning before starting a large project than most other established libraries out there. You have to be diligent about setting up Higher-Order Components / Functional Components in order to not mix too much logic with your markup, otherwise it quickly becomes really hard to read.
Also, I completely agree with you on not including state management and routing in the base React library, which is what I said in the first place. My point is that I'd feel more comfortable using React on a larger project if there were officially supported packages for both of these. Using Vue as an example - Vuex seems like an extension of Vue itself when you add it to a project. Its concepts follow and enhance those of Vue, whereas Redux, while extremely powerful and IMO a better state management system for larger apps than Vuex because of its concept of immutability, increases the complexity of React ten-fold because it doesn't really adhere to the same simplicity as the base library. The same could be said about VueRouter vs React Router. Why they decided to remove the ability to define your routes as a JavaScript object in the new version baffles me. I get that JSX is a key concept of React, but I question the motives of a JS developer who would rather define routing logic in XML-like syntax, instead of JS/JSON notation. Weird. :P
I definitely won't contest that React and its ecosystem is pushing innovation faster than any other library/framework out there right now. They have a large team behind it that's dedicated to improving and innovating with it, so it doesn't surprise me, as it's backed by a company that uses it everywhere. The same can't be said about something like Angular where Google itself is so fragmented on their products - they have multiple UI libraries between the organization and also use React and others across several products. Without a single point of development, it'd be hard for them to push much on the innovation side, not to mention the companies mostly utilizing Angular are larger enterprise organizations who are notoriously slow to change. There are definitely a lot of cool things coming out of the React camp and I don't think they will cease to be the leader in many things in the future, but just because some libraries are copying things that React does, doesn't mean they aren't doing it better. It's a hard position for Facebook to be in - they are driving the innovation but others have the opportunity to learn from it and improve it, which is why I think we see new features to React so consistently, because they have to keep innovating to stay relevant with how fast the JS ecosystem moves.
With great power comes great responsibility I guess.
For me spagehtti code is when you consistently have to open 4 or 5 files to understand what is happening.
As an experienced React developer, I can read almost an code with accurately named components within a few minutes, and I usually can understand the strucure w/o opening more than one file.
Your App.js is the entry point, whatever you name it. Find that, and you know what the entire application does, unless someone intentionally made it harder for themselves. I don't have much experience with Angular, so I won't really try to compare, but I do know that other devs complain about sifting through boiler plate. With that said, I'm also sure there are some poorly designed Angular implementations out there.
As far as react-router-dom, the reason you would want XML for your routes is to make it more declarative with your components. Instead of reaching around to some function and tossing your components into it, you can just declare it directly.
If you wanted to do it out of JSX, then here:
const routes = [{comp: Comp, path: "/comp"})and a one liner in render OR you could make a stateless functional component:
{routes.map((route)=><Route path={route.path} component={route.comp}/>)}You can do it however you want, but the point is that it allows you to interact with the DOM via a logical abstraction instead of boxing you into a do-this do-that model like jQuery or possibly almost any framework with a rigid structure. If you think about it VanillaJS/jQuery are about is strict as it gets, because you have to declare every action (or try to work around that and build your own version of a view library).
P.S. don't know how the code will look on this platform, so thank you for bearing with me
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.