Hi @qyloxe,

There is no need to passive aggresively imply those points. I just stated my opinion. What I’m trying to say is that Quasar Framework is a VueJS framework and in my opinion it is the better practise to follow the path it is taking, because it will ensure compatibility with other building blocks that are build for VueJS.

1. Vue is just a “better javascript” and it feels good
2. Quasar is just the “better Vue” therefore it should feel “more good”
3. Vue packaging/build concept is mature, well thought, good fit for everyone, and Vue is a “white” magic, which should handle everything for everybody
4. Quasar packaging/build is “black” magic, which does something supposedly useful sometimes for somebody, but it is not clear what, why and who

The example you refer to as black box magic was intended to describe the discrepancy between how the Vue CLI building/packaging works and how the Quasar building/packaging works. It isn’t about wheter one or the other is “right”, but rather about how there is an established build/packaging process that all other Vue plugins are/will be using and it’s incompatibility with the one Quasar uses.

5. Quasar packaging/build is “black” magic, which does something supposedly useful sometimes for somebody, but it is not clear what, why and who

I clearly understand that it is super usefull to have PWA, Electron and Cordova straight out of the box. I just think there are better ways to implement it without discarding the ability Vue’s regular CLI provide.

6. Application plugin system is the same as architectural components of the final solution.

If I’m right were talking about the CLI, not architectural aspects? The plugin system is a part of the CLI and doesn’t affect any architectural components.

7. Design of final application should be managed only by a said developer, who is entitled to “feel” good.

Yes, you got me… Thats the only reason I posted my concerns. No I just wanted to start the conversation about this topic. If you come up with some good arguments about your point of view, instead calling me entitled, I’m the first one to acknowledge you’re right.

Finally may I ask you why you prefer a dedicated CLI instead of a plugin based solution that plays nicely with the technology Quasar framework is built upon?

Hi @rstoenescu,

I see your point. However, i have some thoughts about it. One thing I really like about Vue, is that it really works “the Javascript kind of way”. It feels just like I’m writing plain javascript with just the right amount of “magic” going on. For me, this changes a bit when using the Quasar Cli. Because it feels a little bit detached from the Vue way of doing things.

I’d rather be making an Vue application that uses Quaser, instead of making a Quasar application using vue. As it starts to feel this way when I use the Quasar CLI. E.g. quasar-framework is not listed in the package.json anymore and abstracted away. It might be necessary to pin it to a version. Same with the inclusion of quasar.conf.js. I found it strange to include Quasar components in a different way then all the other VueJS Components. I also expected my build scripts in the package.json, where I can easily extend them.

It concerns me that I’m writing a Quasar app instead of an Vue app, as I might want to include some vue cli 3 plugin in the future, which I cannot do when using the Quasar CLI. It isn’t unreasonable to think there might be usefull plugins released that way. It’s a way of futureproofing our work here, because in the end, we’re developing a Vue application.

Vue Cli v3 is really trying to streamline Vue development with dev configs in package.json, 3rd party lib configs in vue.conf.js and easily updateable and stackable vue cli plugins. And I think Quasar CLI is an outstanding addition to that as a vue plugin. That way I can still use all other Vue plugins I might deem necessary and Quasar sticks closely to the path Vue is heading.

I really do love Quasar Framework, and it does give me an awesome developer experience with the high quality components en comprehensive docs. I realise this critique is frustrating as you surely put a great deal of work in the CLI and I’m sorry if I offended you in any way or misunderstood anything.

I can’t wait! A lot of issues that we’ve stumbled against that are addressed in v0.15 It’s gonna be glorious!

@rstoenescu Thanks for your hard work on the 0.15 update. I really appreciate the effort that went into building comprehensive documentation. It really shows how much work you put into it! Well worth the wait.

I’ll check with my manager if we can support you on your Patreon page, as you certainly deserve it!

Hi @qyloxe,

There is no need to passive aggresively imply those points. I just stated my opinion. What I’m trying to say is that Quasar Framework is a VueJS framework and in my opinion it is the better practise to follow the path it is taking, because it will ensure compatibility with other building blocks that are build for VueJS.

1. Vue is just a “better javascript” and it feels good
2. Quasar is just the “better Vue” therefore it should feel “more good”
3. Vue packaging/build concept is mature, well thought, good fit for everyone, and Vue is a “white” magic, which should handle everything for everybody
4. Quasar packaging/build is “black” magic, which does something supposedly useful sometimes for somebody, but it is not clear what, why and who

The example you refer to as black box magic was intended to describe the discrepancy between how the Vue CLI building/packaging works and how the Quasar building/packaging works. It isn’t about wheter one or the other is “right”, but rather about how there is an established build/packaging process that all other Vue plugins are/will be using and it’s incompatibility with the one Quasar uses.

5. Quasar packaging/build is “black” magic, which does something supposedly useful sometimes for somebody, but it is not clear what, why and who

I clearly understand that it is super usefull to have PWA, Electron and Cordova straight out of the box. I just think there are better ways to implement it without discarding the ability Vue’s regular CLI provide.

6. Application plugin system is the same as architectural components of the final solution.

If I’m right were talking about the CLI, not architectural aspects? The plugin system is a part of the CLI and doesn’t affect any architectural components.

7. Design of final application should be managed only by a said developer, who is entitled to “feel” good.

Yes, you got me… Thats the only reason I posted my concerns. No I just wanted to start the conversation about this topic. If you come up with some good arguments about your point of view, instead calling me entitled, I’m the first one to acknowledge you’re right.

Finally may I ask you why you prefer a dedicated CLI instead of a plugin based solution that plays nicely with the technology Quasar framework is built upon?

Hi @rstoenescu,

I see your point. However, i have some thoughts about it. One thing I really like about Vue, is that it really works “the Javascript kind of way”. It feels just like I’m writing plain javascript with just the right amount of “magic” going on. For me, this changes a bit when using the Quasar Cli. Because it feels a little bit detached from the Vue way of doing things.

I’d rather be making an Vue application that uses Quaser, instead of making a Quasar application using vue. As it starts to feel this way when I use the Quasar CLI. E.g. quasar-framework is not listed in the package.json anymore and abstracted away. It might be necessary to pin it to a version. Same with the inclusion of quasar.conf.js. I found it strange to include Quasar components in a different way then all the other VueJS Components. I also expected my build scripts in the package.json, where I can easily extend them.

It concerns me that I’m writing a Quasar app instead of an Vue app, as I might want to include some vue cli 3 plugin in the future, which I cannot do when using the Quasar CLI. It isn’t unreasonable to think there might be usefull plugins released that way. It’s a way of futureproofing our work here, because in the end, we’re developing a Vue application.

Vue Cli v3 is really trying to streamline Vue development with dev configs in package.json, 3rd party lib configs in vue.conf.js and easily updateable and stackable vue cli plugins. And I think Quasar CLI is an outstanding addition to that as a vue plugin. That way I can still use all other Vue plugins I might deem necessary and Quasar sticks closely to the path Vue is heading.

I really do love Quasar Framework, and it does give me an awesome developer experience with the high quality components en comprehensive docs. I realise this critique is frustrating as you surely put a great deal of work in the CLI and I’m sorry if I offended you in any way or misunderstood anything.

@rstoenescu Thanks for your hard work on the 0.15 update. I really appreciate the effort that went into building comprehensive documentation. It really shows how much work you put into it! Well worth the wait.

I’ll check with my manager if we can support you on your Patreon page, as you certainly deserve it!

I can’t wait! A lot of issues that we’ve stumbled against that are addressed in v0.15 It’s gonna be glorious!