Re:Designing very large JavaScript applications
by jakelazaroff on Saturday April 21, 2018 @06:52AM
(#16890905)
The fact that they can't be statically analyzed is a huge downside. It's a trade-off.
Re:Designing very large JavaScript applications
by tzahola on Saturday April 21, 2018 @06:12AM
(#16890804)
>For use on the web the web server could grep require from the source and push modules to the browser
Nope. The server can’t figure out which modules are needed unless it runs the program:
if (isPrime(366226717)) {
require(“hugeModule”)
}
Re:Designing very large JavaScript applications
by z3t4 on Saturday April 21, 2018 @06:17AM
(#16890821)
No need to make sense of the code, just run a regex to find all require's.
Could also use a package.json
Re:Designing very large JavaScript applications
by tzahola on Saturday April 21, 2018 @08:15AM
(#16891145)
require(calculateTenthMersennePrime().toString() + “.js”)
Re:Designing very large JavaScript applications
by kofejnik on Saturday April 21, 2018 @07:09AM
(#16890947)
can you regex this:
var _0xdde4=["\x6C\x65\x66\x74\x70\x61\x64"];require(_0xdde4[0])
Re:Designing very large JavaScript applications
by z3t4 on Saturday April 21, 2018 @08:23AM
(#16891164)
worst case scenario is that the browser has to request it from the server. This is bad because the execution would have to stop and wait, but for most cases it would just be for a few milliseconds. And the developer should take that into account and maybe prep the cache for possible paths.
And it also lazy loads the module. ES6 modules might be a 44 years old standard, but NodeJS modules are better !
For use on the web the web server could grep require from the source and push modules to the browser, so when a module is required it will be loaded from cache. The browser could even pre-parse the module to speed up run-time for when it's required.