ethersage on master
Fix: CircleCI 2.0 Removes conti… Merge pull request #126 from Fo… (compare)
It splits up one long-running CPU-bound operation into several short-running CPU-bound operations. This doesn't change the time it takes to render, but it avoids blocking the event loop - which in a server context is very beneficial.
It is more efficient than React's
renderToString. There are a number of reasons for this, but gist is that React has to do a lot more than is necessary for SSR because it also has to support client-based rendering. When all pieces of Rapscallion are involved, most of this extraneous code is avoided. This is especially true when Rapscallion's Babel server plugin is employed, since parts of the DOM that can be statically generated are generated at build-time rather than at run-time.
It provides shortcuts to avoid doing work. The primary example of this is Rapscallion's caching layer. If a particular component sub-tree is cached, it only has to be calculated once. This is probably where Rapscallion shines the brightest, since instead of trying to be faster than React at X operation, it just avoids doing X operation altogether.
/Users/gcp/Thumbtack/universal-frontend/node_modules/@thumbtack/rapscallion/lib/adler32.js:28 b += a += data.charCodeAt(i); ^ TypeError: data.charCodeAt is not a function