4 ms·

This is a bit off topic, but whenever I'm tempted to add React to a page or incorporate it into my single page app, I keep asking: is it worth roughly doubling

This is a bit off topic, but whenever I'm tempted to add React to a page or incorporate it into my single page app, I keep asking: is it worth roughly doubling the size of my javascript payload (130 kB React + 96 kB jQuery for AJAX + X kB business logic)? I keep backing off, and sticking with jQuery/Backbone. One solution would be using a lightweight AJAX library in place of jQuery, but I haven't found one that is widely used, well maintained, and recommended. Can anyone recommend one? Or in 2015 should an extra 130 kB be considered a non-issue?

aturek 12y ago
If you use a CDN (or use the public CDNs that many of these libraries have) it's not 130 kb, it's a network request + 304
- billsimpson 12y ago
  Yes. The issue for me has been that I bundle my libraries with my app using, for instance, Browserify. So whenever I update the app (which is fairly often), the entire bundle needs to be redownloaded by all clients. I guess the obvious solution is to unbundle the larger libraries that don't get updated frequently.
  - cshenoy 12y ago
    That is absolutely the solution. Don't bundle jQuery and other big libraries into your application code. It can drastically improve performance.
    - billsimpson 12y ago
      In that case, must you create one or more separate bundles to contain your vendor libraries? I suppose there's no way to directly integrate a jQuery library hosted on a public CDN.
caseywebdev 12y ago
I'm a fan of [superagent] for AJAX. The React lib is big, but its declarative nature has lead to fewer and easier-to-diagnose bugs for us, which is ultimately a win for the end user. I've been using it exclusively on new projects for months now and I'm a Backbone.js core contributor ;) superagent: https://github.com/visionmedia/superagent https://github.com/visionmedia/superagent
- nogridbag 12y ago
  I've been toying with mercury, which is similar to React/flux, and had the same dilemma as the parent. It seems a bit strange to use a really light weight library like mercury and then throw jQuery into the mix. I also checked out superagent and it seems to have a good amount of dependencies. I was thinking of simply wrapping XMLHttpRequest with the promise lib of my choice. This link seems relevant... http://youmightnotneedjquery.com http://youmightnotneedjquery.com
avinashv 12y ago
Have you tried Zepto[1]? It's ~9kb gzipped, and is compatible with a lot of jQuery's API. I've found that for a lot of the stuff I used jQuery for, it's mostly a drop-in replacement. [1]: http://zeptojs.com/ http://zeptojs.com/
jfhollingworth 12y ago
I've used github/fetch [1] which is a polyfill for the upcoming fetch standard [2]. If you ever want to go beyond this its one of state sources in marty.js [3] [1] https://github.com/github/fetch https://github.com/github/fetch [2] https://fetch.spec.whatwg.org/ https://fetch.spec.whatwg.org/ [3] http://martyjs.org/guides/state-sources/http.html http://martyjs.org/guides/state-sources/http.html

aturek 12y ago

If you use a CDN (or use the public CDNs that many of these libraries have) it's not 130 kb, it's a network request + 304

billsimpson 12y ago
Yes. The issue for me has been that I bundle my libraries with my app using, for instance, Browserify. So whenever I update the app (which is fairly often), the entire bundle needs to be redownloaded by all clients. I guess the obvious solution is to unbundle the larger libraries that don't get updated frequently.
- cshenoy 12y ago
  That is absolutely the solution. Don't bundle jQuery and other big libraries into your application code. It can drastically improve performance.
  - billsimpson 12y ago
    In that case, must you create one or more separate bundles to contain your vendor libraries? I suppose there's no way to directly integrate a jQuery library hosted on a public CDN.

caseywebdev 12y ago

I'm a fan of [superagent] for AJAX. The React lib is big, but its declarative nature has lead to fewer and easier-to-diagnose bugs for us, which is ultimately a win for the end user. I've been using it exclusively on new projects for months now and I'm a Backbone.js core contributor ;) superagent: https://github.com/visionmedia/superagent https://github.com/visionmedia/superagent

nogridbag 12y ago
I've been toying with mercury, which is similar to React/flux, and had the same dilemma as the parent. It seems a bit strange to use a really light weight library like mercury and then throw jQuery into the mix. I also checked out superagent and it seems to have a good amount of dependencies. I was thinking of simply wrapping XMLHttpRequest with the promise lib of my choice. This link seems relevant... http://youmightnotneedjquery.com http://youmightnotneedjquery.com

avinashv 12y ago

Have you tried Zepto[1]? It's ~9kb gzipped, and is compatible with a lot of jQuery's API. I've found that for a lot of the stuff I used jQuery for, it's mostly a drop-in replacement. [1]: http://zeptojs.com/ http://zeptojs.com/

jfhollingworth 12y ago

I've used github/fetch [1] which is a polyfill for the upcoming fetch standard [2]. If you ever want to go beyond this its one of state sources in marty.js [3] [1] https://github.com/github/fetch https://github.com/github/fetch [2] https://fetch.spec.whatwg.org/ https://fetch.spec.whatwg.org/ [3] http://martyjs.org/guides/state-sources/http.html http://martyjs.org/guides/state-sources/http.html