I wanted to try and address the points Brad makes and as well as clear up some of the misunderstandings in his post. Take a look https://medium.com/@dmitrigrabov/react-is-not-the-new-jquery...
React is the new jQuery
191–200 of 206 posts
Re: React is the new jQuery
#192Earlier quoted context omitted.
> What does "an entire framework" mean? Because you can just make React the little news and weather widget in the corner of your app / website, as the only React component. Same with Vue. Is there a step-by-step tutorial for this? I was googling for one yesterday, because I have a legacy app and want to start moving small components (like datagrids) out of server-side rendering and into components. The best I found w…
Do you find it difficult because it suggests you need to deal with JS modules and building? After you get your tooling setup, you can just include a node in your DOM that React will target and mutate.
I find it difficult because of understanding how to get it to fit with an existing directory layout. And maybe existing scripts in the build. But yes, setting up the tooling is overwhelming.
create-react-app says in the README: "If you need to integrate React code with a server-side template framework like Rails or Django, or if you’re not building a single-page app, consider using nwb, or Neutrino which are more flexible."
So I go and look at nwb and Neutrino, and there's nothing there going "Need to use us in a legacy project with its own directory structure? Here's how".
I feel I'm missing a piece of the jigsaw...
Re: React is the new jQuery
#193Earlier quoted context omitted.
> Who is going to want to use a dropdown component that has the entire React 15.3 lib bundled into it? ...Nobody? Which is why peer dependencies exist. NPM/Yarn aren't perfect by any stretch, but maybe mind Chesterton's Fence and refrain from reflexively assuming the developers of them are idiots?
Peer dependencies are a very valuable tool, and I'm glad that they exist, but most developers should avoid them in most scenarios. If a package requires a peer dependency, it's probably not worth using. There are exceptions but... in general. This has been reinforced over and over again throughout JS history. jQuery, Grunt, Gulp, Angular, Bootstrap, and eventually React will join that list as well. You almost always…
So, two things:
I'm sorry that you've gotten bitten because it's frustrating when it happens, but "if a package requires a peer dependency,it's probably not worth using" is some cargo-cult stuff. Anything that acts as a extension system (coded to an interface) should use the project it's extending as a peerDependency. They are not "global variables", they're interfaces. It's what you're writing against! If you end up in dependency hell because of them, that means your dependencies are not speaking to the same interface, and that means you need to resolve the problem. Which can suck, I guess, having to actually do some work as a programmer, but somehow I think we'll all muddle through. Because the alternative is to silently have different APIs that will later break because the extended system has changed, and that is rather worse than actually knowing what's going on in your system.
React is a system that exists to be extended. Peer dependencies exist to facilitate this. Understanding one's tools makes cargo-cult sweeping-statement fears about milquetoast stuff really just unnecessary.
Flatpak is whatever (it's fancy /opt, that's fine) but, "jumping outside the web world", I'll put on my platform-architecture-is-my-actual-real-job hat right now and point out that Docker, while certainly appropriate for some use cases, is, for example, happy to cost you money in production when your big ol' app (shouts to my 4GB-heap-before-taking-a-request Ruby clients) can't copy-on-write. (After all, each process is supposed to be isolated, right? I mean, that's what people think...) There are real drawbacks to this approach, it's orthogonal to actually writing code, and the analogy doesn't really hold besides.
Re: React is the new jQuery
#194Earlier quoted context omitted.
I don't think JQuery ever got bad. It just got unnecessary, like you said. But it took a lot of work to convince people that it was unnecessary. A charitable explanation of Sara's tweet might be that, like with jQuery, it is becoming difficult to convince new developers that React may not be necessary for their next project. The other comparative downside of JQuery was that components started to rely on it as a share…
Being used to jQuery, I really see no reason not to use it in new projects. I could learn all the new native equivalents, and even then still ending up doing more work than if I'd been using jQuery, just to save a little bit of page load time and filesize, but it would almost certainly not be worth it.
For example, fetch() is built into browsers now but it doesn't have all the features of $.ajax()
Re: React is the new jQuery
#195Earlier quoted context omitted.
More like a cousin... I see Vue as a nice component system for smaller applications, I don't think I'd want to build anything of even moderate complexity with it. React is for building applications, especially with teams. Combined with redux and a handful of other pieces, it's very nice. Angular, I don't get why anyone would choose it today (I've said it time and again).
I disagree. I would imo recommend you to switch to Vue if your app have gotten too big with React. As I said, Vue is more elegant and it improves the speed of development which also means less errors. There are many big companies and startups who switched to Vue and loving it so I would say your point is moot.
Facebook is probably the single most interactive and complex application out there... it's using React. There's also more to it than just the UI portion... there's also state management, and the unidirectional workflow, that you don't get in nearly as consistent a way with Vue as say Redux.
Startups will use whatever is trendy. I'm unaware of any site the size of Walmart.com or twitter's mobile site, or Facebook that uses Vue.
Just because you disagree does not invalidate my point.
Re: React is the new jQuery
#196Oh Brad, you do not know what you are talking about right off the bat. Let's go through your list. 1. Every document has a root node. is your root node now. You had a root node before, you have a root node now. 2. Do a search and replace. That's easy. 3. That's another search and replace. 4. You don't need to call a constructor, you don't need to use bind, and you don't need to assign your functions to an variable on…
I like Brad's articles, but recently it has seemed like he has struggled to migrate on React, and some recent articles have just been trying to criticise React but with bad (or false) arguments, which makes it appear just him trying to justify himself not being able to wrap his head around. React is great, mostly for bigger web apps that do need a framework and more structure, such as an SPA with multiple team member…
>React is great, mostly for bigger web apps that do need a framework and more structure, such as an SPA with multiple team members working on it.
I'd argue this is bad advice. What constitutes a 'bigger' project us arbitrary, and once you build your whole app on jQuery it's expensive to migrate to React once you get just a bit 'bigger'.
Now whether or not all websites need to be React-based SPAs is a different question entirely.
Re: React is the new jQuery
#197Coming from a background of doing embedded Javascript work(not web) I found React surprisingly easy to work with and joy to write code in.
React feels like writing normal Javascript.
Vue is very easy to embed into existing web page but feels like learning a new DSL instead of regular Javascript.
Re: React is the new jQuery
#198> React is a big commitment. I guess that’s why I’m still struggling to comprehend why so many organizations are so eager to take the sturdy, foundational layer of the frontend stack and rewrite it all in a proprietary format.
There’s nothing proprietary about React. It’s all open source. MIT licensed. If you don’t like Facebook’s implementation, there’s like a dozen re-implementations. Hell, a modestly competent software developer could write his own implementation of React in a few days of work.
All else being equal, I’d say a React code base will be less of a maintenance hassle in the future, than the spaghetti mess you usually get when trying to write complex applications with jQuery (been there, done that).
Re: React is the new jQuery
#199Earlier quoted context omitted.
Peer dependencies are a very valuable tool, and I'm glad that they exist, but most developers should avoid them in most scenarios. If a package requires a peer dependency, it's probably not worth using. There are exceptions but... in general. This has been reinforced over and over again throughout JS history. jQuery, Grunt, Gulp, Angular, Bootstrap, and eventually React will join that list as well. You almost always…
So, two things: I'm sorry that you've gotten bitten because it's frustrating when it happens, but "if a package requires a peer dependency,it's probably not worth using" is some cargo-cult stuff. Anything that acts as a extension system (coded to an interface) should use the project it's extending as a peerDependency. They are not "global variables", they're interfaces . It's what you're writing against! If you end u…
There is not a huge fundamental difference between a global variable and a global interface. That doesn't mean that interfaces are bad, but it means you should minimize the number of globally accessible interfaces that you have, and where possible opt for local interfaces that are accessible only to the classes that are extending them.
In any case, peer dependencies are a heck of a lot more than just an interface. They're a shared implementation. That's way more dangerous.
You're looking at this from the perspective of "well, my peer dependency is the interface I've blessed." What I'm saying is that for any long-lived project you are inevitably going to get parts of your implementation, interface, and toolchain wrong. It is therefore in your best interest to optimize for small, encapsulated interfaces that will be easy to remove or change later.
Unless you're working on a trivial project, you likely do not know enough about your project to bless an interface. You almost definitely don't know enough about your project to guess in advance which interface future 3rd-party dependencies will be using. You absolutely don't know enough about your project to guess whether or not your dependencies can rely on an evergreen codebase rather than a static one that you test once and then leave unchanged for the entire component lifecycle.
It's OK if you think I'm wrong about that. I probably would not have agreed with this two years ago. And you could very well be right and in two years my opinion might flip again. All of this is just opinion me, I've gone out of my way to say that none of what I'm talking about is a universal rule - you are going to need to share at least some environment code with your dependencies.
But it's usually true. You don't need to join a cargo cart to understand that some ideas tend to be better than others on average. It's not that I don't understand my tools, it's that I understand that tools evolve.
Re: React is the new jQuery
#200Earlier quoted context omitted.
I like Brad's articles, but recently it has seemed like he has struggled to migrate on React, and some recent articles have just been trying to criticise React but with bad (or false) arguments, which makes it appear just him trying to justify himself not being able to wrap his head around. React is great, mostly for bigger web apps that do need a framework and more structure, such as an SPA with multiple team member…
>React is great, mostly for bigger web apps that do need a framework and more structure, such as an SPA with multiple team members working on it. I'd argue this is bad advice. What constitutes a 'bigger' project us arbitrary, and once you build your whole app on jQuery it's expensive to migrate to React once you get just a bit 'bigger'. Now whether or not all websites need to be React-based SPAs is a different questi…
yeah you are right about the cost of migrating, I've been through one and it's indeed to be avoided.
I badly used "bigger". What I meant was more in the lines of React is great to build what we could call web apps - something with complex logic, etc. While jQuery is better for simple DOM manipulation.
Maybe a good line is, as soon as you find yourself manipulating data you might want to think about using a framework such as React.