vue-cli 3.0 and the future of quasar-cli
qyloxe last edited by qyloxe
@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.
[…] 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.
LaurentPayot last edited by LaurentPayot
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
extendWebpackfunction of quasar.conf.js.
Vinkman last edited by
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.
- Quasar is just the “better Vue” therefore it should feel “more good”
- Vue packaging/build concept is mature, well thought, good fit for everyone, and Vue is a “white” magic, which should handle everything for everybody
- 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.
- 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.
- 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.
- 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
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.
Quasar Vue cli 3 plugin: https://goo.gl/fNxDU3
Quick summary of for/against arguments, as of writing this. You’ll have to decide for yourself.
- Using vue cli plugins
- Testing (unit & end to end), which Quasar CLI does not yet support it (it’s currently under work)
Disadvantages, due to current vue-cli 3 architecture:
- no ability to “write code once then deploy as a SPA/PWA/Mobile & Electron app”; you will usually pick what you want to build (SPA or PWA – only) right from the start when creating the app with Vue CLI; even if vue-cli will support these
- only SPA and PWA supported; can’t build Mobile or Electron apps as vue cli doesn’t support it; the smart algorithms behind Quasar CLI use more than one webpack config, which is not possible with Vue CLI
- none of the features embedded in quasar.conf.js; for many, you’ll have to manually edit your
- building/developing with one theme and switching to the other requires editing the vue config (in package.json or vue.config.js, depending on what you picked when creating the vue app)
- you lose the ability to effortlessly upgrade your the Quasar version that you are using as with Quasar CLI; it will possibly require you to manually edit
src/main.jsto update to latest specs
Wow. I’m impressed with @rstoenescu 's mature response in providing the Vue cli 3 plugin. As for myself, I’ll be using the Starter Kit for now.
One thing I wasn’t clear on is whether vue-cli 3 introduces breaking changes and can’t be used with quasar-cli at the moment - vue-cli is a dependency, right? Once vue-cli 3 is out of beta it will be the default installed with the basic npm install command, won’t it?
Another thing I’m not clear on is what vue-cli 3 means for quasar’s development going forward. I don’t imagine @rstoenescu will ignore it altogether, but I don’t think I’ve seen a statement about that.
In any case, I’m really enjoying working with Quasar.
I believe all of the disadvantages listed can be solved/nearly solved:
no ability to “write code once then deploy as a SPA/PWA/Mobile & Electron app”; you will usually pick what you want to build (SPA or PWA – only) right from the start when creating the app with Vue CLI; even if vue-cli will support these
Not true, you can always call
vue add my-plugin
only SPA and PWA supported; can’t build Mobile or Electron apps as vue cli doesn’t support it; the smart algorithms behind Quasar CLI use more than one webpack config, which is not possible with Vue CLI
- PWA: @vue/cli-plugin-pwa (official)
- Mobile: vue-cli-plugin-nativescript-vue (TRULY NATIVE, by nativescript-vue, semi official)
- Electron: vue-cli-plugin-electron-builder (made by me)
You can use a custom webpack config by calling
api.resolveChainableWebpackConfig()and modify it as you wish. With this PR you can import the build and serve commands and call them with a custom chainable webpack config (used in vue-cli-plugin-electron-builder).
none of the features embedded in quasar.conf.js; for many, you’ll have to manually edit your src/main.js file
This is true, however, I bet this could be implemented in a plugin by having it create a custom
quasarImports.jsduring build/serve and having it imported in
main.js. This is also a relatively minor issue.
building/developing with one theme and switching to the other requires editing the vue config (in package.json or vue.config.js, depending on what you picked when creating the vue app)
With the previously mentioned PR, you can overwrite the build/serve commands, calling them multiple times for each theme with custom output directories for each build.
you lose the ability to effortlessly upgrade your the Quasar version that you are using as with Quasar CLI; it will possibly require you to manually edit src/main.js to update to latest specs
Most of the time, it is quite easy to upgrade to the new version, and will be easier with the custom
Some other features of using vue-cli not mentioned:
- Way more community plugins (unit testing, typescript, etc…)
- CLI ui, making it super easy for new developers
- Better support, the entire vuejs team is working on vue-cli
- Easier integration with existing vue-cli 3 apps
- Less risk for large projects as they are not locked into quasar
- Less work for quasar dev team as they have less bugs, don’t have to add typescript/testing support, and just less code to maintain in general.
I look forward to the bright future of quasar and I hope my comments will be taken into account.
“write code once then deploy as a SPA/PWA/Mobile & Electron app” – you said: “not true”. Then you listed a mobile vue cli 3 plugin which uses nativescript (so NOT actually web code using web api). I’d really be interested to see how you can write one codebase then run it on electron and nativescript
The main point is that if you add one of the PWA, Electron or any other “Quasar mode-like” vue cli 3 plugin, you’re building only PWA or only Electron, or only (…fill in the blanks here…). Unless you create multiple project folders. This is for starters. Then, saying you can add some plugin is not equal to having same feature-rich functionality as embedded into Quasar CLI. Some examples that immediately come to my mind (the full list is big): command line parameter tells what you want to develop/build (SPA, PWA, Mobile, Electron), directly develop on a mobile phone (or emulator) with HMR, automatic handling of statics (without the need to change any path) regardless of vue router mode chosen, and sooo many more.
I believe each developer should chose one path after they know both (Quasar CLI / Vue CLI) really well, which I feel it’s the thing missing in most comments here. My recommendation is Quasar CLI, but you can safely go with Vue CLI too, depending on your needs. In any case, it’s no war between Quasar CLI and Vue CLI as some might imply. Quasar is about flexibility and it will forever be. You want to use Vue CLI 3? Ok, go that path. You want to get the recommended experience with Quasar, go with Quasar CLI. There’s a Nuxt module coming up, and lots more. Choose whatever fits your needs best. Flexibility. Nothing more.
Also mind the timestamp of each comment and the corresponding vue-cli state at each of those moments. For example you’re saying vue cli ui was not mentioned. It didn’t exist at that time
LaurentPayot last edited by LaurentPayot
I’m going full PWA so I do not need Electron nor Cordova. I use vue-cli 3 with a customized Quasar UMD build (removed unneeded components and css with a bit of metaprogramming) and with a custom script at startup I can dynamically load different themes depending on the platform.
The more I use vue-cli the more I think quasar-cli is amazing because it really hides a lot of complexity from developers.