A year ago I was exactly where you are now except at that point Quasar wasn’t even at v1, no video, etc. We needed to migrate our flagship application from Flex/ActionScript to something sustainable and my job was the one on the line if the choice was not correct. I had a list of requirements any framework we chose had to meet and had implemented a proof of concept app in a bunch of them. Even at a 0.17 the Quasar implementation gave me the least bugs/quirks to work around, smaller built size, and great render times. As a bonus the CLI tool took care of configuring webpack, babel, etc for me, giving us more time free to migrate our product.

So I took the leap and we started development with Quasar. To help mitigate the risks of change (especially with known breaking changes in the upcoming V1) we created wrapper classes for every component used. They allowed one person to move our codebase at that point from 0.17 to v1.beta in an afternoon. To prove to my management that going with a 0.17/beta framework was not a monumental risk I spent one day several months into development and made Vuetify versions of all the components. Almost every page worked without further modification. Since then, we have used more quasar specific functionality that would make that drastic of a change take more effort, but it would be a tiny tiny fraction of total development time.

Concerns 2-4 to me seem centered around getting skilled talent working with Quasar.
The docs for Quasar are very good, all of the examples take you directly to a working codepen. I can’t imagine going back to a book after getting used to clicking on an example, playing with it a few minutes to understand exactly how it works, then updating my actual code accordingly. We brought one person into our team since this project started. He had solid Vue experience but had never used Quasar. After two days of reading through the docs and experimenting with the code pens, he was producing quality code.

The ported application is a full electronic health records system with additional data fields and validation to support ongoing research for several specific diagnoses. We opted for SPA only with breakpoints to work at desktops and on tablets. In reality, it works well even scaled down to my phone but we don’t promise that so we don’t have to support it. The testing effort is beyond our capacity and our clients aren’t willing to pay for it. I still have my job, happy management, and can confidently say Quasar was the correct choice for me to bet the business on for a medical application.

Take the code from the docs on labeled “Clearable is equivalent to” and put it in your append slot.

Here is the code to make it work with your codepen

    <template v-slot:append>
      <q-icon 
        v-if="search" 
        name="cancel" 
        class="cursor-pointer"
        @click.stop="text = null" 
      ></q-icon>
      
      <q-icon name="search"></q-icon>
    </template>

A year ago I was exactly where you are now except at that point Quasar wasn’t even at v1, no video, etc. We needed to migrate our flagship application from Flex/ActionScript to something sustainable and my job was the one on the line if the choice was not correct. I had a list of requirements any framework we chose had to meet and had implemented a proof of concept app in a bunch of them. Even at a 0.17 the Quasar implementation gave me the least bugs/quirks to work around, smaller built size, and great render times. As a bonus the CLI tool took care of configuring webpack, babel, etc for me, giving us more time free to migrate our product.

So I took the leap and we started development with Quasar. To help mitigate the risks of change (especially with known breaking changes in the upcoming V1) we created wrapper classes for every component used. They allowed one person to move our codebase at that point from 0.17 to v1.beta in an afternoon. To prove to my management that going with a 0.17/beta framework was not a monumental risk I spent one day several months into development and made Vuetify versions of all the components. Almost every page worked without further modification. Since then, we have used more quasar specific functionality that would make that drastic of a change take more effort, but it would be a tiny tiny fraction of total development time.

Concerns 2-4 to me seem centered around getting skilled talent working with Quasar.
The docs for Quasar are very good, all of the examples take you directly to a working codepen. I can’t imagine going back to a book after getting used to clicking on an example, playing with it a few minutes to understand exactly how it works, then updating my actual code accordingly. We brought one person into our team since this project started. He had solid Vue experience but had never used Quasar. After two days of reading through the docs and experimenting with the code pens, he was producing quality code.

The ported application is a full electronic health records system with additional data fields and validation to support ongoing research for several specific diagnoses. We opted for SPA only with breakpoints to work at desktops and on tablets. In reality, it works well even scaled down to my phone but we don’t promise that so we don’t have to support it. The testing effort is beyond our capacity and our clients aren’t willing to pay for it. I still have my job, happy management, and can confidently say Quasar was the correct choice for me to bet the business on for a medical application.