4 ms·

> 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

> 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?

williamxd3 8y ago
> 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?
- tracker1 8y ago
  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.
  - williamxd3 8y ago
    Yeah, Preact is great for standalone widgets
danShumway 8y ago
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.
eropple 8y ago
> 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?
- danShumway 8y ago
  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.

williamxd3 8y ago

> 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?

tracker1 8y ago
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.
- williamxd3 8y ago
  Yeah, Preact is great for standalone widgets

danShumway 8y ago

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.

eropple 8y ago

> 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?

danShumway 8y ago
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.