3 ms·

No, Mozilla is imposing the same brand new restriction against dynamic code (eval, Function[1]) as Google & has no affordances to allow this sometimes performan

No, Mozilla is imposing the same brand new restriction against dynamic code (eval, Function[1]) as Google & has no affordances to allow this sometimes performance-critical & creatively necessary set of capabilities. Extensions can no longer grow & evolve, turning back multiple deacdes of possibility. [1] https://exploringjs.com/impatient-js/ch_dynamic-code-evaluation.html https://exploringjs.com/impatient-js/ch_dynamic-code-evaluat...

Firmwarrior 4y ago
Hey, look on the bright side. Within a decade or so, the "open" web will have completely stagnated, and all new content will be squirreled away in closed-source, non-searchable private domains like Discord. So you won't even care that your web browser sucks
wvenable 4y ago
eval() is creatively necessary? The existence of eval() in a function breaks JIT optimizations so it's also bad for performance.
- rektide 4y ago
  You point out only the weak, sad dynamic code & ignore the enormously speedy & optimizing dynamic code. Shame. Have at least some nuance or balance in your decry-al.
  - wvenable 4y ago
    Where is your example of speedy safe optimized code executed by eval() that wouldn't just be better as regular code?
    - rektide 4y ago
      Function constructor is the fast one. To repeat, since we're back here again, > You point out only the weak, sad dynamic code & ignore the enormously speedy & optimizing dynamic code
      - wvenable 4y ago
        What would you use the function constructor for that's worth the security implications of it existing? The majority of programming languages get along fine without such a mechanism. Why should we have it in our browser extensions?
        rektide 4y ago
        JS has always been special & excellent because it allows multiphase programming. That one coild just add more code has been unique versus the world of statuc languages, where maybe youcd have some tool to generate stubs for Thrift or gRPC, then compule that in to your program. Which works ok, if and only if you know ahead of time what schemas you might need. Im these cases, you have to give up on stub code & start using more interprtted systems. The advantages in js have been colossal, often an easy order of magnitude win to compile selectors & queries & other fast inner loop bits into jit compiled code versus having userland interpretters. Some of thd rete engines enjoy this. Just today there's graphql-jit. https://github.com/zalando-incubator/graphql-jit/blob/main/src/execution.ts#L267 https://github.com/zalando-incubator/graphql-jit/blob/main/s... https://news.ycombinator.com/item?id=31432495 https://news.ycombinator.com/item?id=31432495 Everything you say is laced with doubt & scorn & skepticism. I just cant imagine living in such a world where each system had to know fully well ahead of time each type of data it might want to interact with, might have to have that precompiled & baked in. That's a shitty miserable world that looks like the hell JS plucked us out of. By being a flexible, dynamic language that could load in routines & change it's behavior over time. Screw that dark hell world.we crawled out of, screw systems that cant ever become more, & screw the fearmongering shit show V3 foisted upon us by removing really really important flexibilities of the language.
        shadowgovt 4y ago
        > I just cant imagine living in such a world where each system had to know fully well ahead of time each type of data it might want to interact with, might have to have that precompiled & baked in At the level of a browser extension (which, operating outside the per-page security sandbox, has wide latitude to observe and manipulate the user's experience and interactions with the web), the new way of thinking is that such forward-declared constraint should be the prerequisite for the security-conscious extension. By all means, change your behavior over time... By the process of pushing new versions of the extension, which can be statically analyzed, and forward-declaring the permissions you need to accomplish your tasks. Anything else is asking the user to trust a stranger (both to not be malicious and to not be inept). > That's a shitty miserable world that looks like the hell JS plucked us out of JS plucked us out of one hell and put us, initially, into another where any old website could fake a query to get your bank account data or steal your password. We've been digging out of that hell ever since, and this is another step in that process.

Firmwarrior 4y ago

Hey, look on the bright side. Within a decade or so, the "open" web will have completely stagnated, and all new content will be squirreled away in closed-source, non-searchable private domains like Discord. So you won't even care that your web browser sucks

wvenable 4y ago

eval() is creatively necessary? The existence of eval() in a function breaks JIT optimizations so it's also bad for performance.

rektide 4y ago
You point out only the weak, sad dynamic code & ignore the enormously speedy & optimizing dynamic code. Shame. Have at least some nuance or balance in your decry-al.
- wvenable 4y ago
  Where is your example of speedy safe optimized code executed by eval() that wouldn't just be better as regular code?
  - rektide 4y ago
    Function constructor is the fast one. To repeat, since we're back here again, > You point out only the weak, sad dynamic code & ignore the enormously speedy & optimizing dynamic code
    - wvenable 4y ago
      What would you use the function constructor for that's worth the security implications of it existing? The majority of programming languages get along fine without such a mechanism. Why should we have it in our browser extensions?
      - rektide 4y ago
        JS has always been special & excellent because it allows multiphase programming. That one coild just add more code has been unique versus the world of statuc languages, where maybe youcd have some tool to generate stubs for Thrift or gRPC, then compule that in to your program. Which works ok, if and only if you know ahead of time what schemas you might need. Im these cases, you have to give up on stub code & start using more interprtted systems. The advantages in js have been colossal, often an easy order of magnitude win to compile selectors & queries & other fast inner loop bits into jit compiled code versus having userland interpretters. Some of thd rete engines enjoy this. Just today there's graphql-jit. https://github.com/zalando-incubator/graphql-jit/blob/main/src/execution.ts#L267 https://github.com/zalando-incubator/graphql-jit/blob/main/s... https://news.ycombinator.com/item?id=31432495 https://news.ycombinator.com/item?id=31432495 Everything you say is laced with doubt & scorn & skepticism. I just cant imagine living in such a world where each system had to know fully well ahead of time each type of data it might want to interact with, might have to have that precompiled & baked in. That's a shitty miserable world that looks like the hell JS plucked us out of. By being a flexible, dynamic language that could load in routines & change it's behavior over time. Screw that dark hell world.we crawled out of, screw systems that cant ever become more, & screw the fearmongering shit show V3 foisted upon us by removing really really important flexibilities of the language.
        shadowgovt 4y ago
        > I just cant imagine living in such a world where each system had to know fully well ahead of time each type of data it might want to interact with, might have to have that precompiled & baked in At the level of a browser extension (which, operating outside the per-page security sandbox, has wide latitude to observe and manipulate the user's experience and interactions with the web), the new way of thinking is that such forward-declared constraint should be the prerequisite for the security-conscious extension. By all means, change your behavior over time... By the process of pushing new versions of the extension, which can be statically analyzed, and forward-declaring the permissions you need to accomplish your tasks. Anything else is asking the user to trust a stranger (both to not be malicious and to not be inept). > That's a shitty miserable world that looks like the hell JS plucked us out of JS plucked us out of one hell and put us, initially, into another where any old website could fake a query to get your bank account data or steal your password. We've been digging out of that hell ever since, and this is another step in that process.