<img data-src="..."> <noscript> <img src="..."> </noscript> ... <script> [JS code to handle the lazy loading...] </script>
<img data-src="..."> ... <script> [JS code to handle the lazy loading...] </script> //or <img src="...">
JSCheck employs a cookie, a query string parameter, a meta tag, and a script tag. As such, it could be implemented on a variety of systems.
There are three possible JS states: “enabled”, “disabled”, and “indeterminate”. The “indeterminate” state is only used when jscheck is disabled in the application’s configuration.
Mojito is organized around modular units of execution called mojits (“module-widgets”). Any mojit using the Mojito-JSCheck add-on can then leverage this information. For instance, a mojit which displays an image grid might decide not to lazy-load its images. A simple API call to ac.jscheck.status() would return “disabled”.
Given those considerations, generally, you should still write your code with JS-enabled users in mind, coupled with graceful degradation and progressive enhancements strategies for the “no js” case. However, Mojito-JSCheck allows you to reliably optimize your code.
Awesome sauce! I want to use it. But how?
You could design your own JSCheck system—for any front-end stack—based on the narrative above. But if you use Mojito, it’s very easy to plug Mojito-JSCheck into your app. See the README file for details.
Good luck. I hope you find Mojito-JSCheck useful, and that it enables you to achieve more with Mojito.
~James Alley and the Search Frontend Platform team @ Yahoo!
Q: Why not return a status of “indeterminate” upon the first request?
Q. Mojito-JSCheck uses redirects. Aren’t redirects evil?