vue-cli 3.0 and the future of quasar-cli
-
How could Quasar Framework benefit from upcoming vue-cli 3.0? Is there any possibility to quasar-cli become a plugin for vue-cli, rather than a standalone executable?
-
@laurentpayot said in v0.15 news:
Vue CLI v3 is out in alpha. It looks like it’s totally different from v2: doesn’t use templates any more, Cypress (
) for end-to-end testing etc.
Will that be transparent to Quasar CLI or will that lead to future incompatibility issues for projects initiated with Quasa CLI v0.15?So yes I’m wondering too…
-
Looks like Vue CLI V3 integration to Quasar is a common wish: https://github.com/quasarframework/quasar/issues/1576#issuecomment-369857721
@rstoenescu could you tell us more about this?
-
Current quasar-cli already wraps around vue-cli. I suspect we will se an update once vue-cli 3.0 is out and stable -
Right now I’m uprading to the Vue-CLI-V2-based Quasar V0.15.
It would be nice to know if I’ll have to spend hours again upgrading to the next Vue-CLI-V3-based Quasar once it is out. Because then I would just wait for the next release instead of wasting my time… -
Let me shed some light on this. From what I see, it’s one of the most misunderstood tools from the Quasar ecosystem.
- The future of Quasar CLI is… well… using Quasar CLI, because of what I am about to briefly explain.
- Quasar CLI does NOT wrap vue-cli in any way.
- Quasar “init” command calls “vue init” in the terminal. That’s the only connection between the Quasar CLI and Vue CLI.
- 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:
- Vue is just a “better javascript” and it feels good
- 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
- 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”
- Application plugin system is the same as architectural components of the final solution.
- 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 theextendWebpackfunction 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.
- Vue is just a “better javascript” and it feels good
- 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.
