http://elijahmanor.com/react-file-size/
Looks to be around 45KB gzipped now, to say nothing of the parse time. It's becoming a pretty huge dependency and I wonder how much of it 90% of projects really use. Personally, I've been getting along just fine with Preact, which matches a lot of the API and is just 3KB gzipped:
You can see the latest code here: https://github.com/lhorie/mithril.js/tree/rewrite
The main highlights are improved performance, modularity and API design. The `render` module - which is analogous to React/Preact - is about 3kb min+gzip and has support for fragments, lifecycle hooks for animations among other things.
Other additions to the framework include new utilities for testing, bundling, and optional reactive streams.
It's currently in release candidate status, but there are already some applications in the wild using this new version. I'm just finishing up writing documentation before the official release
i.e. how many milliseconds are we losing in parsing time or download time?
I imagine it may matter in a mobile browser but for a desktop app my intuition tells me the difference is not noticeable.
ThreadItJS[1] has some tests for this (scroll down to the "Dependency load and execute" section). On my desktop, loading React on a clean cache takes a little over 300ms. Ember is over 600ms. This is just to get to a point where you can start a hello world with the framework on a powerful desktop machine with fast internet.
Another anecdote: one project at my day job is using the Auth0 lock library (long story, don't ask). It's basically a login widget, but it bundles all of React and a few other libraries, and it's over 1MB of Javascript (uncompressed). Is the site still usable? Sure, I guess. Could it be faster? Absolutely.
Basically it comes down to a trade-off between developer comfort and a commitment to give users the best experience they can get. You just gotta draw a line somewhere. The thing is that many people justify the trade-off of React/Ember/Angular/whatever's code size by saying it provides benefits in maintainability, etc, but the reality is that for a lot of projects, you could compromise less on the user experience side and still have good maintainability with smaller libraries.
As I recall, one of the other stats they cited is that mobile traffic is outpacing desktop traffic, so unless you're designing an app that really only works on a large screen, your users may be more mobile than you imagine. Facebook is a desktop site (most of their mobile traffic is in native apps), so they don't have the same incentives to optimize React for mobile that other developers might.
Time lost can vary wildly. 1-10 KB seems like nothing but the collective effect makes a difference if you have enough users.
But I think the real reason people are complaining about size is not the potential increase for each version but the trend. Increases will accumulate unless something is actively done.
As such, I think the push-back is fine, although I'm personally okay with the size.
Server-side rendering fixes the issue of time to first pixel. I think we don't really need to worry about a 10KB bump, especially considering how many websites are serving ads to mobile which are sending over MUCH MORE DATA.
I have been traveling around to many 3rd world countries, and when I hit a website thats loading a little slow you know what I do? I wait for it to finish loading, or I refresh. One of the biggest things a site can do to improve speed is picking a good CDN (Cloudflare).
EDIT found it:
preact-compat adds somewhere around 2kb to your bundle size, but has the advantage of supporting the vast majority of existing React modules you might find on npm. The preact-compat package provides all the necessary tweaks on top of Preact's core to make it work just like react and react-dom, in a single module.
For reference: Total minified size is now at 145.2 KB for React + DOM versus 149.52 KB in 15.3.2. That's a -2.89% reduction.
- Classical Components, with lifecycle methods and state
- Stateless Functional Components, which are functions that accept props and return JSX.
All the state you have in a functional program is usually your cal stack and/or message queue.
All of this creates an illusion of speed, and people are generally fine waiting, as long as they are shown the progress bar.
For development, one thing that immediately comes to mind is that React has PropTypes, which help to enforce types being passed from component to component. Preact doesn't have that.
EDIT: damn it, that's a bad example as well, because it would work fine if you use React for dev (which takes className) and Preact for prod (which uses either).
I still think it's a bad idea, though.
(sizes react-both)
=> {:br11 [34761 "0.240"], :gz9 [41790 "0.288"]}