React v15.0
facebook.github.io
facebook.github.io
https://github.com/facebook/react/issues?q=is%3Aissue+is%3Ao...
I think a lot of the core folks also hang out on IRC at #reactjs on freenode.
Specifically, in the old way, there were spans, and we had css styles targeting the spans sometimes.
That's the only time I'm targeting them... To fix what they screw up.
react.min.js is now 145.4kb. For comparioson, angular.min.js is 155.2kb. One of React's biggest selling points was that it was much smaller than Angular/Ember/Backbone etc, but I'm not sure that argument can be leveraged anymore. I think React is a culmination of some great ideas, but in my view this is a big step back. Especially since Angular/Ember/etc. offer a lot more tools out of the box.
I don't intend to tell anyone here that React is a bad framework because it's not, but I think it should be a big priority to tighten down the file size. When React is big pretty much all their selling points go out the window.
Perhaps they can split files up so you can just import the APIs you want. I wonder how much that would help with the bloat.
I feel like some of the smaller VDOM frameworks like Cycle/Mithril/Riot are a lot more appealing now, since they focus on small file size and low bloat.
(Also note that growing framework code can reduce your app code size overall; I don't want to make specific claims about React but at Facebook we often see code size increase when 10 people all try to avoid importing the same module and end up reimplementing 20% of it 10 times and increasing the overall size.)
I haven't looked lately at the biggest contributors to React's file size. We're certainly willing to try to modularize more when it makes sense, but we do that more with an eye towards developer flexibility rather than runtime efficiency.
There may be some ways to drop some dead code that we haven't eliminated efficiently yet. Here is a recent example I found that drops 1kb: https://github.com/facebook/react/pull/6401
It would be cool if somebody in the community could spare some time to look into the biggest factors as well.
We definitely want to have a good explanation for where those bytes are coming from. That is, what React gives you for them. I plan to write a high level overview of React internal implementation so I might as well look at relative size cost of different pieces of it as part of my exploration process.
In any case don't forget 43k is less than many images.
We are not in a perfect place right now but we are not just brushing it off either. As I said in another comment, at least having a good explanation for these bytes is something we plan to do in the following couple of months.
There are some other improvements to startup time that we are considering such as bundling to a flat file and removing some dynamic overhead (https://github.com/facebook/react/issues/6351). Also the plan is to have React go through significant changes this year (adding an incremental reconciler) so right now is not the best time to optimize the script size.
But yeah, this is on our radar. Community help identifying specific issues is also very welcome.
I would love this! I really like how you basically re implement redux in the first few videos of your EggHead Redux tutorial. It really took my understanding to another level.
That said we will continue exploring how to drop some weight from React further down the road. This is not a priority right now because some large changes are coming relatively soon to React (work on incremental reconciler) so it would be unwise to focus on size optimization before a big refactoring.
I think that we will be in better position to consider what can be removed or separated after we ship the incremental reconciler. Hopefully this will happen within a year. For now I don't have a good answer to this but I'll try to at least provide a summary of how large different pieces are when creating a high level technical overview of React next month.
for comparison, mithril is 7.8 gzipped. i don't see react getting that small, but i'm sure there's room for slimming down, perhaps signicantly.
It's certainly my experience that using React over a mess of jQuery and its plugins leads to smaller file-sizes when enhancing functionality on a single page, but when you're using React (with Relay, React Router etc) to build the entire site, you end up with enormous payloads.
Let's ignore the gzip size for now, since there's more to file-size than just data over the wire. A production build of a simple React + Relay project (i.e. one that does practically nothing) is around 1mb in size. We can't reliably do server-side rendering with Relay yet, so this is 1mb that must be downloaded and executed before you can see and do anything at all.
This is a bad place to be.
Nevertheless it is an ecosystem precisely because you get to pick the pieces you need. For comparison, Redux + Redux Thunk is about 3kb. Immutable is not required either. Of course your app code would have to include data fetching logic which would make it much larger. But those are all tradeoffs you have the power to make.
* It helps us justify to our bosses why a 350kb library is needed instead of a 3kb one.
* It helps us understand the overall picture of JavaScript today, what kind of problems we're having to solve that could eventually be better solved by browsers themselves.
* It just makes me more comfortable in my decision to send a lot of JavaScript over the wire.
Without such an explanation, we're essentially taking it on faith that these libraries are written by people who value good quality lean code.
> Without such an explanation, we're essentially taking it on faith that these libraries are written by people who value good quality lean code.
We built something that works for us, balancing feature set, runtime performance, maintainability, code size, etc. We're continually focusing on performance - see https://github.com/facebook/relay/blob/master/meta/meeting-n... for more about what we're focusing on - but so far file size has not been the most impactful thing to work on.
As far as understanding Relay's functionality, we've covered the more obvious aspects in talks (http://facebook.github.io/relay/docs/videos.html) and in a conceptual overview (http://facebook.github.io/relay/docs/thinking-in-graphql.htm...). But an analogy to React is probably simplest. React converts declarative UI descriptions into imperative updates on the DOM. Relay is superficially similar - it converts declarative data descriptions into imperative calls - except that there is no DOM for data, so Relay also implements the query representation, object graph for cached data, networking, mutation queuing & rollback, etc.
We're also giving a tech talk about Relay internals (https://relaytechtalk.splashthat.com/) which may be of interest.
If you are at a point where your task doesn't justify these abstractions - don't use them.
Find the right tool for your job.
My initial reservations about the amount of boilerplate in setting up Relay, were in large part due to the server-side half of the equation. Since switching to building my backend in a different language (now using Elixir with absinthe, rather than node and graphql-js) I've found my productivity has skyrocketed.
At this point the overhead in terms of file-size (and the still pending support for server-rendering) are the only things giving me pause for thought.
If the bulk of your bundle size comes from page-specific functionality, then you can easily benefit from code-splitting and tree-shaking techniques. But those techniques won't help you at all when it's your core architecture that are enormous, because every single page on your site depends on it.
With that said React + ReactDOM is 180kbish unminified.
I can't find Relay's size as a single file. Is it really over 800kb?
I still can't figure out where the hell I saw the smaller numbers earlier. I must have been drunk.
However, my dev build is 9mb, my production build is 1mb. So when i'm talking about baseline filesize for a React + Relay project, I am talking about production builds. Not all of this 1mb comes from those two libs, but they contribute very heavily towards it.
However, I think this is becoming less common with the increasing popularity of module bundlers like webpack. It's still possible with webpack [3], but it's not as easy as a 'npm i react' and 'import React from "react";'.
That said, a module bundler could easily automatically swap out local modules for modules hosted on CDNs in production builds (with fallbacks in case the CDN is down). I'm a little surprised this doesn't seem to exist yet, at least for webpack.
3. https://webpack.github.io/docs/library-and-externals.html
e.g. <library name="react" version="^5.0"><script src="https://cdn/react-5.0.8.js"></script></library>
import _ from package 'github.com/lodash/lodash/tree/4.8.2';
import $ from package 'jquery.com/version/2.2.0';
@import package("github.com/twbs/bootstrap/tree/3.3.6");<script src='...' checksum='2fd4e1c67a2d28fced849ee1bb76e7391b93eb12' />
Which would allow the browser to use cached copies of files even if from different domains. Not sure where I saw that.
That attribute is meant to verify resource contents. The strategy of using it as a cache ID is still being discussed, but last I looked into it, there were some cache poisoning concerns.
You might find this thread useful: https://news.ycombinator.com/item?id=10311020
I think what's needed is a heuristic webpack-loader, where you can specify both a self-hosted URL and a cdn-URL. It could work like this:
* Load the CDN version and fallback back to the self-hosted version, if it doesn't exist or takes too long. * In certain cases (probability, origin of request, etc.) load the self-hosted version first, but load the CDN in the background, so it get's cached.
I strongly disagree. If React's API were to get all big and complicated, that would be a concern. The tight scope and clean interface are definitely selling points for React compared to many larger (in scope and interface) frameworks and rendering libraries. But I really don't care about the file size, as it's far too small to be anything but noise in almost any web app where it's worth using a tool like React at all, and it's going to matter less anyway as JS build tools get more sophisticated and connection speeds increase over time.
Is this related to the bandwidth costs you incur in aggregate? I guess I too would be mad after converting all of my image assets into vector and CSS3 concoctions only to have my site size foiled by a dependency. But in reality one image is much larger than this.
You can't be serious. React's selling point for me is that it enables me to write web apps in a whole new way. Coming from an Angular background it's amazing how much cleaner, better and more pleasant it is to work with React. To bring up file size as the main selling point is just ridiculous.
That said, I've been tinkering with this project on the side:
https://github.com/developit/preact
It's a 3-4K React-ish library. Pretty impressed with it so far, but it does lack the dev tools, event normalization, etc.
https://github.com/Microsoft/TypeScript/issues/7270
TLD'R: React 15.0 broke TSX in typescript but the workaround is easy.
Typings still has 0.14 tagged as the latest - I'm guessing we need an update there too?
To be clear: I do like TypeScript and use it almost exclusively on the server, so this isn't a case of me "not liking TypeScript". It's the combination of the two. Basically, all of the stuff I did to keep TypeScript happy when using React was worthless overhead and brought nothing but pain, warping the codebase horribly. The JavaScript version with React was smaller, lighter, and had way less cognitive overhead. YMMV.
Really happy to see the SVG support, and the continued fast-paced development of React. Onwards!
Long story short, I took 40+ hours of Angular 1.5 code and converted it to React code in a single 8 hour work day without any prior experience in React. I was both impressed and giddy. The next day I merged that reactify branch into my develop branch, and continued on.
I feel that React does components better. I feel that Angular 1.5's introduction of the component sugar over top directives and even components in Angular 2.x just felt shoehorned in as an afterthought.
I couldn't even spend a day trying to figure out how to componantize this app in Angular 2.x let alone 1.5.
Now I'm head deep in learning as much about the ecosystem as I can, Redux, Relay, GraphQL, all that good stuff. I've officially ditched Angular for the React ecosystem.
I should mention that Angular 2 is quite a work in progress currently - even though it has the beta label, it still is very much far from production ready IMO. Components in Angular 2 are largely well conceived, excepting the interactions with inputs and outputs and how they interact between reusable components. React was cited by an Angular team member to me as being vastly easier to use when it comes to intercomponent communication currently - I trust the Angular team will eventually get it right, but for now there are certainly some holes.
That doesn't seem like a fair comparison considering that when you first wrote that code, you probably had to figure out things unrelated to whatever framework you were using and didn't have to deal with that aspect when porting to React.
For example, if I rewrote a Django app in Pyramid, it wouldn't take as long as writing the original app even with the overhead of learning Pyramid, because I've already figured out the functional aspects of the app.
Generally speaking, learning frameworks isn't the hard part of writing an app, unless the app is trivial.
I took it as a statement of "someone new to the framework, can quickly rewrite their old code" if they came from Angular.
Which is an important metric.
When I converted a Backbone app to Angular, it took 3x as long simply because of the amount of ceremony and process that I had to go through to do things the idiomatic Angular way.
React on the other hand, as a view layer, is so dead simple that you can internalize its workings within hours of study. The complexity with React comes with everything else---Redux, React-Router, GraphQL, CSS in React, etc.
None of that stuff is defined as part of the React framework itself, but that's the only way you can make a "fair comparison" to Angular which is a full-stack framework.
We also discovered that since writing components is so much easier in React than with Angular 1.5 we tend to write a lot more of them. This makes the components easier to test and has greatly improved reuse across the code base. Which in turn makes adding features possible that would have destabilized the old code base.
I did look at Angular 2 and just saw more of the same and didn't want to deal with it anymore. I found that I personally aligned well with the React ecosystem (Redux, JSX, CSS in Javascript) which probably colored some of my decision.
Yep. I spent a few days last week reimplementing a heavy part of our app in React, specifically because of this problem. "Make everything a component" is a great idea, but does not work so well in real-life Angular 1.5 when you're building a complex tree-like editor. The digest cycles grow longer and longer.
The code reimplemented in React is 30% smaller and 8x faster (with some other tweaks to cut down on the frequency of digest cycles). I'm really enjoying React so far.
In my opinion the biggest credit in this release goes to Ben who single-handedly turned around the internal implementation of React DOM to stop using ids. The big span change submitted by Michael was also possible thanks to Ben's work.
('cause the browser vendors have done a ton of awesome work speeding up DOM APIs in recent years)
https://blog.mozilla.org/research/2014/08/26/javascript-serv...
I'm curious though. I'll have to check out the source to see how it works in React now. You know, when I find some free time :)
https://developer.mozilla.org/en/docs/Web/API/Document/creat...
Nice. I currently use another functional reactive virtual DOM data binding mechanism and the data attributes everywhere was one of the things that didn't appeal about react. Since react is getting crazy network effects from community I might check it out for my next project.
As someone who focuses heavily on small page size, that's a pretty harsh regression. Especially when compared to all the other VDom frameworks like Riot/Mithril/Cycle which are all much much smaller and achieve about as much (in my opinion).
Going from 0.14.8 to 15.0 RC2 there seemed (subjectively) to be a noticeable increase in lag in some pages we're working on with a moderately large amount of content being rendered (things like tables or SVGs with a few thousand elements) when using development builds. However, looking at the changelog and how many new warnings seem to be included now, it doesn't seem unreasonable that those would slow things down a little overall even with the other changes.
As long as those aren't going to affect production, or if there were some final changes that have gone in now but weren't in RC2, it's not a big deal. However, if the React experts wouldn't expect a net slow-down even in a dev build, maybe we should look into it a bit more.
It's great for...
- Static D3 components or other such libraries (things like Backbone should work too!)
- D3 components with simple state and event interaction, like tooltips on charts
- D3 components such as progress bars that can be animated using react-motion, for example
It's not so great for...
- Physics based D3 components or anything using a lot of DOM mutation and state
- Linked to the previous one, brushing and filtering of selections using the built in stateful D3 tools
- Essentially: Anything with a lot of DOM mutation from timers, events or internal state will be hard to useation from timers, events or internal state will be hard to use
node
.on("mouseover", (d) => window.requestAnimationFrame(() => this.setState({selectedElementId: d.id})))
.on("mouseout", (d) => window.requestAnimationFrame(() => this.setState({selectedElementId: 0})))
node.filter((d) => d.id === this.state.selectedElementId)
.select("text")
.style("text-decoration", "underline")
.style("font-weight", 'bold');https://github.com/facebook/react/commit/b8ba8c83f318b84e429...
Since that change I've heard few complaints, and I know for a fact that several large companies who were previously unwilling to use it are now content with the language.
If React didn't have an explicit "grant" there would be an implicit grant. Is the explicit grant better than an implicit grant? It isn't because the explicit grant has what is known as a strong retaliation clause.
More info on weak vs strong retaliation clauses: http://www.rosenlaw.com/lj9.htm
React's patent "grant" gives you a license to React's patents. This sounds like a good thing, however, the "grant" has a "strong retaliation clause" which says that if you make any sort of patent claim against Facebook this patent grant automatically terminates.
Which means Facebook can now sue you for patent infringement for using React. You may think this is no worse than not having a patent grant at all. But that's not the case. If React didn't have an explicit patent grant then there would be an implicit grant which does not have any retaliation clauses, and cannot be revoked.
If you work for a software company and your company has patents then keep in mind that by using React you are giving Facebook a free license to your entire patent portfolio.
I'm not a lawyer. My understanding is that this is hypothetically possible but stands on shaky legal ground and has no legal precedent. Whether or not an implicit grant exists seems to depend on who you ask. This is apparently why GPLv3 includes an explicit grant.
It could also be that there aren't any patents that cover React. I don't personally know of any that do.
I am not a lawyer either, but I think the idea of implicit grant is compatible with common sense.
> Wherever possible, make sure you have an explicit license to any necessary patents held by the licensor.
Then it goes on to distinguish between weak and strong grants.
I think you mean weak, not implicit. AFAICT, there isn't an implicit grant with patent law, because the default is that you're infringing without an explicit grant.
The theory behind implicit patent licenses is that the licensee (often the buyer) will have some idea about which rights they have to the thing they are licensing, absent any other agreement. For a software license like the 3-clause BSD, this means that if they are licensing the software from the holder of the patent, they can reasonably expect to not subsequently be sued for infringing on the patent while following the terms of the license.
Omitting any kind of patent mention from your product's license, and later claiming infringement for reasonably expected use, would look subversive and generally be unconvincing.
If that is the case, why have this controversial patent clause at all?
I haven't read them all, but Facebook seems to have a number of patents which at first glance are so broad they could apply to react:
https://patents.google.com/patent/US20160092096A1/en "a method performed by one or more computing devices including defining a hierarchical structure for a user interface (UI) that includes defining one or more layers of the hierarchical structure, adding one or more objects at each layer, and specifying one or more relationships among particular objects"
https://patents.google.com/patent/US20160091953A1/en "Adjusting mobile device state based on user intentions and/or identity"
https://patents.google.com/patent/US20150277691A1/en "In one embodiment, as a user is scrolling through a first series of content items and reaches the nth content items from the first series of content items, display a visual indication that there are additional content items from the first series of content items existing after the nth content item."
https://patents.google.com/patent/US20150113066A1/en "A communications system including one or more alert gates and an alert controller. Each alert gate is configured to detect a different type of alert feed corresponding to a particular kind of alert. The alert controller is connected to the alert gates and operable to receive detected alerts from the alert gates and to deliver the detected alerts to a user of the communications system."
https://patents.google.com/patent/US20160086219A1/en "methods and systems that allows for improved user navigation within a group of content items."
I actually had no idea Facebook's patent portfolio was so broad. There are countless more: https://patents.google.com/?q=G06F3%2f048&assignee=Facebook+...
other than the unmitigated absurdity that is the patent system these days?
Even if I subscribed to the idea that this was without prior art on the web in 2009, equivalent functionality already existed in desktop applications. To claim that it is a novel invention because it now works on a web page is disheartening. It's exactly this kind of behavior--claiming new ownership based on each abstraction--that leads to restrictions in some countries on patents which can only exist in software.
Please provide a citation to any court decision so holding, or to the text of any law that clearly implies this.
The reality is that a couple of lawyers have come up with the speculative theory that maybe, some day, a court will read the plain text of the BSD license as granting an implicit patent license because some of the words its uses are kind of similar to the words used in a seemingly unrelated law.
This theory is...tenuous at best. More to the point, it's just a theory about what a hypothetical court might rule one day in a hypothetical case. (Plus, I mean, hypothetically the court might rule that an explicit grant can't limit the rights granted by an implicit grant in this case. Since we're just speculating about what new rules a future court might hypothetically make.)
:D