search

krausest / js-framework-benchmark

A comparison of the performance of a few popular javascript frameworks
https://krausest.github.io/js-framework-benchmark/
Apache License 2.0
6.68k stars 827 forks source link

Note: Implementation uses runtime code generation [sticky] #1139

Open fabiospampinato opened 1 year ago

fabiospampinato commented 1 year ago

Update from @krausest: Please see this WIKI page for documentation of how the check is performed End of update

Some frameworks, like mine, generate code at runtime, usually either via eval or via new Function.

In theory there could be no problems with that, but from the point of view of a user they must be more confident that something with no runtime code generation at all has no security issues deriving from that compared to something that uses runtime code generation.

There's also a CSP policy for preventing user code from generating code at runtime, as it's a desirable feature for many.

As such I think it would be useful to add an additional flag for marking frameworks that use this technique.

WebReflection commented 1 year ago

I was going to propose this flag myself, as people are "scared" by events delegation due flags, and not aware their library of choice might not even be usable in the wild due CSP constraints, so that having a library based on code evaluation / requires CSP workarounds flag would be way more interesting than benchmark specific implementations!

in short, I fully support this new flag and I'd be happy to help out flagging all libraries involved with a cumulative PR.

krausest commented 1 year ago

Good idea. I'll add the text to the result table soon and we'll use this issue as the target. Would be great if you added the issue in package.json where appropriate.

  "js-framework-benchmark": {
    ...
    "issues": [
      1139
    ]
  },
WebReflection commented 1 year ago

@krausest here we go: https://github.com/krausest/js-framework-benchmark/pull/1142 I've written some note there as the flag is actually all over the board but I've reasoned why I think that's actually the right choice, so that developers are aware that either the library or the tools used to ship the library in production can cause CSP issues, hence break the whole execution if CSP is not taken into account.

krausest commented 1 year ago

Was accidentally closed.

yyx990803 commented 1 year ago

Not sure why Vue is flagged in in 018322f697e6906bb068b89ad68acd4610f2e47d - Vue 3 does not use runtime code generation when templates are pre-compiled at build time.

WebReflection commented 1 year ago

@yyx990803 this should've been amended after through automated tests, the initial PR simply looked for evaluation, it wasn't super accurate and few got removed (few others got added) later.

krausest commented 1 year ago

I switched to an automated check. See https://github.com/krausest/js-framework-benchmark/issues/1148 for details.

L3P3 commented 1 month ago

What if there is a variant/setting to disable runtime generated code? I think this would be sufficient to remove/change the notes. Or should I submit 2 benchmark entries? https://github.com/L3P3/lui?tab=readme-ov-file#noeval-variant