Open hilbix opened 6 years ago
Why is e) something the loader must care about?
Just because. Usually the error reporting module must be the first thing active, to wrap everything.
But the loader is asynchronous. Hence we cannot rely on the fact, that the error reporting is able to wrap everything first. Hence the loader must ensure this.
This is a Must-Have which must be built into the loader right from the beginning.
Either the loader just loads this module and then vanishes in favor of the module.
Or the module cooperates with the loader.
However the latter needs an API. APIs are big and bloaty. Hence the loader cannot support this.
Hence we are back to "the loader gives up in favour of the module".
But now we are missing a loader again. Hence the error reporting module must provide a loader again.
This is an Antipattern. Hence we are back to the loader itself. As the module must not cooperate with the loader, the only thing the loader can do is to load the error reporting module and then continue.
However the error reporting module needs another beast. The data reporting module, which is able to pull a consent from the user.
This should not be build in the error reporting module itself, else we would re-invent the wheel, when it comes to other reporting functions, like the browser's environment.
This leads to another variant of the same problem:
Silent errors.
This is, the user loads the page, and no error happens, but it still does not work.
What to do in that case? We need to gather user response information and send them back, such that we can diagnose the whole environment the user uses, not only the error (as there is none)
This needs the reporting module as well.
Hence the loader must do:
This then can lead to 2 other variants:
A) Running without net in case the user does not want error reporting etc.
The first 3 steps are skipped. In certain situations, diagnostic and reporting might be loaded later.
B) Just run diagnostics
Diagnostics then can trace how the application is processed by the bloaty loader. Or whatever seems fit.
All effort for "obeys the EU law" is put into the "reporting module".
Other countries might not need that and even in certain situations (i. E. the application is run by testers) this module may be replaced by something fully automatic, which runs in background.
Hence this is a module which needs to be flexible enough. This should not affect any other part of the whole software stack.
Today each device has huge caches. So even force-loading a 100 MB JS application could take less than 1s at 1KB/s, in case the loading page is small. You can prime the cache in case you have wLAN, then you can use the cache when you are mobile with less than 1 KB/s.
Hence what I need is:
a) A minified JS loader. With "minified" I think about ess than 1 KB of code.
However:
It must not support all browsers on it's own. In contrast, there must be variants of the loader for all known browsers. Each variant as small as possible. So no bloat. Nothing you do not need on a particular browser.
It must be AMD compatible. However it must not be fully AMD compatible on the first invocation. AMD compatibility can be provided by a module loaded later on.
b) Easy to use.
It should be easy to use with
<script>
.No JS required for bootstrapping and configuration. All done on DOM level.
c) Fast first response
<noscript>
)This means:
If everything and really everything fails, like you look at the page with
curl
, there must be a prominent note that you need some browser with JS enabled.If you are looking at the page with a JS enabled browser, this prominent note must be wiped away, automatically.
This has to go into the loader.
d) Asynchronous loading of everything else
<script>
tag loading the loaderHence, the loading of everything else must
e) Full blown monitoring
One of the first modules loaded must be something, which gathers all uncaught errors and is able to reports them.
Another extremely important module is a module, which allows to send remote-diagnose information, which includes standard information like the used browser environment, but also special application data, which was gathered by the application.
Hence, nothing will be sent out from the Browser without full prior consent of the user. This consent must be fully by free choice and completely free will of the user, and it must not happen, that the data is sent accidentally, ever.