marko-perf.md

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

If you have a more realistic benchmark for SSR, I think it would add real value to the discussion here.

For sure the time spent on data fetching in a real world app is most likely dominant compared to the time spent on rendering the HTML string. So when you measure the performance on the time to the first byte I would not expect a 10x difference if we are waiting to get all the data before we start shipping the HTML.

That said, MarkoJs supports asynchronous rendering so meaningful HTML (for example the above the fold content) can be shipped before you have all the data you need to render the full page (I am sure there is something more updated but so far I found this ). So depending on what the data on the page is and where it is stored, you may have even more than 10x not only on the Time to the First Byte but also on the Time to the First Meaningful Paint when you use MarkoJS.

On the other hand if you just run a bunch of times the function that renders the template with the same data, the performances are likely going to be CPU bounded. So a 10x improvement difference would likely go along with 10x more CPU usage. That goes along with needing 10x servers to ship the same number of requests.

On the other hand if you just run a bunch of times the function that renders the template with the same data

That shouldn't happen in Real-life scenarios imho. Unless you are building a static website, content will never be the same for each render.

@ChrisCinelli Vue also supports streaming rendering, or async rendering as you call it. In fact we have had this feature since 2.0.

The argument of "10x difference in micro-benchmarks leads to 10x server need" couldn't be farther from the truth - as I said:

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.

It's not only about data fetching - your server has to handle the request all the way down, parsing the headers, handling middlewares, database IO, serializing state, etc. Rendering is not the only work that the server has to do.

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

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