React 15.4 | Hacker News Reader

React 15.4

facebook.github.io

173 pointsspicyj72 comments

I like React a lot, but boy. That file size is getting pretty large:

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:

https://preactjs.com

Thanks for sharing. I hadn't heard of Preact before. However, the landing page does mention Mithril, which I use frequently. There's just so much included in Mithril out of the box, and it's hard to beat the file size.

http://mithril.js.org/

Isn't Mithril abandoned since years back? I'd go with Vue instead which is still maintained.

No, we're working on a v1.0 release

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

Great to hear. Seems I've been oblivious to the rewrite. This is looking very promising.

Any book would be available?

I often read people complaining about library size, but is there any numbers about the actual impact on the user's perception?

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.

> is there any numbers about the actual impact on the user's perception

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.

[1](https://koglerjs.com/verbiage/performance)

addyo@, samccone@, and slightlyoff@ gave talks at Chrome Dev Summit last week about exactly this topic (and plugged Preact while they were at it). The average load time on mobile right now is 19s. (I think they were citing a DoubleClick study.) The Chrome dev rel team is in the midst of a big educational push around these topics right now, because pages are getting more complex, but median devices and networks are actually getting slower as more low-end devices enter the market.

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.

Every year the mobile market share grows (still) making mobile devices and their experiences even more important.

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.

We also should remember that most react apps are single page apps, and usually this .js file is aggressively cached on a CDN. Most interactions are close to instant.

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

How much is preact-compat gzipped? Can't seem to find it on the website...

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.

I'm not sure I'm seeing the same pattern for this particular version. Comparing the minified versions I see the file size delta for version 15.4.0-rc3 is -4.32 KB, meaning a reduction in file size.

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.

There was a comment addressing this on the GitHub's Issues page yesterday: https://github.com/facebook/react/issues/8294#issuecomment-2...

Meh. The synthetic events are a huge reason of why someone would go with react. Promises much better performance in theory. For 40k difference on an initial request, I have 0 qualms going "full react".

Hmm, for comparison jQuery is 32kB and half of the web includes that. Conisdering today's hardware and connection speed how large would it have to be to noticeably affect performance?

In preactjs, how do you update the screen when data changes? According to the site preactjs is stateless, so presumably there is no updateState() but there is no alternative mentioned.

Component lifecycle methods. There's two types of components in preact:

- Classical Components, with lifecycle methods and state

- Stateless Functional Components, which are functions that accept props and return JSX.

Sorry, can you elaborate? How are lifecycle methods useful for updating the screen when data changes? Component lifecycle methods are componentWillMount, componentDidUnmount etc. But my data may change at any time, and I want to update the screen when my data changes, and I can't wait for the next component lifecycle method invocation.

Not sure if I understand what you are asking. It is basically the same as react, you either call setState on the component or pass in different props to the component and then the component gets re-rendered with the new state/props.

Likely you dispatch an event that updates some props, and your components render themselves again with a new props configuration?

All the state you have in a functional program is usually your cal stack and/or message queue.

One possible way of dealing with huge libraries on the client side is to create a preloader, a hyper-optimized tiny page with all the CSS/JS embedded (so one request). It displays some basic progress bar and preloads all the JS / CSS / images / JSON your app needs. Then you start your actual framework, render and swap the load screen to your app.

All of this creates an illusion of speed, and people are generally fine waiting, as long as they are shown the progress bar.

I'm also very happy with Preact. Apparently one approach is to use React in development and Preact in production. Could anyone who does this or knows more about this explain what React offers in development?

I'd be extremely dubious of this approach, as I've been burnt before by switching things between dev and prod (like using SQLite in dev, Postgres in prod).

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.

Wouldn't that be an example of the exact reason to use React in dev and Preact in production, as OP said? PropTypes are useless in production.

Yeah, it was a bad example. A better one: Preact lets you specify HTML classes using "class", React requires you to use "className". So it would be easy to trip up on that dev/prod difference.

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.

Considering these two bad examples (and another one in a parallel thread), I still don't really understand what the downside is...

PropTypes for one. And a lot of other little, "you did this but probably meant to do that" type of checks like when you use class instead of className.

Correct me if I'm wrong, but the production build of React strips out PropTypes as well doesn't it?

It definitely strips out PropType checks. Not sure if the underlying code is still in the production builds though.

It is included in 15 but won't be in 16.

I just downloaded both and I get these numbers:

  (sizes react-both)
  => {:br11 [34761 "0.240"], :gz9 [41790 "0.288"]}

It actually got smaller from the 15.3 release.

Query parameter for enabling timeline recording seems wrong. My app will remove that query parameter because it's unknown to the server

Does it remove it and redirect? If not, you're fine. I think that's why something like this is chosen. Your (server) app will rightly ignore that query parameter, but you'll probably still serve up the page. React is client-side, so it will still see it in the url. Everyone should be happy.

Agreed. There should be a function u can call in the console as a fallback similar to Perfect.start(). I bet there is, they just didn't publicize it.

The PR: https://github.com/facebook/react/pull/7549

I don't see the location.search (or toggle) used anywhere in this PR :(

edit: 'isProfiling' is used but never declared so it most likely already was a toggle they used.

They use window.location.href with a regex here:

https://github.com/facebook/react/blob/e612826650ff68e73bff4...

There is, ?react_perf is exactly the same as ReactPerf.start().

`ReactPerf.start()`

The first time I used react was for the beta of my project http://launchaco.com/

One of the coolest things from this release IMO is the simulation of clicking working now! Simulate.click()

Watch out for third party libraries breaking with this release. A couple that we use use were importing some modules from 'react/lib' that moved to 'react-dom/lib' such as CSSPropertyOperations.

These were always private APIs and will break many more times. Please file issues with those libraries to stop using them. We will stop exposing them completely in the future.

We just released an updated version of Winds using React 15.4 and it works wonderfully! Looking forward to seeing the perf improvements. http://winds.getstream.io if you're curious to see what we're working on at GetStream.io!

What's your experience with Sails been like? I considered it for askinline.com when starting but quickly abandoned ship and ended up rolling a backing using Hapi & Sequelize. I couldn't be more satisfied with the decision.

Happy to see another RSS reader get some love.

Was looking forward to better chrome timeline integration, great!

wow visualizing React components timings in the Chrome Timeline seems really cool. must try it out :)

reactperf looks nice and useful. thanks for the hard work!

If you use Typescript you can get most of the benefits of React from this little library: https://github.com/wisercoder/uibuilder

It doesn't support fine-grained screen update but you get support for Web Components (Polymer) which React doesn't support.

Facebook is being arrogant by not supporting the Web Components W3 standard.

For me the best asset of React is not having to manipulate the DOM directly with jQuery, which in my experience leads to code that injects DOM elements from everywhere making it very difficult to maintain.

This is certainly not a replacement.

You can do this with Polymer, Vue or Angular too (and many others)

You can divide your page into multiple components, then to update the screen replace the components that contain stale data. You do not have to deal with elements--you only have to deal with components.

Regardless of which library you use there is nothing preventing you from injecting DOM elements from everywhere. Only discipline can prevent that.

I guess I fail to see the value of this. If you don't want the component lifecycle, event system, or DOM diffing that React gives you, you might as well just write your own declarative wrapper around `document.createElement(...)` and be done with it. You can achieve this for templating alone in < 10 lines of code, and if you want to add some event delegating on top of it you can include that for another ~30.

Right - DOM diffing is the key selling point of React. But the fine-grained screen updates possible via DOM diffing is not super important for most applications.

Event system is already supported by DOM. React doesn't add anything there. Component lifecycle is also not compelling.

That's kind of what I'm saying. If you don't value those things, why introduce a library at all? What you're describing can be implemented in < 10 lines.

More like 200 lines, so it is useful to have a library. BTW it is rare to hear component lifecycle and event system described as key selling points of React. Most people would say DOM diffing and perf are the key selling points.

The point of React is to make it practical to structure view logic as a function (projection) of the application state. Virtual DOM is just an implementation detail.

By the way, for the most minimal diffing implementation see https://github.com/patrick-steele-idem/morphdom.

I lied. More like 5 lines. http://codepen.io/anon/pen/MbjLMB

Right, but the point is that React is disciplined for you. You never do any manual HTML manipulation so you don't have to worry about injection issues.

You don't do manual HTML manipulation with this lib either. You can just see your page as being composed of components and replace components in order to update screen.

So, you're still controlling what is updated and when, with the same potential for making mistakes that you'd get in direct DOM manipulation.

React doesn't require you to ever manually replace a component - that's why the two are not comparable.

I am not familiar with the type of mistakes you are talking about. I have used both React and UIBuilder and find them to be comparable. Would you be willing to share an example of the type of mistake that developers frequently make?

It's not that React doesn't "support" web components. React is a competitive alternative to web components. Custom HTML elements (components) done better, done now and without aggressive browser shimming. My understanding is that a significant driver for an alternative to WC was Facebook's view that no server-side rendering made WC a complete non-starter within the company.

Competition is good for the web.

It is actually not "done better". Web Components have shadow DOM, which permits scoped CSS. React Components are brittle because styles and scripts are global. Also, some people think you can only pass strings as attributes to Web Components. This is not true; you can pass objects just like in React. Also, Web Components are declarative not imperative, again like React.

I didn't mean "done better" as an absolutist statement, but I can understand why it would be read that way. I meant it more as a brand statement, obviously the React team, contributors and users are likely to believe it's better. I get that some will come down on the other side of that coin.

I stand by the statement that the competition between these two projects is good for the web which I think is the important part of my response to the parent comment. I'm glad there are people working with and on web components.

What is the point of open standards if everyone competes against the open standard as opposed to supporting the standard?

Facebook isn't "everyone". As I noted in the comment to which you're replying, there are people building and using Web Components.

Nothing about Facebook creating React prevents browser vendors from implementing Web Components natively. React uses other open standards (ECMA & HTML) which have existed for a decade previous to Web Components.

Web Components contains good ideas. React contains good ideas. You're arguing against people who are helping. Stop doing that.

Somehow I think the reaction would be different if Microsoft had done this, i.e., make proprietary competing technology instead of supporting an open standard. (Yes, React is proprietary--look into the patent rider issue.)

Yes but you didn't dispute his major point of server-side rendering.

You can uses this to do server-side rendering: https://github.com/pimterry/server-components

It is unfortunate that this post got so many downvotes. Apparently people only want to hear from people who agree with them. This is known as the echo chamber effect, and HN is becoming one: http://www.nytimes.com/roomfordebate/2011/04/21/barack-obama...

Reply on news.ycombinator.com