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

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.

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.

Is there any upgrade guide planned? I see lots of app-level things have changed

Would be good to import vue-router on it, and some basic layout maybe?
For faster prototyping and issue reproduction: https://jsfiddle.net/9qv1n4uk/

If your card is inside a .container, .row, .column or any flex element, you can use <q-card class="no-margin full-height">, otherwise, you can use window-height instead, which may be too high for sure.
You can also try .fit class as stated here http://quasar-framework.org/components/other-helper-classes.html#Size-Related

Yes, it is (and much easier to do it if you were trying to import vuetify in quasar) but I don’t recommend it.
Vuetify is a complete mess (read my comment here about it), you’ll save a lot of time if you switch completely to Quasar, and quasar-cli
v0.15 is about to come, and with it a few api changes regarding to layouts so you may want to wait a few days more and do the switch.

“Brand new QLayout…” this is why I logged in forums today!!! Glad to see you’re steps ahead
Keep the good work! Keep it performant

I’m trying to create an horizontal list of cards like google’s play-store, it’s supposed to go inside a <div class="scroll"> container, but I don’t know how to handle a dynamic <q-card-title> height to keep <q-card-actions> always at the end (self-end)

This is how it looks now (note: second card’s price should be at the very bottom):

HorizontalCardList.vue

<template>
    <div class="row sm-gutter no-wrap">
      <div v-for="n in 10" :key="n" class="col-xs-5 col-sm-3 col-md-2">
        <q-card class="no-margin text-center full-height">
          <q-card-media>
            <img src="http://placehold.it/180x180" class="responsive" />
          </q-card-media>
          <q-card-title class="no-padding text-left on-right">
            <small class="ellipsis-2-lines" v-if="n % 2 === 0">Papas y boñatos</small>
            <small class="ellipsis-2-lines" v-else>Papas y boñatos y verga</small>
            <q-btn flat slot="right" class="no-padding">
              <q-icon name="more_vert" />
            </q-btn>
          </q-card-title>
          <q-card-separator />
          <q-card-actions>
            $ 1.000
          </q-card-actions>
        </q-card>
      </div>
    </div>
</template>

<script>
export default {
  name: 'horizontal-card-list'
}
</script>

<style scoped>
.row {
  padding-bottom: 1rem;
  padding-top: 0.5rem;
  padding-left: 0.5rem;
  padding-right: 0.5rem
}
.q-card-title {
  line-height: 1em;
  padding-top: 0.5em;
  padding-bottom: 0.5em
}
</style>

I don’t want to create a new topic for it so I’ll use this one.

What’s the advantage of using Quasar.LocalStorage over native api?

I’ve been following MaterialX designs for some time now, and I love their standars for material design.
You can take a look here: https://codecanyon.net/item/materialx-android-material-design-ui-components-10/20482674 (or download their app and play with it in your android phone https://play.google.com/store/apps/details?id=com.material.components)

Actually, not all of those components can be replicable with Quasar, but I think we can start working on a sub-site with examples and snippets.
Of course, some of those animations require complex scroll-related motion designs that may require exceptional performance optimization for the web.