3 ms·
I'm not 100% certain, but it looks like that parsing is meant to be done ahead of time, rather than on the fly? > "To use Polaris with a specific page, a web d
by outsidetheparty 11y ago
I'm not 100% certain, but it looks like that parsing is meant to be done ahead of time, rather than on the fly?
> "To use Polaris with a specific page, a web developer runs
Scout on that page to generate a dependency graph and a Polaris scheduler stub. The developer then configures her web server to respond to requests for that page with the scheduler stub’s HTML instead of the page's regular HTML."
(But even if I've misunderstood that and it is realtime, the network is still a tighter bottleneck than the page renderer in most cases, so it seems like a generally reasonable tradeoff to me.)
I'm curious how well this compares to e.g. a plain old webpack solution though -- ideally you'd have organized your assets well enough in the first place that something like Polaris would be unnecessary. "Ideal" is often a long way from reality, of course.
- tyingq 11y agoThe calls to eval() and manipulation of innerHTML are runtime...they describe it as what the "scheduler stub" does, which is the runtime code that parses the "processed page" and recreates it. eval() is a significant concern for performance.