8 ms·
I like React a lot, but boy. That file size is getting pretty large: http://elijahmanor.com/react-file-size/ http://elijahmanor.com/react-file-size/ Looks to
by untog 10y ago
I like React a lot, but boy. That file size is getting pretty large:
http://elijahmanor.com/react-file-size/ 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:
https://preactjs.com https://preactjs.com
- mercer 10y agoI'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?
- untog 10y agoI'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.
- SamBam 10y agoWouldn'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.
- untog 10y agoYeah, 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.
- mercer 10y agoConsidering these two bad examples (and another one in a parallel thread), I still don't really understand what the downside is...
- svachalek 10y agoPropTypes 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.
- tengbretson 10y agoCorrect me if I'm wrong, but the production build of React strips out PropTypes as well doesn't it?
- doytch 10y agoIt definitely strips out PropType checks. Not sure if the underlying code is still in the production builds though.
- danabramov 10y agoIt is included in 15 but won't be in 16.
- ryannevius 10y agoThanks 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/ http://mithril.js.org/
- Numberwang 10y agoIsn't Mithril abandoned since years back? I'd go with Vue instead which is still maintained.
- lhorie 10y agoNo, we're working on a v1.0 release You can see the latest code here: https://github.com/lhorie/mithril.js/tree/rewrite 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
- Numberwang 10y agoGreat to hear. Seems I've been oblivious to the rewrite. This is looking very promising.
- andrzejsz 10y agoAny book would be available?
- interlocutor 10y agoIn 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.
- rublev 10y agoComponent 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.
- interlocutor 10y agoSorry, 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.
- TheCoelacanth 10y agoNot 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.
- nine_k 10y agoLikely 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.
- andrethegiant 10y agoThere was a comment addressing this on the GitHub's Issues page yesterday: https://github.com/facebook/react/issues/8294#issuecomment-260831450 https://github.com/facebook/react/issues/8294#issuecomment-2...
- rattray 10y agoHow 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.
- eloisant 10y agoI 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.
- scarlac 10y agoEvery 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.
- chadscira 10y agoWe 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).
- lhorie 10y ago> 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 https://koglerjs.com/verbiage/performance)
- scarlac 10y agoI'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.
- fleetfox 10y agoHmm, 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?
- smrtinsert 10y agoMeh. 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".
- olegkikin 10y agoOne 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.
- susi22 10y agoI 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.