Let’s not forget that jQuery was a polyfill that allowed JavaScript Devs on all browsers to code to a common baseline. React is a nice —- and popular —- library for building UIs but it’s existence isn’t an indictment of the laziness of standards implementors for browsers (okay, IE mainly) and god-send to developers like jQuery was.
Yes, React isn’t _exactly_ jQuery, but it gives the same level of productivity boost comparing to development with just the modern DOM APIs (querySelector, classList, etc).
Oh 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. <div id='app' /> 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 your class instance.
React allows you to compose things. Make something once and use it everywhere. You write much, much less code. You get lifecycle hooks for when things mount, update, unmount. You get easy templating in JSX. You can also ditch the whole thing for Inferno if you care about having no lisence or company behind it.
You also get amazing libraries for state management and async via reactivex.
You also get convention. jQuery didn't offer much of that once you started gluing its functions together...
I can usually jump into someone's react code and get what's going on pretty quickly unless they did something really gnarly with incredibly nested props. Even then, at least I still know where to drill down. With jQuery soup, you didn't get that luxury.
Being able to have an entire team know how to build components and provide them with functionality is an incredible advantage. I don't love everything about react either, but the ecosystem, somewhat enforced convention, tooling, etc - it's worth it (so far).
I love some things about Vue, but it isn't a silver bullet either. Brad seems to be pretty butt hurt about react. If you've worked on a large team without something like react, then worked on one with react, it really shines. It's a major productivity booster.
I agree when you’re talking about the most well known of plugins and so on, but IME for application code all that goes out the window. A lot of developers really didn’t know how to write JavaScript back then. Still don’t, but we didn’t then either ;)
I agree that the library has great convention. I actually learned quite a bit from that API when I was starting out. The only problem was you could really abuse the usage of the API.
I'm realizing now that this isn't a fair comparison. React 'wins' here largely because it has a smaller scope. It's for giving functionality to templates built in the library using a certain approach. jQuery was far more open ended and far less opinionated. That was as much it's strength as it's weakness.
It's definitely not a direct comparison. But I do think react is a nice safe tool for larger teams.
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 members working on it.
Just like jQuery is great to do some quick and simple dom manipulation.
I've tried both opposites; I've been on teams working on large apps in jQuery, and it's hell.
And I've also used React to implement simple little things, and it's also hell (part of it for reasons Brad mentions in this article).
I don't have much experience with Vuejs but I've been using it instead of React recently, and it's refreshing indeed. Just like jQuery you can just import it with a script tag and start doing some dom manipulation and it makes the code much cleaner than jQuery.
And as others have said, jQuery is not bad - it's awesome. I guess it didn't age very well with the JS env evolving, but it's great.
>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.
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.
We're talking about two totally different programming paradigms here. The end product might be the same but it's more of a question about how you arrive there.
With JQuery you're signing up for manual DOM manipulation. It's a challenge to scale that for what's now considered table-stakes for web apps.
If you tear out something like jQuery, you’re going to have to figure out a way to get those accordions to expand and collapse again. If you tear out React, you get a blank page. React is a big commitment.
This is probably the only real concern I see.
jQuery is a library for DOM manipulation. It can co-exist with many other libraries.
React is an entire framework.
These days you need jquery less because browsers are more standards compliant and css animations basically work.
The trick is about using the right tool for the right job.
We have several large react applications - these are user-interaction heavy rich single page apps.
But we also use vanilla html and jquery dom manipulations in many other places.
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.
The people for whom ripping out React or Vue leads to a blank page are those who wanted an app from the ground-up.
If anything, React is losing because it doesn't include enough out of the box. If you wanted to build a news widget, fine. But if you wanted to build an app, you have to start putting pieces together from 3rd parties (or write your own custom pieces). That's not what a framework sounds like to me, that sounds like figure-out-your-own-framework, and I think that's why Vue is winning.
Create React App was a very late response, and I still don't think it's as good as Vue's up-and-going tooling experience.
I guess what I meant was when you build a widget with react - the whole widget has to be react.
With jQuery, you're likely building it with html and using jQuery for user interactions or animations (I know - not always true - constructing the markup with $('<tag>') is also useful). So its easier to rip out jQuery and replace it with - say - document.querySelector - or whatnot.
I personally think React is overkill if you're pulling it in to do a small widget on a larger non-react page
It's typechecked with redux and router built in already but still early so not all bindings are there yet for libs easily found for react/typescript. Maybe not for all projects that need that strict of type checking.
> 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.
I've been spending hours and hours the last few days working with react/vuejs/react native/native script+vue. It's hard picking a stack for staticish sites/pwa/pwa+e/spa/mobile! Throw in moving from .NET/IIS to .NET Core and tinkering with Node.JS/Express and your head is going to be spinning like mine (let alone worrying about authentication, API first, SSR)
Right now I'm moving an old webforms project to .NET Core + MVC / Razor and am going to try building out some components in both react and vue to see how it goes.
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 might prescribe that you go to reactiflux (not associated) or other popular chat communities to get some more live help for getting your tooling up. I suspect that if tooling were resolved, so much discussion of churn would disappear overnight.
> These days you need jquery less because browsers are more standards compliant and css animations basically work.
Originally, jQuery's big selling point wasn't that it handled animations, it was that it gave you a query selector, and one that could be used in any browser. jQuery predates the release of chrome, and came out a few years before document.querySelector was added to Firefox and Chrome was released.
jQuery was monumentally more useful for common actions compared to its contemporaries, such as Dojo, MooTools and Prototype.
>>If you tear out something like jQuery, you’re going to have to figure out a way to get those accordions to expand and collapse again. If you tear out React, you get a blank page. React is a big commitment.
>This is probably the only real concern I see.
I'm sorry but this is not a problem. If you commit to React then you commit to it. You are not suppoused to change it every other year.
Imagine a big C++ Qt application. Will you ever think of changing Qt on it, and expect no huge cost? No. That's unreasonable.
So what he wants is not only a cross-browser, cross-platform framework (and much more) but also a framework that is somehow "cross-framework"!!
This is really getting me. People, such flexibility and ubiquity is NOT FREE. People this days complain about the web being to complicated, and that it is a lot of complexity to make something "simple as a webapp". I agree, it is. But that simple multimedia webapp you get today works over a distributed network, in almost every platform, from mobile to desktop to almost everywhere. This kind of ubiquity will be unthinkable in the early 90s/2000s without investing on a huge number of experienced dev teams and a huge especialized codebase(s). Today some javascript framework and markup will give you almost the same product. Yes, I think the web ecosystem can be improved. A lot. And the end result is not always 1:1 comparable at many levels with what you would get back in the day with native apps and a load of work and experience. But still.
People complain but they don't know what they are getting.
same! Jquery is still quite useful and powerful. This is also what rails does for me; makes web development fun. Or highcharts making charts fun, or elasticsearch making search fun. To me that's a testament to elegantly solving a problem. I just don't get those fuzzies with react.
> Burn all of your markup down to the ground and replace what you had with <div id="app" />
This isn't totally true -- if you really only wanted to implement a single toggle and leave the rest of the page alone, then you could replace just the relevant DOM elements with a container and render into that fragment of the page. (Though really I'd ask why use React if that's the only value you're getting out of it)
> 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. [...] Projects like Vue are showing that’s not necessary.
Except, Vue.js does require a proprietary format; all those v-* attributes and custom components will be need to be migrated if you want to switch away from Vue. Comparatively, React is better in this regard because there are multiple implementations of React (preact, inferno, nerv). Also, JSX is technically optional, and it's really easy to mix markdown, or other formats/templating engines into a React app to handle the content-heavy bits.
I feel like the word "proprietary" means something different to me than the author. When I think of proprietary I think of a closed standard that may or may not be copyrighted/patented. Something like React would not even come close to my definition.
Wikipedia seems to agree with me [1], but maybe I'm misinterpreting it:
Anyone who uses "the new jQuery" as some sort of insult (as it seems Sara did in her tweet) probably hasn't been a developer for more than a few years or is just trying to sound smarter than they are by bashing an easy target.
The reason jQuery got so popular is that it made common tasks so much easier than anything else at the time. Anyone who was doing web development before jQuery knows what a godsend it was at the time. JQuery was a fantastic leap forward for development at the time it was released.
JQuery didn't become bad, the rest of the development world caught up and made it unnecessary.
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 shared library, which meant developers suddenly needed to do dependency management. That is (usually) a bad idea. React absolutely does have that problem as well - probably to an even worse degree than jQuery widgets ever did.
This is kind of the same concern I have with Vue to be honest. I use Vue for prototyping and will probably use it in some final apps as well. But I'm probably not ever going to use a component that someone else has written if it relies on Vue.
IMO Lodash went the right direction with this. A component or library can depend on Lodash, pull in just the functions that they use for a final build, and then nobody else in the entire dev toolchain needs to know or care. No risk of conflicting dependencies, build size stays low, etc...
I kind of wonder if the problems Vue solves for me could be solved better by a smaller, lodash-style library instead of a framework.
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.
Take a look at zepto (or another jquery-like library), add some feature detection for IE polyfills, and switch to using fetch for ajax calls. Unless you're using a lot of jQuery dependencies, you'll cut your download size by more than half for most browsers/users.
I'd never say don't use jQuery, and it does support some options for a minimal footprint, still there's smaller options that probably have all you need.
Indeed. I occasionally write a webbased tool to deal with a specific task (say formatting some form of codec data, or a simple dashboard for a specific event, or a small config generator, or whatever), userbase is in the <10 users (not concurrent) range, I don't give a stuff about scaling. I care that the code is in a repo (git, svn, whatever), is versioned (deb, rpm, whatever), and deploys cleanly.
I could learn and use $latest_thing, and maybe it would be great. That will triple the time taken to develop, but whatever. However in a couple of years time when I come to need to write something else, $latest_thing will be old hat, and replaced by $shiny_and_new. Rather than having 10 years of nice simple code based on jquery, I get some based on Angular, some on React, some on Vue, some on Meteor, or whatever.
I'm not a programmer, I'm not a wireman, and I'm not a carpenter. I program in the same way I'll run a network cable or get a screwdriver out, it's a tool I can use to solve a specific task. I like tools that are the same, year in, year out.
That's not to say the latest frameworks aren't all great, if you're building something for a million users and want to take advantage of shiny new features that's great, but for those that aren't, there's still a place for boring old things in a large part of the computer industry.
> 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.
That's fair.
> The other comparative downside of JQuery was that components started to rely on it as a shared library, which meant developers suddenly needed to do dependency management. That is (usually) a bad idea. React absolutely does have that problem as well - probably to an even worse degree than jQuery widgets ever did.
I totally agree with that, but I don't think you can use that as a knock against jQuery, react, or vue. I think developers, especially js developers with our love of pulling in external packages, have yet to find a great solution for dependency management.
> IMO Lodash went the right direction with this. A component or library can depend on Lodash, pull in just the functions that they use for a final build, and then nobody else in the entire dev toolchain needs to know or care. No risk of conflicting dependencies, build size stays low, etc...
I think lodash can work that way because most of its functions are small and self-contained. It's easy to just bundle in a few select functions when they functions are 100 lines max and don't need the rest of the library, but I don't think React or Vue could use a similar approach.
Who is going to want to use a dropdown component that has the entire React 15.3 lib bundled into it?
Maybe not for a dropdown component, but I built a calendar component that stood alone using preact and redux, and the final size was still smaller than most calendar components of similar complexity.
To clarify what I was talking about with dependencies, many jQuery widgets used jQuery as a global dependency. This is very different from just building a bloated library - I might prefer a small library that has fewer dependencies for performance reasons, but I can still use a large one without any engineering downsides.
The problem is if I need to manage the dependencies between multiple components - if there's a singleton dependency that multiple components are accessing. It's dangerous not because it's a dependency, but because the components consuming it may have different requirements or assumptions that conflict with each other, and I won't be able to fix those assumptions without forking the components.
This is where you would run into scenarios where somebody's widget was only jQuery 2.x compatible, and somebody else's wanted to add custom events that interfered with scroll direction or something... I still have horror stories about trying to debug that kind of crap.
Shared dependencies really seem like they should be a good idea, but unless you're willing to fork other people's code or your app is only going to have a very short lifespan they're usually more trouble then they're worth.
To be fair, I think jQuery eventually did go the same way as Lodash. I haven't checked in a while but I'm pretty sure that they now have a way to generate a custom build of jQuery to be locally scoped to whatever thing you're building.
It would be tough for Vue to go the same route (still much easier than React) but that just means that you should probably only use Vue for your own projects and should avoid importing 3rd-party components that rely on having it globally accessible.
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 end up with the nightmare of having to do package management because widget A and widget B interfere with each other. This is the same exact reason why it's good practice to avoid defining JS variables in the global scope.
Peer dependencies are just global variables at the package level.
To be clear, the people who built NPM were not idiots. Node handles packaging really intelligently - via a node_modules folder. There was a lot of thought put into how to make this system flexible: for example, you can have a node_modules not just at your root, but even in subfolders. This allows you to have custom implementations of a dependency that's isolated to a single folder in your source code, and to easily check your implementation directly into your VC.
None of that is accidental - the Node developers learned from languages like Ruby and Python, where gems and packages would be installed globally to the system, not locally to your project. They wanted a system that got rid of the majority of peer dependencies.
Jump outside of the web world and you'll see the same trend in the broader software ecosystem as well. The big hotness around Linux packaging right now is Flatpack, which is mostly copying Node's strategy of bundling dependencies into the app and then de-duplicating them after installation. Docker is an even more extreme example of this trend.
Peer dependencies are sometimes useful, and they're an important concept. But people use them and abuse them too much. They sound like they should be a good idea, so developers often don't realize the downsides until after they've gotten bitten - and even then they often just assume they were using a bad library or something.
9 out of 10 times you should avoid them, and you should avoid frameworks that introduce them.
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.
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.
> But it took a lot of work to convince people that it [JQuery] was unnecessary.
First it took about a decade of browser and ECMA very intensive development to actually make it unnecessary.
> it is becoming difficult to convince new developers that React may not be necessary for their next project.
Give it a decade for the web "components" to actually become composable and for inventive and useful native language built-in solutions to state management to happen before you start advocating people out of React. Until then telling people they might not need React is not a step forward but backward. Imagine people saying "you might not need jQuery" in times where IE reigned and browsers were wildly incompatible.
Unless you were doing custom jQuery builds per project (which no-one was), it was always bad. People would routinely drop in the 35kb lib and only use 3-4 functions.
That's not really a problem with jQuery, that's a problem with the way people were using it.
Also, a slow loading JS lib wasn't as much of an issue 5-7 years ago when jQuery was really in its heyday. Web pages were simpler and more information based back then and it was usually a requirement that they be useable without javascript. Since you are (should be) loading jQuery at the end of the page (or asynchronously) the page should render just fine without jQuery and probably would have been loaded by the time any user interaction would have happened.
Also, since users were on computers (mobile wasn't really a thing) and data usage wasn't a limiting factor (most plans were unlimited), loading extra data didn't really matter that much.
Yeah, jQuery had extra functions that you didn't need, but it didn't really hurt much at the time and there wasn't really a better option.
It still doesn't hurt. Less than 300k of a cachable library isn't a big deal for mobile data, and jQuery has never (in any example I know pf at least) been the reason a mobile page is slow. Sites like the default mobile reddit manage to be absolutely atrocious without it (10+ seconds to load anything even on wifi), yet lots of sites with it are completely fine on any smartphone in current use (such as the same phone mobile reddit takes 10 seconds to load on because it's using some awful ajax setup - seriously, they had perfection with .compact and just abandoned it for this crime against humanity).
> Also, a slow loading JS lib wasn't as much of an issue 5-7 years ago when jQuery was really in its heyday.
Not to mention it was recommended to point your "src=" to one of the common cdns, so it would likely already be in the user's cache from some other website that used the same jquery version.
I wouldn't say jquery was bad. It was really a nice API with interesting innards. Easy to abuse, of course, it was too popular not to end up being the first thing people try to have 'modern' websites.
I don't presume to be an expert on history (only entered the webdev domain in 2010), but didn't prototype come out at least a couple of years after jQuery?
Php is important in the way it exemplifies the total failure of the software industry to take advantage of it's 40-50 years of accumulated knowledge...
jQuery was never bad. As a tool it was fantastic at what it did.
But jQuery wasn’t just a tool, it was also community. What that community did/perpetuated was some pretty bad and ill advised practices. Plugins for everything - the old $.sum(2,2) joke applies here. DOM for state. Even sanctioned projects like jQuery UI were guilty of some terrible, awful practices.
That said, React isn’t the new jQuery, it’s the new Backbone. Backbone lacked so much - and did so little - that it’s deficiencies needed to be made up for by “other” tooling. As a result, there was O(n) ways to “Backbone” – making backbone apps very difficult to study/build/maintain.
React is fine. The community just needs to coalesce.
I think a lot of that does happen with React. Before Redux there were so many Flux-like libraries. material-ui and react-bootstrap are very widely used for UI/UX baseline. There are a ton of options for everything, for me it comes down to the following.
react, redux, thunks (with async functions), fetch, material-ui ... those will get you a LONG way to where you need to be with react.
Who is? CSS and SVG are great, but how is her javascript? Neglecting the role that jQuery played is foolish, and even respected developers can say foolish things now and then.
Unfortunately the shortness of the tweet leaves much to interpretation. Perhaps the analogy she was getting at is simply that it's being used in solutions that do not benefit from it.
I agree jQuery was very useful early on, especially since it abstracted cross-browser differences and APIs.
However in my experience, a couple of things were key to creating a negative view of jQuery:
1. Security and unsafe defaults, for example: evaluating remote JavaScript by default [1]; and unsafe DOM parsing by default [2]
2. Not really to blame on jQuery, but its ease of use for DOM manipulation led to programming patterns that aren't easily scalable, for both code and performance
I think by 2006 magic auto globals was already off by default (4.2, which was released in 2002, was the one that turned it off, and though 4.2 was still widely used by the time jQuery came about, register_globals was considered bad practice in general by at least 2004, if not even earlier).
good point. Your timeline is accurate, and while PHP installs tend to be out of date and people following tutorials would just turn off security features, by 2006 the trend should have been in decline, yes.
More than anything, the crazy thing for me is that jQuery seemed to have been there from the wake of the web, when it came out only one year before the iPhone.
Is jQuery unnecessary because the functionality is built into js now? Or browsers? Or other libraries? If it's libraries, are those libraries providing a superset of jQuery or are they just better?
jQuery is not that necessary anymore because difference between browsers' js implementations are not that big. You still have small differences in events but nothing like it used to be
Yes, the DOM API's have greatly improved and are well-supported among browsers now, so jQuery is no longer needed for that. React doesn't solve the problem of inconsistent and unwieldy browser API's (which isn't a problem any more), but of a clean architecture for web applications.
Back when browsers were wildly incompatible jquery was a life saver. Sure you could do painful dom code and then have all kinds of libraries that have to be loaded in the right order to support all browsers or you could just include jquery. Now in the era of the progressive web app SPA jquery is outdated. Even for low level dom its still outdated because modern browsers follow standards really tightly especially compared to the bad old days. Frameworks are starting to get outdated in the face of tools like Svelte as well as Polymer 3. You can pull off a SPA with Polymer 3 on modern browsers with no shims at this point, except maybe shadow dom, but Polymer 3 has selective shimming so you don't have to download one huge shim file.
jQuery also predates standards such as querySelectorAll and fetch, so no, it wasn't just compensating for browser incompatibilities; it also provided a far more pleasant API.
React is in a similar boat - it provides a far more pleasant experience keeping the DOM in sync with your application state, in a way that Web Components don't (although they have other advantages that make them great when used together with React).
Insulting is really what i felt too. Simplicity, size, ubiquity, plug and play are the opposite of react.
I would understand if comparing VueJS with jquey. Even if they are very different, the philosophy is the same: a small elegant easy to use versatil tool.
I know what a pain Prototype.js and others got to be... jQuery was a lot cleaner, though in retrospect, I wish they'd passed the context in as a property, instead of relying on "this", also wish they'd passed it as an already jQuery wrapped representation.
Agreed. Furthermore, a lot of those tasks were downright unnecessarily painful and tedious time sinks, e.g. browser agnostic control when the ecosystem was much more fragmented and HTML5 more nascent. Also, jQuery's documentation was solid, and it was very easily extensible.
As someone who learned web dev in the era after jQuery was marked by many as deprecated, I started to resent it mainly because of all the StackOverflow posters that give jQuery answers to JavaScript questions. (Plus the cases where CSS would suffice.)
React has a lot of inertia behind it, although it doesn’t really make things easier.
The amount of js code to make even basic things work is high, and with so many different styles of writing react/js code, large codebases require significant effort to keep maintainable.
Which is to say, with this much effort put into structuring maintainable react js code, one could pretty much develop in any js ui framework (including jquery, backbone or none whatsoever) - since little of this effort is dependent on react, or made easier by it.
I disagree. Bridging the concerns split between between HTML, JS and CSS helps a ton and would be a lot of code to write if not for React (or similar frameworks).
I feel this is because many people confuse Redux (or flux) with React itself.
Or the more general problem of not knowing the difference between store state, local component state, and component instance state (the actual JS object's properties.)
The new Unstated library leveraging the next Context API is a nice balance I find for state management. It basically just mirrors Reacts setState style update system. Although you do lose the single source of truth pro of Redux.
Virtual DOM and ability to derived your DOM state from props and state is not something you can easily done with jQuery or any UI library that doesn't have that concept.
It's not something you can easily implement yourself either.
That's the main part that makes React code maintainable.
I agree, this is the part that people seem to be ignoring. Yes, you can make a proof of computational equivalence between jQuery and React, but you cannot deny the massive increase in human usability that an set of components brings. There's far more interesting set of things you can do, Redux + the litany of other related libraries, a vibrant ecosystem unto themselves, prove this. I started my career out slinging jQuery and after 4 years of React I never want to go back.
Maybe development requires more overhead, but you have to factor in reading understanding and maintenance. React, with a proper state management library like React, in my humble limited opinion, is easy to understand because of its functional nature. The view rendering is a function of the props it receives, whether it come from a context based store like Redux or just passed thru. I don’t find reading other peoples React code terribly difficult because most of it is not surprising. Even components which make heavy use or internal state are never so terribly difficult to understand.
I don’t think the same could be said of your random JQuery or. Backbon based project
Moved from Vue to React. A couple things drove this: Typescript support for Vue was kind of weak, and the interception of events and reactive elements ended up creating more bugs. I do love how Vue is easy to get up and going fast, but React seems more compatible with a growing team where you want stronger guarantees.
Vue works better for small apps, or progressive enhancement (similar to jQuery)
React works better for teams working on applications that need build tooling and dependency management anyway.
Angular, frankly I don't see why anyone would pick it over the other two. Yeah, it's got more in the box, but that bigger box takes 4x as much effort to lift off the ground.
React, like jQuery, could have done more to keep people from writing bad code. With React, they made the same mistake that Angular did, which was to impose strict rules on all developers. Vue, to its credit, doesn't make this mistake. It's much less opinionated about state management.
In this case, doing more means responding to the real-world usage of React, and making it so that lifting state up isn't the only recommended option. Vue did this and is grabbing some market share from React. https://reactjs.org/docs/lifting-state-up.html
> This comes from a well-known and respected thought leader.
I don't disagree but will push back slightly on the appeal to authority. I think in JS land we're getting a little too carried away with celebrity developers (I often joke about "what would Dan Abramov say?" and it's only half-joke). I've been trying hard to focus on the ideas, without regard from who said it.
I agree with the spirit of what he's saying, although I don't think jQuery is a very good comparison to use.
React is a decision. I'm speaking in broad generalizations because I don't know how to put this principle into more specific terms, but good programmers should avoid making decisions for as long as possible. This is the same reason why I caution people against using test frameworks. Most of the time when you start coding an application you won't have enough information to make any educated decisions about it.
This is a huge advantage that Vue has over React. You can use Vue for just one component out of your entire app and it's fine. It is fairly easy to separate it from all of the rest of your application logic and that means by extension it's fairly easy to rip it out later. Or at least... easy enough.
It's still not perfect. I dislike how hard it is to make its templates fail gracefully when Javascript is disabled. I dislike that it uses setters in its data model, which discourages immutable programming. I dislike a few other things as well.
At some point, someone will make a better framework than Vue, probably by building something even smaller and even more focused than Vue already is. But in the meantime, if you are going to use a framework for two-way data bindings, you should probably be using Vue instead of React. Opinion me, of course.
it is as if some react developer sat down and said, “how can we make this even simpler so that even my grandson can do it.”
i appreciate when we have guys like the authors of Vue come forward driving the community and taking web development to the next level giving us a more elegant solution.
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.
I think there is some confusion comparing jquery with frameworks in general heh- time for a history lesson! So back in the mid-aughts right before jquery there was prototype. I got hired into a job where I had to maintain sites written with both in the past and they were very similar to each other. Ajax was new and so was the class based handling of JS to make it more object oriented. It could be done but prototype made it convenient. It was possible to manipulate objects before applying them to the DOM however it was really verbose...academic I would call it. Then prototype’s cool younger brother arrives (jquery) and it became so easy to pull this stuff off it was like a giant party. Learn jquery? Your hired! Ahh the halcyon days ;) Anyhow- if you’ve lived through things like CGI and DHTML (and java servlets to a lesser extent) they were like the malaise era of web dev but jquery flipped the tables there has been NOTHING like it to date. We’ve gone back to academic with colorful packaging (I’m lookin at you angular!) and react coupled with redux just isn’t the same- it’s interesting but not a quick study. So..back then we could pick up a program in 24 hrs book and land a job. Today we can read 24 books and scratch the surface. Jquery was a movement not a framework and the statement being made was life is too short to NOT be incredible, we can all be incredible with jquery so why not? More comparable to the Misfits showing up to a Johnny Cash show than just another framework...just my two cents.
i just find it amusing that everyone gets up in arms what Brad Frost struggles with in React because he's famous. news flash: hundreds of devs face these issues every day and figure it out. Brad is famous and has problems with React; that's fine. He'll figure out a way that works for him. Doesn't mean his opinion at all reflects the experience of the thousands of devs who are happy with React. Let's move on and talk about more interesting things.
I think people got carried away with the JSX side of React (which IMO is really just the icing on the cake) and forgot that React was probably the first view library that introduces the notion of the DOM as a pure function of data. It made functional programming mainstream in front-end development. This purity makes UI extremely easy to reason about and makes all DOM changes tractable. I was in a Backbone shop before using React and I remember Backbone was such a chore to manage in a large application. We switched to React and never looked back.
> It made functional programming mainstream in front-end development.
I totally agree, and in fact I would take it a little farther and say it's making functional programming mainstream on the backend as well. Many people I've worked with got their taste via React/Redux and then started adopting things like Elixir/Phoenix for the backend.
Maybe it's an overstatement, but I credit React with driving at least some of that.
Its funny because JSX is totally unrelated to React besides just being a heavy convention. You can use a totally different template system if you plumb it up correctly. Plus JSX can be used outside of React.
You hit on the two points that makes React what it is. A pure state -> ui abstraction and the ability for large projects or teams to use it efficiently.
The JS world is so much more hype driven than say ruby, every few months they will have a new framework that promises to solve all the problems in ui land or the backend. They write songs in its praise everyone worships it like this is the one true framework a panacea for all evils. And then when the hype cycle winds down a new framework emerges. I am totally bored of looking at this cycle for the past few yrs. This just leaves a ton of unmaintainable projects in its tracks because the devs have found a new toy to play with. I have seen clients struggle to find backbone devs because no body in interested in Backbone this is a repeated pattern among JS Devs.
JQuery -> Backbone -> [Tons of Backbone wannabe's written in Coffeescript Batmanjs/Bananajs/what not..] -> Angular -> [Angular lookalikes with tons of magic] -> Ember -> Meteor -> React -> Vue -> [Wait a few months new framework in the Pipeline].
Unfortunately very few want to agree to the truth.
I dont disagree, React has some solid underpinnings but for now VUE has some momentum, till the next one comes along. Google gave up on the idea long back. Google develops Angular but doesnt use it in any of their core products. They themselves use Google Closure library for gmail or word processor.
Isn't the new YouTube website running Angular? Please don't shoot me if I'm wrong, I don't have any citations, I just presumed (on phone, too lazy to look up).
Not according to Augery (angular chrome extension), but not sure if all evidence can be built out of the result.
However, mobile.twitter.com and facebook proper are using react. Along with Walmart.com and many, many others.
The biggest Angular app I've seen is probably grubhub, and there's some painful state bugs there... in fact I don't think I've ever seen an angular app (not using rxjs or redux) that doesn't have weird state management bugs.
I tried using Angular 1 when it came out and it seemed like too much work to learn for such a small benefit. I started learning React at the start of last year and have found it phenomenal. I am not comparing the two, let alone arguing in favour of Angular. I just thought with the swap to Material Design (and async loading data and components) in YouTube, that they were using Angular. Your opinion about YouTube using Angular (or not) has more citation and authority than mine, so I will assume in the future that YouTube does not use Angular (without certainty, of course).
Sort of tangential, but React is way less painful with TypeScript/tsx. I combine that with an IntelliJ IDE (RubyMine specifically) and honestly, it's a lot of fun to write web apps this way. (Maybe that's because I come from an iOS background?)
205 comments
[ 1.8 ms ] story [ 124 ms ] thread1. Every document has a root node. <div id='app' /> 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 your class instance.
React allows you to compose things. Make something once and use it everywhere. You write much, much less code. You get lifecycle hooks for when things mount, update, unmount. You get easy templating in JSX. You can also ditch the whole thing for Inferno if you care about having no lisence or company behind it.
You also get amazing libraries for state management and async via reactivex.
I can usually jump into someone's react code and get what's going on pretty quickly unless they did something really gnarly with incredibly nested props. Even then, at least I still know where to drill down. With jQuery soup, you didn't get that luxury.
Being able to have an entire team know how to build components and provide them with functionality is an incredible advantage. I don't love everything about react either, but the ecosystem, somewhat enforced convention, tooling, etc - it's worth it (so far).
I love some things about Vue, but it isn't a silver bullet either. Brad seems to be pretty butt hurt about react. If you've worked on a large team without something like react, then worked on one with react, it really shines. It's a major productivity booster.
It's not perfect, but it's very good.
jQuery + co. have very consistent "look and feel"
I'm realizing now that this isn't a fair comparison. React 'wins' here largely because it has a smaller scope. It's for giving functionality to templates built in the library using a certain approach. jQuery was far more open ended and far less opinionated. That was as much it's strength as it's weakness.
It's definitely not a direct comparison. But I do think react is a nice safe tool for larger teams.
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.
Just like jQuery is great to do some quick and simple dom manipulation.
I've tried both opposites; I've been on teams working on large apps in jQuery, and it's hell. And I've also used React to implement simple little things, and it's also hell (part of it for reasons Brad mentions in this article).
I don't have much experience with Vuejs but I've been using it instead of React recently, and it's refreshing indeed. Just like jQuery you can just import it with a script tag and start doing some dom manipulation and it makes the code much cleaner than jQuery.
And as others have said, jQuery is not bad - it's awesome. I guess it didn't age very well with the JS env evolving, but it's great.
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.
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.
With JQuery you're signing up for manual DOM manipulation. It's a challenge to scale that for what's now considered table-stakes for web apps.
This is probably the only real concern I see.
jQuery is a library for DOM manipulation. It can co-exist with many other libraries.
React is an entire framework.
These days you need jquery less because browsers are more standards compliant and css animations basically work.
The trick is about using the right tool for the right job.
We have several large react applications - these are user-interaction heavy rich single page apps.
But we also use vanilla html and jquery dom manipulations in many other places.
The people for whom ripping out React or Vue leads to a blank page are those who wanted an app from the ground-up.
If anything, React is losing because it doesn't include enough out of the box. If you wanted to build a news widget, fine. But if you wanted to build an app, you have to start putting pieces together from 3rd parties (or write your own custom pieces). That's not what a framework sounds like to me, that sounds like figure-out-your-own-framework, and I think that's why Vue is winning.
Create React App was a very late response, and I still don't think it's as good as Vue's up-and-going tooling experience.
With jQuery, you're likely building it with html and using jQuery for user interactions or animations (I know - not always true - constructing the markup with $('<tag>') is also useful). So its easier to rip out jQuery and replace it with - say - document.querySelector - or whatnot.
I personally think React is overkill if you're pulling it in to do a small widget on a larger non-react page
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 was https://reactjs.org/docs/add-react-to-an-existing-app.html, which reads like it would make sense to an xperienced React developer, but not someone coming new to it.
Right now I'm moving an old webforms project to .NET Core + MVC / Razor and am going to try building out some components in both react and vue to see how it goes.
As for some links:
Here is slightly old .NET/MVC5 article: https://www.red-gate.com/simple-talk/dotnet/asp-net/a-real-w...
Vuejs for .NET/MVC5: https://medium.com/corebuild-software/vue-js-and-net-mvc-b5c... https://medium.com/@hyounoosung/integrating-vue-js-2-0-to-ne... https://medium.com/@disjfa/using-vue-js-in-existing-websites...
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...
Originally, jQuery's big selling point wasn't that it handled animations, it was that it gave you a query selector, and one that could be used in any browser. jQuery predates the release of chrome, and came out a few years before document.querySelector was added to Firefox and Chrome was released.
jQuery was monumentally more useful for common actions compared to its contemporaries, such as Dojo, MooTools and Prototype.
I'm sorry but this is not a problem. If you commit to React then you commit to it. You are not suppoused to change it every other year.
Imagine a big C++ Qt application. Will you ever think of changing Qt on it, and expect no huge cost? No. That's unreasonable.
So what he wants is not only a cross-browser, cross-platform framework (and much more) but also a framework that is somehow "cross-framework"!!
This is really getting me. People, such flexibility and ubiquity is NOT FREE. People this days complain about the web being to complicated, and that it is a lot of complexity to make something "simple as a webapp". I agree, it is. But that simple multimedia webapp you get today works over a distributed network, in almost every platform, from mobile to desktop to almost everywhere. This kind of ubiquity will be unthinkable in the early 90s/2000s without investing on a huge number of experienced dev teams and a huge especialized codebase(s). Today some javascript framework and markup will give you almost the same product. Yes, I think the web ecosystem can be improved. A lot. And the end result is not always 1:1 comparable at many levels with what you would get back in the day with native apps and a load of work and experience. But still.
People complain but they don't know what they are getting.
same! Jquery is still quite useful and powerful. This is also what rails does for me; makes web development fun. Or highcharts making charts fun, or elasticsearch making search fun. To me that's a testament to elegantly solving a problem. I just don't get those fuzzies with react.
This isn't totally true -- if you really only wanted to implement a single toggle and leave the rest of the page alone, then you could replace just the relevant DOM elements with a container and render into that fragment of the page. (Though really I'd ask why use React if that's the only value you're getting out of it)
> 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. [...] Projects like Vue are showing that’s not necessary.
Except, Vue.js does require a proprietary format; all those v-* attributes and custom components will be need to be migrated if you want to switch away from Vue. Comparatively, React is better in this regard because there are multiple implementations of React (preact, inferno, nerv). Also, JSX is technically optional, and it's really easy to mix markdown, or other formats/templating engines into a React app to handle the content-heavy bits.
Wikipedia seems to agree with me [1], but maybe I'm misinterpreting it:
[1] https://en.wikipedia.org/wiki/Proprietary_software
Anyone who uses "the new jQuery" as some sort of insult (as it seems Sara did in her tweet) probably hasn't been a developer for more than a few years or is just trying to sound smarter than they are by bashing an easy target.
The reason jQuery got so popular is that it made common tasks so much easier than anything else at the time. Anyone who was doing web development before jQuery knows what a godsend it was at the time. JQuery was a fantastic leap forward for development at the time it was released.
JQuery didn't become bad, the rest of the development world caught up and made it 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 shared library, which meant developers suddenly needed to do dependency management. That is (usually) a bad idea. React absolutely does have that problem as well - probably to an even worse degree than jQuery widgets ever did.
This is kind of the same concern I have with Vue to be honest. I use Vue for prototyping and will probably use it in some final apps as well. But I'm probably not ever going to use a component that someone else has written if it relies on Vue.
IMO Lodash went the right direction with this. A component or library can depend on Lodash, pull in just the functions that they use for a final build, and then nobody else in the entire dev toolchain needs to know or care. No risk of conflicting dependencies, build size stays low, etc...
I kind of wonder if the problems Vue solves for me could be solved better by a smaller, lodash-style library instead of a framework.
I'd never say don't use jQuery, and it does support some options for a minimal footprint, still there's smaller options that probably have all you need.
I could learn and use $latest_thing, and maybe it would be great. That will triple the time taken to develop, but whatever. However in a couple of years time when I come to need to write something else, $latest_thing will be old hat, and replaced by $shiny_and_new. Rather than having 10 years of nice simple code based on jquery, I get some based on Angular, some on React, some on Vue, some on Meteor, or whatever.
I'm not a programmer, I'm not a wireman, and I'm not a carpenter. I program in the same way I'll run a network cable or get a screwdriver out, it's a tool I can use to solve a specific task. I like tools that are the same, year in, year out.
That's not to say the latest frameworks aren't all great, if you're building something for a million users and want to take advantage of shiny new features that's great, but for those that aren't, there's still a place for boring old things in a large part of the computer industry.
That's fair.
> The other comparative downside of JQuery was that components started to rely on it as a shared library, which meant developers suddenly needed to do dependency management. That is (usually) a bad idea. React absolutely does have that problem as well - probably to an even worse degree than jQuery widgets ever did.
I totally agree with that, but I don't think you can use that as a knock against jQuery, react, or vue. I think developers, especially js developers with our love of pulling in external packages, have yet to find a great solution for dependency management.
> IMO Lodash went the right direction with this. A component or library can depend on Lodash, pull in just the functions that they use for a final build, and then nobody else in the entire dev toolchain needs to know or care. No risk of conflicting dependencies, build size stays low, etc...
I think lodash can work that way because most of its functions are small and self-contained. It's easy to just bundle in a few select functions when they functions are 100 lines max and don't need the rest of the library, but I don't think React or Vue could use a similar approach.
Who is going to want to use a dropdown component that has the entire React 15.3 lib bundled into it?
And who would want a dropdown component that has its own little rendering framework inside when you are using React for that?
The problem is if I need to manage the dependencies between multiple components - if there's a singleton dependency that multiple components are accessing. It's dangerous not because it's a dependency, but because the components consuming it may have different requirements or assumptions that conflict with each other, and I won't be able to fix those assumptions without forking the components.
This is where you would run into scenarios where somebody's widget was only jQuery 2.x compatible, and somebody else's wanted to add custom events that interfered with scroll direction or something... I still have horror stories about trying to debug that kind of crap.
Shared dependencies really seem like they should be a good idea, but unless you're willing to fork other people's code or your app is only going to have a very short lifespan they're usually more trouble then they're worth.
To be fair, I think jQuery eventually did go the same way as Lodash. I haven't checked in a while but I'm pretty sure that they now have a way to generate a custom build of jQuery to be locally scoped to whatever thing you're building.
It would be tough for Vue to go the same route (still much easier than React) but that just means that you should probably only use Vue for your own projects and should avoid importing 3rd-party components that rely on having it globally accessible.
...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?
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 end up with the nightmare of having to do package management because widget A and widget B interfere with each other. This is the same exact reason why it's good practice to avoid defining JS variables in the global scope.
Peer dependencies are just global variables at the package level.
To be clear, the people who built NPM were not idiots. Node handles packaging really intelligently - via a node_modules folder. There was a lot of thought put into how to make this system flexible: for example, you can have a node_modules not just at your root, but even in subfolders. This allows you to have custom implementations of a dependency that's isolated to a single folder in your source code, and to easily check your implementation directly into your VC.
None of that is accidental - the Node developers learned from languages like Ruby and Python, where gems and packages would be installed globally to the system, not locally to your project. They wanted a system that got rid of the majority of peer dependencies.
Jump outside of the web world and you'll see the same trend in the broader software ecosystem as well. The big hotness around Linux packaging right now is Flatpack, which is mostly copying Node's strategy of bundling dependencies into the app and then de-duplicating them after installation. Docker is an even more extreme example of this trend.
Peer dependencies are sometimes useful, and they're an important concept. But people use them and abuse them too much. They sound like they should be a good idea, so developers often don't realize the downsides until after they've gotten bitten - and even then they often just assume they were using a bad library or something.
9 out of 10 times you should avoid them, and you should avoid frameworks that introduce them.
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.
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.
First it took about a decade of browser and ECMA very intensive development to actually make it unnecessary.
> it is becoming difficult to convince new developers that React may not be necessary for their next project.
Give it a decade for the web "components" to actually become composable and for inventive and useful native language built-in solutions to state management to happen before you start advocating people out of React. Until then telling people they might not need React is not a step forward but backward. Imagine people saying "you might not need jQuery" in times where IE reigned and browsers were wildly incompatible.
When querySelector and ES6 came about, I found myself not needing jquery by default.
Also, a slow loading JS lib wasn't as much of an issue 5-7 years ago when jQuery was really in its heyday. Web pages were simpler and more information based back then and it was usually a requirement that they be useable without javascript. Since you are (should be) loading jQuery at the end of the page (or asynchronously) the page should render just fine without jQuery and probably would have been loaded by the time any user interaction would have happened.
Also, since users were on computers (mobile wasn't really a thing) and data usage wasn't a limiting factor (most plans were unlimited), loading extra data didn't really matter that much.
Yeah, jQuery had extra functions that you didn't need, but it didn't really hurt much at the time and there wasn't really a better option.
Not to mention it was recommended to point your "src=" to one of the common cdns, so it would likely already be in the user's cache from some other website that used the same jquery version.
I cant even name a similar piece of software in web development history that is as important as jQuery.
Despite Web development as a whole, back end or front end is still no where near being good enough, it is still many times better then the old days.
Php?
Apache?
But jQuery wasn’t just a tool, it was also community. What that community did/perpetuated was some pretty bad and ill advised practices. Plugins for everything - the old $.sum(2,2) joke applies here. DOM for state. Even sanctioned projects like jQuery UI were guilty of some terrible, awful practices.
That said, React isn’t the new jQuery, it’s the new Backbone. Backbone lacked so much - and did so little - that it’s deficiencies needed to be made up for by “other” tooling. As a result, there was O(n) ways to “Backbone” – making backbone apps very difficult to study/build/maintain.
React is fine. The community just needs to coalesce.
Edit: typing on my phone; and am lazy
react, redux, thunks (with async functions), fetch, material-ui ... those will get you a LONG way to where you need to be with react.
Yet, Sara is neither of those, she's a well respected developer, who's work with CSS and SVG is world-class.
If she's using jQuery as a comparison she's doing it from a place of experience and knowledge
However in my experience, a couple of things were key to creating a negative view of jQuery:
1. Security and unsafe defaults, for example: evaluating remote JavaScript by default [1]; and unsafe DOM parsing by default [2]
2. Not really to blame on jQuery, but its ease of use for DOM manipulation led to programming patterns that aren't easily scalable, for both code and performance
[1] https://nvd.nist.gov/vuln/detail/CVE-2015-9251 [2] http://api.jquery.com/jQuery.parseHTML/
Times were different
More than anything, the crazy thing for me is that jQuery seemed to have been there from the wake of the web, when it came out only one year before the iPhone.
React is in a similar boat - it provides a far more pleasant experience keeping the DOM in sync with your application state, in a way that Web Components don't (although they have other advantages that make them great when used together with React).
I would understand if comparing VueJS with jquey. Even if they are very different, the philosophy is the same: a small elegant easy to use versatil tool.
The amount of js code to make even basic things work is high, and with so many different styles of writing react/js code, large codebases require significant effort to keep maintainable.
Which is to say, with this much effort put into structuring maintainable react js code, one could pretty much develop in any js ui framework (including jquery, backbone or none whatsoever) - since little of this effort is dependent on react, or made easier by it.
Or the more general problem of not knowing the difference between store state, local component state, and component instance state (the actual JS object's properties.)
The new Unstated library leveraging the next Context API is a nice balance I find for state management. It basically just mirrors Reacts setState style update system. Although you do lose the single source of truth pro of Redux.
It's not something you can easily implement yourself either.
That's the main part that makes React code maintainable.
I don’t think the same could be said of your random JQuery or. Backbon based project
React works better for teams working on applications that need build tooling and dependency management anyway.
Angular, frankly I don't see why anyone would pick it over the other two. Yeah, it's got more in the box, but that bigger box takes 4x as much effort to lift off the ground.
> Don’t @ me I’m not trying to start a controversy. I’m only stating an observation.
https://twitter.com/SaraSoueidan/status/1001189524477743105
React, like jQuery, could have done more to keep people from writing bad code. With React, they made the same mistake that Angular did, which was to impose strict rules on all developers. Vue, to its credit, doesn't make this mistake. It's much less opinionated about state management.
What does that even mean?
I don't disagree but will push back slightly on the appeal to authority. I think in JS land we're getting a little too carried away with celebrity developers (I often joke about "what would Dan Abramov say?" and it's only half-joke). I've been trying hard to focus on the ideas, without regard from who said it.
React is a decision. I'm speaking in broad generalizations because I don't know how to put this principle into more specific terms, but good programmers should avoid making decisions for as long as possible. This is the same reason why I caution people against using test frameworks. Most of the time when you start coding an application you won't have enough information to make any educated decisions about it.
This is a huge advantage that Vue has over React. You can use Vue for just one component out of your entire app and it's fine. It is fairly easy to separate it from all of the rest of your application logic and that means by extension it's fairly easy to rip it out later. Or at least... easy enough.
It's still not perfect. I dislike how hard it is to make its templates fail gracefully when Javascript is disabled. I dislike that it uses setters in its data model, which discourages immutable programming. I dislike a few other things as well.
At some point, someone will make a better framework than Vue, probably by building something even smaller and even more focused than Vue already is. But in the meantime, if you are going to use a framework for two-way data bindings, you should probably be using Vue instead of React. Opinion me, of course.
ReactJS is a power tool and it takes some learning.
If your primary concern is about your initial learning curve then you should look elsewhere such as VueJS but I'm glad of the power of ReactJS.
Changing class to className is not a big deal, nor are the minor other bits and pieces mentioned in the post.
I prefer vue, but I dislike that it’s essentially a one man show.
And when compared to React, he's absolutely right.
it is as if some react developer sat down and said, “how can we make this even simpler so that even my grandson can do it.”
i appreciate when we have guys like the authors of Vue come forward driving the community and taking web development to the next level giving us a more elegant solution.
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).
There are many big companies and startups who switched to Vue and loving it so I would say your point is moot.
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.
I was more into those two but jQuery made everything dead simple.
A lot of the mootools team moved into React. At least the ones I was familiar with.
I totally agree, and in fact I would take it a little farther and say it's making functional programming mainstream on the backend as well. Many people I've worked with got their taste via React/Redux and then started adopting things like Elixir/Phoenix for the backend.
Maybe it's an overstatement, but I credit React with driving at least some of that.
You hit on the two points that makes React what it is. A pure state -> ui abstraction and the ability for large projects or teams to use it efficiently.
JQuery -> Backbone -> [Tons of Backbone wannabe's written in Coffeescript Batmanjs/Bananajs/what not..] -> Angular -> [Angular lookalikes with tons of magic] -> Ember -> Meteor -> React -> Vue -> [Wait a few months new framework in the Pipeline].
Unfortunately very few want to agree to the truth.
Reference: https://youtu.be/-HUHRRYQl5k?t=2m4s
However, mobile.twitter.com and facebook proper are using react. Along with Walmart.com and many, many others.
The biggest Angular app I've seen is probably grubhub, and there's some painful state bugs there... in fact I don't think I've ever seen an angular app (not using rxjs or redux) that doesn't have weird state management bugs.
Anyway, I recommend giving this setup a go.
He's given hundreds of talks all over the world about a component-based approach to style guides in web, but yet cannot fathom the need for React.