vue-cli 3.0 and the future of quasar-cli


  • Admin

    Let me shed some light on this. From what I see, it’s one of the most misunderstood tools from the Quasar ecosystem.

    1. The future of Quasar CLI is… well… using Quasar CLI, because of what I am about to briefly explain.
    2. Quasar CLI does NOT wrap vue-cli in any way.
    3. Quasar “init” command calls “vue init” in the terminal. That’s the only connection between the Quasar CLI and Vue CLI.
    4. If you want to take advantage of the full power of Quasar, use Quasar CLI. It has all you need so you can avoid any headaches. It builds SPA, PWA, Cordova and Electron apps out of the box and allows seamless upgrades to newer versions. It would take me a day to write a full description on the optimisations, configurations, tools and everything that Quasar CLI v0.15 brings to the development area.

    If, for some reason, you decide to go against recommendations and just throw out the window 50% of what Quasar can do for you, then go ahead and use Vue CLI only. But don’t ask for help from Quasar team, because this is not the way to go. I see many developers going for the new shiny thing (vue-cli v3) only because, well, it’s something new and it’s got vibe on social media. No, it does not bring any value to what Quasar stands for nor does it enhance it. Quite the opposite. I’m getting tired of explaining this over and over again and my frustration grows by the minute. It’s quite sad to see people only using a small part of what is cooked into Quasar because of confusion or misunderstanding.

    Is there something missing from Quasar CLI? Please write a Github ticket. There are people wanting Coffeescript and Typescript support out of the box. We’re working on this! (There’s two github tickets opened on the issue). It will be available soon.



  • Thanks @rstoenescu for these explanations. If Vue CLI v3 will change nothing to the way we use Quasar CLI then that’s perfect for me. I’m loving Quasar CLI so far!



  • 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.



  • @Vinkman as I understand your frustration it is based on following assumptions:

    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
    5. Writing “application” is inherently tied only with one developer framework, and every other person in the team responsible ie for deployment, qa, vision, integration, marketing, life cycle, should use their own solutions, because this one developer wants to “feel” good working with his beloved “framework”
    6. Application plugin system is the same as architectural components of the final solution.
    7. Design of final application should be managed only by a said developer, who is entitled to “feel” good.

    Every single one of the above is false BTW.



  • @qyloxe Sorry, but your comment seems a bit rude. @Vinkman has some valid points and even if I think we should fix the things that are missing for people in quasar-cli, because Quasar is a framework and not a component libary, we should have a discussion about why people want to use vue-cli instead and what features are missing for them isntead of just discrediting all their points.



  • @a47ae please read carefully and express yourself clearly. Seems “rude” or is “rude”? It’s a difference - similar to @Vinkman conception of similarities between Vue and Quasar. Quasar “seems” as “framework” or “component library” but in fact it isn’t, because it is much more than that. Analogously in my comment you feel “offended” but in fact this comment only defines the assumptions and “axioms” of discussion. In your comment you use a term “framework” but this definition is wrong, too. Why? Because frameworks works on client side, in spite to the definition of “library” they process and emit events. I just hope that you used that term metaphorically, because if you want to talk “engineering” you should be very precise with used terms. In the light of this, Quasar works and helps not only on the server side, but it helps with architectural design of the whole system. In example - if we will be talking about simple solutions, chat apps or similar, then we will never agree becasue we will have 1000s of possible of options for design and every single opinion would matter. But, consider this - you should create an architecture for application with federated logins, with potential of milions of users, with team of hundreds of people, with mixed backend servers, localised reverse proxy configurations, AWS etc. In such scenario, your path of possible solutions will be really thin. Would your actual understanding of the “framework” be “right” or “sufficient” for this discussion? This is not rude, this is just different level of discussion. The level based on engineering, architecture, true/false and not on @Vinkman or @a47ae feelings. That’s why quasar could be one of the biggest “gamechangers” in modern software ecosystem. We saw such events before and we will see them in the future. There were PHP/dynamic pages, there were XMLHTTP and SOA, there were microservices, there were virtualization - but - there were jQuery also and webpack. Every single mentioned technology changed minds. Quasar changes minds too, so please, do not think about it in terms of what already was.



  • @qyloxe Sorry if I did not state this clearly, your comment is rude and you are disrespecting the time and thought @Vinkman has put into his comment, while your comment(s) do not add anything to this discussion.

    Also get your facts straight if you have to start this discussion:

    In computer science, a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software.

    In computer science, a library is a collection of non-volatile resources used by computer programs, often to develop software. These may include configuration data, documentation, help data, message templates, pre-written code and subroutines, classes, values or type specifications.

    A framework has nothing to do with “client side” or “server side” and a libary has not necessarily anything to do with event handling.

    Quasar works and helps not only on the server side

    Can you please give me an example where Quasar is involved in the server side?
    Even if you count server side rendering it is not really involved in any server side stuff.
    Quasar at its base is JavaScript that gets executed in the Browser (or a web wrapper like Electron or Cordova) so in my understanding browser = client.

    […] federated logins, with potential of milions of users, with team of hundreds of people, with mixed backend servers, localised reverse proxy configurations, AWS […]

    Oh I just won at buzzword bingo!

    Also this was never about feelings but rather about a focused discussion which @Vinkman wanted to start here and I guess @rstoenescu is als happy to discuss possible improvement to Quasar-CLI if people struggle with some of the recent changes.

    Nobody here stated that their opinion was right, but wanted to express their opinion on the topic.

    And in fact, your comment and my very own comment are the only comments here which do not add anything to this discussion so I would say we stop it right here and listen to what @rstoenescu has to say on this topic.



  • Well that’s the eternal debate “Frameworks vs Libraries”.
    Quasar is as a framework (front-end), so it’s normal that it creates a “frame”, a fixed structure to avoid reinventing the wheel for every app. I still find Quasar quite flexible for a framework, thanks to the extendWebpack function of quasar.conf.js.

    @Vinkman and @lbssousa if you want to use Quasar like a library, in a pure Vue-CLI project for instance, you should give Quasar UMD a try.



  • 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.

    1. 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.

    1. 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.

    1. 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?



  • Just created an issue in github while I wasn’t aware of this post. But I’m glad there’s a discussion about it, because few hours ago (after Razvan even replied to this topic), Evan announced remote presets, which I think it was the missing feature for all this to be even taken in mind.

    Besides of all the drama, I quote @Vinkman

    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.

    And regarding to this:

    If, for some reason, you decide to go against recommendations and just throw out the window 50% of what Quasar can do for you…

    By creating a new remote preset for vue-cli, we can still use webpack for electron, cordova, PWA, SPA, etc…
    Not a single piece of functionality is lost by applying current quasar-cli functionality into a vue-cli 3 preset. And in my humble opinion, you’re gaining a lot from letting your users stick with what they know from vue docs/courses (and ofc, vue’s CLI features, such as plugins).

    Sooner or later, there will be plugins/presets for pretty much everything that quasar-cli offers. But that’s just my opinion.



  • I’m inclined to agree with the posters favoring a more vue centric approach. While I greatly appreciate the introduction of the UMD offering, I worry that adoption both within my firm as well as broader adoption of quasar will suffer if a “dependency” on quasar-specific tooling is maintained. Don’t get me wrong, I love Quasar and the ability to use the same code base across all the platforms is a massive value add and the quasar cli is a very impressive feature in general. In fact, I wish I could rewrite our entire existing code base and all new projects strictly with the Starter Kit.

    Unfortunately this is not a reality. My employer has decided to emphasize the use of Vue going forward, largely because of the ease of gradual integration as well as the flexibility and granularity of incorporating parts of the broader Vue-centric ecosystem as they see fit on a project by project or even component by component basis. Even if that flexibility is actually still there behind the scenes, the optics alone of quasar specific tooling has already elicited groans from my coworkers and management. I’ve seen our firm pass over various libraries/frameworks/etc because of much less. I am being selfish in this to an extent as having to fight such a battle to use what I feel is the absolute best tool in the space is not good for me personally. However, I worry that others will have to fight the same battles and this will limit the potential of Quasar.



  • @sevan Exactly, +1.



  • In a way this happened to meteor. Some liked the brilliant, opinionated tool as is, some pushed for breaking up the parts so they went well into a larger ecosystem. To my <opinion> the parts people won the war, and for all I know they are very happy and Meteor is doing very well in the corporate space and making more money than ever before. I was a fan of the opinionated tool - it helps reduce my js churn when someone smarter than I is making damn good choices. I left meteor during the fight, found vue and loved its magic, then found quasar and absolutely worship its magic.

    I am not trying to put forward that this is a perfect analogy, but even though this is arguably a good problem to have, it is still a danger point. I think it’s the only time I’ve seen @rstoenescu loose his cool to any degree. That really should be a sign.

    I’d suggest @rstoenescu and team has amazing instincts and should stick to their guts. And I hope to get out of my dev cycle so I can start making money, because truly both quasar and vue deserve a hundred times more love and support than they are getting.



  • @jimmack1963 I used to develop with Meteor and I have a totally different opinion.
    No doubt Meteor was innovative a couple of years ago. But they got stuck with their painfully slow build system instead of webpack, integrated npm too late, and even with Evan You in their team they refused to make Vue a first class citizen. Their paid hosting business model wasn’t attractive enough so they took the GraphQL train and somewhat pivoted with Apollo.
    Just like you said Meteor is now more for corporate spaces, because corporate people have to support legacy software they sold to their customers. Who would recommend the Meteor prison ecosystem these days?



  • Going back to the Quasar subject, I hope @rstoenescu and the team noted that the template system Quasar-CLI is based on is going to be depreciated, thus unmaintened, as soon as Vue-CLI 3 is released. The current PWA template is already obsolete as it doesn’t integrate workbox, wherease Vue-CLI 3 does.

    Maybe it wasn’t the right timing to release the new template-based Quasar CLI when Vue CLI is going full-plugins. I do love Quasar but the lack of visibility regarding its obsolete template system makes me feel I’m building apps on sand. Maybe I’m wrong but I’m glad we can discuss about this in this thread, let’s make it constructive.



  • I agree that it is always bad to be forced to a specific build system by a framework, but I think Quasars case is a bit different.

    Meteor is a standalone framework, whereas Quasar is somehow dependent on Vue.js, so it is also dependent on how Vue.js apps can be build (e.g. vue-template-compiler).
    And because of that you are totally free to implement the build on your own just like pre 0.15 (I used to never use the cli to build but just call webpack directly via npm).

    The real benefit of Quasar CLI comes from having one tool which supports different build setups like SPA, PWA, Electron and Cordova. In the pre 0.15 days it was a bit of a struggle to set up an Electron version of your app after you initiated a plain SPA. Also having all the webpack config in your project scared lots of people because it seemed very complex to get your project up and running, even if most people never needed to touch the build configurationand in the past is was not really possible to easily upgrade your Quasar version without modifying all the changed template parts by hand.

    I think the problem here is that @rstoenescu commited lots of his time to build the new cli version and pack all the features in it. So I can totaly understand that its not really statisfying that you build such a tool, which right now is mostly state of the art and works flawlessly and people directly ask you to throw it all away because as @rstoenescu formulated it

    […] developers going for the new shiny thing

    without arguing what they are missing from the current solution.

    But I can also see where lots of the concernes are coming from. Of course it would be fatal if someday Quasar CLI would not longer work with the latest Vue.js version or was missing feature that makes it not longer usable for people. But if that happens it is most likely that Quasar as it self is not longer maintained, because why should @rstoenescu stop updating the cli somedays?

    On the other hand the current Quasar CLI setup is very similar to the Vue.js CLI v3 setup:

    • Both no longer ship a webpack config as part of the source but build this config during runtime
    • Both provide a config file where most of the aspects are configured
    • Both use webpack for building

    Where they are different:

    • + Quasar allows to build SPAs, PWAs, Electron apps and Cordova apps out of one source repository, as far as I know this is not possible with the defautl Vue.js setup
    • - Vue CLI allows for a plugin infrastructure which can alter the build process. Even Vue CLI itself is build using these plugins
    • - Vue CLI alows for “Chaining” of webpack config (https://github.com/vuejs/vue-cli/blob/dev/docs/webpack.md#chaining-advanced) which allows to later tap into webpack rules

    I guess webpack chain feature is easily integratable into Quasar CLI. So currently I see no real benefit from migrating to Vue CLI except

    Migrating to Vue CLI (while being a bit of a pain at first) propably saves dev time in the future.
    Lets assume Quasar is provided as a config of Vue CLI, then @rstoenescu never has to bother about updating the webpack config, learning about new PWA toolchains, testing and maintaining a cli by himself, while still being able to support Cordova and Eelctron via the plugin infrastructure.

    This integration would propably also support Quasars stand in the Vue.js community.

    So I am really looking forward to hear some input from @rstoenescu on this topic! 🙂

    P.S.: @LaurentPayot Are you sure the tempalte system will be deprecated? From your link I can only see that the PWA template will be deprecated but not the infrastructure as such. Also last time I checked workbox was not deprecating the other tools, but more combining the, while still being in development, but you are right, workbox is propably the future for PWAs



  • @a47ae templates usage is the number one problem Vue-CLI 3 was created to solve: https://github.com/vuejs/vue-cli/issues/589

    The short list of Vue CLI 2 templates was mainly about build systems. They are now replaced by a plugin-based configuration of webpack (a little bit like the Quasar’s extendWebpack function btw, except no templates are used at all)



  • @laurentpayot Ah, then this is indeed a strong point on moving part of Quasar CLI to the new Vue CLI platform.
    I think these are the plugins you are referring to: https://github.com/vuejs/vue-cli/blob/dev/docs/plugin-dev.md from my understanding these provide hooks into the cli tool, while the webpack part is, just like Quasar CLI, there for users to alter their config but it also makes use of chaining as linked in my post above.



  • @a47ae yes, wrong link 😉



  • I agree its such a pity to not have previously anticipated this, although Vue CLI 3 has been in development for a few months. I was concerned about its development and also the new Quasar CLI for v0.15, but I assumed Razvan was not only aware of this, but also taking Vue CLI 3 into consideration (and probably he did! But decided to go for Quasar CLI anyway for some reason, which happened, and now I totally understand his frustration when somebody shows up with something like “Hey, let’s get into the hype-wagon of Vue CLI!”), so I didn’t worry at all.

    I’m sure everyone here is aware of all the work and effort that required v0.15, but to make it clear, nothing from all that hard work would be lost by “migrating” to remote preset(s) of Vue CLI. It’s just a port, and the advantages of that are already well explained in the replies above.