@folami - Quasar now offers its own SSR solution. No need for Nuxt anymore.

https://quasar-framework.org/guide/ssr-introduction.html

Scott

@sergevdz - https://quasar-framework.org/guide/app-quasar.conf.js.html#Example-setting-env-for-dev-build

Scott

@UnderDog - I’m using a generic node alpine container and installing yarn would just lengthen the process, unfortunately.

You can create your own base container (there might even be one already done with yarn) as you’d like it and just update the Dockerfile container import (FROM) accordingly.

Scott

You can also do relative imports by using ../ or ../../.

This @ bit is a Webpack setting: https://webpack-gatsby.netlify.com/configuration/resolve/#resolve-alias

Which you can change to your heart’s desire in quasar.conf.js.

https://quasar-framework.org/guide/app-quasar.conf.js.html#Extending-Webpack-Config-Object

Scott

That’s nice.

Is there something you want to ask? How about showing us the code you have?

Scott

https://github.com/quasarframework/quasar/tree/dev/quasar/src/plugins

Please note, that is version 1. If you are looking for 0.17, then here:

https://github.com/quasarframework/quasar/tree/v0.17/src/plugins

Scott

Yes. That is correct. Method 1 is using Quasar’s CLI and you are creating a Quasar app, so you can further develop and build your app (as in get it ready for production) with Quasar’s CLI.

The second method is binding Quasar’s component system to Vue. where you then have to work with Vue’s CLI, losing the advantages Quasar offers in terms of building your app.

Hope that makes sense.

Scott

Ionic Vue is still in its infancy. It’s still alpha. And it’s not getting that much love. It was a third party addition and was later added to Ionic. So, it wasn’t even developed by the core Ionic team. And, Ionic/Vue is still only the new Ionic Stencil bit in Ionic 4 (i.e. the abstraction of the components from the Angular core) bound to Vue. It’s not really a Vue.js based framework, where the components are also built from Vue.

That alone should be enough to tell you, Quasar is a better choice.

But, there is more.

The Quasar CLI takes care of building your different applications. With Ionic. You must use Vue, so you are talking the same disadvantages (or advantages) as if you were using Vue CLI and Quasar as a Vue CLI Plugin. See here please: https://quasar-framework.org/guide/

Quasar’s Vue based components are built for speed and developer efficiency, and not only for SPAs, but for all manner of applications possible with Quasar. With Ionic, you aren’t getting this TLC for developer efficiency. Quasar has been built for over 2 years now and only on Vue. Ionic can’t come even close to this.

With Vue 3.0 coming around the corner with even more efficiencies, you’ll gain those efficiencies right off the bat with Quasar. With Ionic, this isn’t a given at all.

Quasar has more components for you to work with. And again, they are Vue based. That means consuming them as a developer will just make better sense.

Quasar’s team are Vue aficionados. That means, you’ll get more direct help, if something goes wrong. And, I’d say the Quasar community is larger now, than the Ionic/ Vue community is. So, if you get stuck, and you are more likely to get stuck with Vue/Ionic, because the Vue binding code for Ionic is still alpha, you more than likely won’t get the help you will get with the Quasar community.

Are you sold yet?

Scott

What you did were the steps. Only at the end, it’s Vue’s CLI you are working with. Not Quasar’s.

Scott

If you are using the Vue plugin for Quasar with Vue’s CLI, you need to be using a Vue CLI command to run the project.

So, it’s not quasar dev you need, but rather yarn serve.

https://cli.vuejs.org/guide/cli-service.html#using-the-binary

Scott