There’s many libs for web workers. One which is quite simple and working in Quasar is described below.
Lets create a new test Quasa project, with javascript and simple options:
quasar create qworkers
We will be using this library and integrate it with our test project:
https://github.com/developit/workerize-loader
In file package.json we will add this:
"devDependencies": {
...
"workerize-loader": "^1.3.0"
},
In file quasar.conf.js we will add this:
build: {
...
// https://quasar.dev/quasar-cli/handling-webpack
chainWebpack (chain) {
chain.output.set('globalObject', 'this')
},
extendWebpack (cfg) {
...
cfg.module.rules.push({
test: /\.worker\.js$/,
exclude: /node_modules/,
loader: 'workerize-loader',
options: { inline: true }
})
}
},
Our index.vue should look like this:
<template>
<q-page class="flex flex-center">
<img
alt="Quasar logo"
src="~assets/quasar-logo-full.svg"
>
<q-btn @click="start1">start worker</q-btn>
<q-btn @click="start2">start DOM function</q-btn>
</q-page>
</template>
<script>
import worker from './test.worker'
export default {
name: 'PageIndex',
methods: {
async start1 () {
const instance = worker()
const count = await instance.expensive(5000)
console.log(`Ran1 ${count} loops`)
},
expensive (time) {
const start = Date.now()
let count = 0
while (Date.now() - start < time) {
count++
}
return count
},
start2 () {
const count = this.expensive(5000)
console.log(`Ran2 ${count} loops`)
}
}
}
</script>
We will add a new file src/pages/test.worker.js with content:
export function expensive (time) {
const start = Date.now()
let count = 0
while (Date.now() - start < time) {
count++
}
return count
}
export default expensive
Next we execute commands:
npm install
quasar dev
And the browser should popup:
Pressing “start worker” button will execute CPU expensive function in web worker. Observe, that the page is fully responsive. The result will be shown in the console.
Pressing “start dom function” will execute CPU expensive function in main DOM browser thread. The page will NOT be responsive! The result will be shown in the console.
Discussion:
- Why this library? Well, it’s simple and it works. The integration by webpack in inline mode allows nice HMR and quasar bundling.
- Why there are strange CSP comments in firefox? Yes, the web workers has some security quirks and there are differences in handling them in Chrome and Firefox. There is a section about Content Security Policy in MDN about that:
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers
- Why do you need web workers in Quasar? In Quasar there are many potential optimizations which could benefit from using web workers. They are not only typical sorting, filtering, querying but even less obvious parts of Quasar component where the CPU work could be transferred to web worker. Yes, it could make Quasar the fastest framework in the market.
- Oh, but I’m just a user and I want web workers in Quasar, too! Well, I would like also! I think it is time to include web workers support in base library - similar as it was done with support for other browser API as local storage, full screen, resize. The one, working Quasar interface to web workers would be a game changer.
- What if somebody will create an App Extension with web workers support instead? This IMHO would be less optimal, because the Quasar API for web workers should be the same for internal Quasar components and for user apps. The example above is rather simple in terms of communication, but in real life, probably one would want a more advanced communnication between components. It comes to mind the excellent BEX mode and the concept of
bridge. I think, if Quasar would implement support for web workers, the existing bridge concept as a means of communication would be just right.
