Skip to content

Instantly share code, notes, and snippets.

@yyx990803
Last active September 18, 2017 20:08
Show Gist options
  • Star 6 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save yyx990803/6fcc277479a0beac2dd53adf73c11b2f to your computer and use it in GitHub Desktop.
Save yyx990803/6fcc277479a0beac2dd53adf73c11b2f to your computer and use it in GitHub Desktop.
  • The benchmarks used by Marko, with one benchmark containing only a single component with ~50 lines of code, and the other 3 components with one of them fully static markup, are typical micro-benchmarks created to the advantage of certain implementation details. They are too isolated and too trivial to justify across-the-board performance claims.

  • For client-side performance I recommend using the 3rd party js-framework-benchmark as a more neutral reference; the benchmark tests a much bigger workload and covering a much more comprehensive performance scenarios. According to the data from the latest round Vue actually outperforms Marko. That said, even this benchmark doesn't reflect real world performance where much more overhead comes from big component trees.

  • Vue has significantly improved SSR performance for templates in the 2.4 release, however the server-side benchmark uses a JSX-based setup that doesn't benefit from these improvements. I've created a pull request to use a more idiomatic Vue setup (with single-file *.vue components) which improves Vue's performance by 2x/8x in the two benchmarks. Marko is still far ahead by about 3x, but again the test cases are IMO too trivial to reflect real-world performance. When we were benchmarking Vue's 2.4 SSR improvements in real apps by requests per second, we found the gain to be much less obvious than the 2x we saw in micro-benchmarks, because raw rendering only constitutes a relatively small portion of the time spent in a full server request.

    One additional note regarding Vue 2.4 SSR improvements: although still using vdom under the hood, the template compiler now analyzes the template statically and extract as much as possible into string concatenations (similar to Marko). However, Vue's rendering is "hybrid" in that non-extracted parts still work seamlessly with vdom, i.e. you can still use render functions in logical components where you need the full power of JavaScript, they will seamlessly blend-in with optimized strings around them. In comparison, Marko is limited to "templates only". This hybrid mode is the reason why Vue is not as fast as Marko, but we feel that the ability to use render functions when needed is too important to give up.

The point here is that micro benchmarks are not really good references for real world performance, drawing the conclusion that "Marko is 10x faster than X" from two microbenchmarks is, unfortunately, very misleading.

@nek4life
Copy link

Does SSR performance even matter for a PHP framework like Wordpress?

@seangates
Copy link

@yyx990803 I think what you're missing is the "all things being equal" part of this. Once you begin to try to run "real world examples" things tend to no longer be on equal footing. Therefore, I feel micro-benchmarks are a great start.

Also, the 10x argument for Marko makes a ton of sense when we're talking about SSR and how that can make a huge difference for an app when you're needing to deliver the page/app the first time to users. Splitting the rendering load between both a server and the front-end gives you a lot of flexibility, especially for large apps/enterprises.

Which leads me to my last point: Wordpress (which started this discussion) could benefit from the capability to have the JS framework run both on the server an on the client, broadening the base of support to enterprises who want the capabilities of Wordpress but have discounted it because of the cost of scaling it. (I know this from firsthand experience trying to use Wordpress beyond it's limits.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment