Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React v15.0

facebook.github.io

Post reply on HN
Print view View original

141–150 of 174 posts

Re: React v15.0

#141

Post by oleg009 »

andrewingram wrote: post #130
spicyj wrote: post #21

Earlier quoted context omitted.

I don't think we've ever promoted React based on file size. Smaller files are better but people tend to overemphasize JS file size -- gzipped, this latest release is 43k which is comparable to the size of an image or two on most websites. (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 1…

I feel it's important to point out that React is now an ecosystem. Relay is comparable in size to React, then we throw Immutable into the mix, and so on. These are all dependencies that will be used on practically every page on a website, so cannot benefit from code-splitting techniques. It's certainly my experience that using React over a mess of jQuery and its plugins leads to smaller file-sizes when enhancing func…

People should stop looking for a silver bullet. If you are using react + relay, you must be building a very complex solution, where the overhead for such abstractions is justified.

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.

Re: React v15.0

#142

Post by rabelrabel »

amelius wrote: post #138
nevir wrote: post #33

There's a bit of irony here, but in a good way: Switching back to DOM APIs (e.g. document.createElement) was a performance boost . ('cause the browser vendors have done a ton of awesome work speeding up DOM APIs in recent years)

Uhm, perhaps a stupid question, but how exactly would one build DOM elements without access to the DOM?

document.createDocumentFragment()

https://developer.mozilla.org/en/docs/Web/API/Document/creat...

Re: React v15.0

#143

Post by andrewingram »

danabramov wrote: post #140
andrewingram wrote: post #130

Earlier quoted context omitted.

I feel it's important to point out that React is now an ecosystem. Relay is comparable in size to React, then we throw Immutable into the mix, and so on. These are all dependencies that will be used on practically every page on a website, so cannot benefit from code-splitting techniques. It's certainly my experience that using React over a mess of jQuery and its plugins leads to smaller file-sizes when enhancing func…

I see your point. Indeed this does not sound very good. I don’t know enough about Relay or their plans so I can’t really say much. 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 t…

I agree it's about picking and choosing the right things, but as I think we've both mentioned elsewhere, an audit and explanation of what contributes to file-size in these libraries would be super useful, for a few reasons:

* 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.

Re: React v15.0

#144

Post by andrewingram »

oleg009 wrote: post #141
andrewingram wrote: post #130

Earlier quoted context omitted.

I feel it's important to point out that React is now an ecosystem. Relay is comparable in size to React, then we throw Immutable into the mix, and so on. These are all dependencies that will be used on practically every page on a website, so cannot benefit from code-splitting techniques. It's certainly my experience that using React over a mess of jQuery and its plugins leads to smaller file-sizes when enhancing func…

People should stop looking for a silver bullet. If you are using react + relay, you must be building a very complex solution, where the overhead for such abstractions is justified. 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.

I've found that the benefits in terms of developer experience, and being able to build good UI quickly, start accumulating almost immediately, even on tiny projects.

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.

Re: React v15.0

#145

Post by cel1ne »

lisivka wrote: post #23
_uhtu wrote: post #19

Is there a reason why the file size has exploded? 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…

It is time to deploy common JS libraries out of band, like native libraries. Download them once, precompile them once, and then use precompiled version at any site, which requires it.

Libraries on CDNs have drawbacks as well, like the additional dns-roundtrip.

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.

Re: React v15.0

#146

Post by danabramov »

kriro wrote: post #116

Interesting renaming choice. ReactPerf.getWasted() :D

Yeah I was hesitant about this one. At least it will be consistent with other methods (we’ll add getInclusive(), getExclusive() etc).

Re: React v15.0

#147

Post by amelius »

rabelrabel wrote: post #142
amelius wrote: post #138

Earlier quoted context omitted.

Uhm, perhaps a stupid question, but how exactly would one build DOM elements without access to the DOM?

document.createDocumentFragment() https://developer.mozilla.org/en/docs/Web/API/Document/creat...

The documentation says this is faster because the browser does not have to compute reflow during DOM construction. But is this also true if the DOM tree is built "bottom up" (i.e., first the leaves, then their parents, etc, and then finally hook everything into the document body)?

Re: React v15.0

#148

Post by et1337 »

moreati wrote: post #119
et1337 wrote: post #96

Earlier quoted context omitted.

Better idea would be to reference it via cryptographic signature. Then you could host your own copy of lodash for example, but still benefit if a client already has it downloaded from a different site.

Subresource Integrity is the standard for that https://www.w3.org/TR/SRI/

Do you know if this allows consolidation of multiple copies of the same resource from different hosts?

Re: React v15.0

#149

Post by [deleted] »

moreati wrote: post #119
et1337 wrote: post #96

Earlier quoted context omitted.

Better idea would be to reference it via cryptographic signature. Then you could host your own copy of lodash for example, but still benefit if a client already has it downloaded from a different site.

Subresource Integrity is the standard for that https://www.w3.org/TR/SRI/

[deleted]

Re: React v15.0

#150

Post by moreati »

et1337 wrote: post #148
moreati wrote: post #119

Earlier quoted context omitted.

Subresource Integrity is the standard for that https://www.w3.org/TR/SRI/

Do you know if this allows consolidation of multiple copies of the same resource from different hosts?

I don't know. At a guess such optimization would be beyond the scope of the standard - hence up to each vendor/browser/user-agent.
Post reply on HN