vue-cli 3.0 and the future of quasar-cli
sevan last edited by
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.
jeffatef last edited by jeffatef
@sevan Exactly, +1.
jimmack1963 last edited by
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.
a47ae last edited by
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)
a47ae last edited by
@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 ;)
Frondor last edited by Frondor
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.