Open jimmywarting opened 1 year ago
It was a different world back then.
I think we should do this change when all of alasql can also use the import syntax
yea... maybe
there is so much eval new Function(code)
going on everywhere... would be a bit nicer if alasql didn't have to do that as much. it also breaks some CSP
Not sure if this new Function(...)
that's going on everywhere is such a good thing for optimizations. if something is running multiple times then browser are able to optimize a function and also reuse them rather than compiling new javascript JIT
maybe a more compose-able strategy would be better? with iterable helpers you would be able to build some pretty cool stuff. but that is really much in the feature and bleeding edge.
The new function things are basically the core of how the library works.
It generates the source js for the function to do what you want it to do based on the SQL. The function is cashed so that next time you run that SQL it does not need to run read and understand the SQL.
The only way I see that we can get rid of this is to have alasql act as a build step where the SQL is replaced with an actual function in the final build. This will only work with SQL that is static + parameters so we can replace the alasql call with a call to the actual function currently being cached.
when fixing sync loading in #1610 (specifically test 298) i tough: isn't it best if developers load plugins themself instead? it's not so hard to just do something like:
where the plugin assign itself into alasql
i really do not think it's up to alasql to handle the loading of plugins. what do you think?