Quasar: Too many changes.

[syntacticsolutions]

I'm now moving from Quasar to iView because I think you guys are changing way too much. Vue is a good framework because it is lightweight and easy to use. I feel like you guys are very good developers, but you are focusing too much on your code structure and less on optimizing the code. I made a list that renders multiple multi-selects with chips and it made my page load times stall by 10 seconds. I had to substitute your multiselect for v-multiselect. Now I feel like with v15 I have to relearn your whole entire framework. Why should I do that when I can just use iView(which has a high amount of support for iOS style components(and they are extremely optimized)) and not have to relearn their framework every two weeks. Sorry guys but I don't like this version. Why should I be forced to use your paradigms? I like Vue's paradigms and that's why I use it.

[dennythecoder]

It seems that Quasar hasn't been declared production ready quite yet. The library continues to grow to meet new requirements and the API does change as the maintainers work towards a sustainable product. I understand that this issue was likely written due to some very valid concerns, but it might be best to take a step back and consider sticking with the other free libraries that you may favor. Quasar is improving dramatically IMHO, but iView and vue-multiselect are very nice and worth using as well.

[syntacticsolutions]

I'm just a little bit disappointed because I used to tell everyone about Quasar and now I don't want to tell anyone about it. I was productive in v0.14 and now I feel like I'm fighting against the grain. Vue is better than React because Vue is not opinionated. I feel like this framework is quickly becoming a React framework. I tried to change one of my routes to render a component without a layout component and I got an error stating that I had to use a layout component with a child component. That just doesn't make sense to me at all. You are going against all the makes Vue Vue.

[rstoenescu]

I am sorry that you feel this way. And I'm also sorry that you are giving up with v0.15, just before the v1.0, when the new architecture allows for seamless upgrades. Taking just a few minutes reading on the pages in Guide section of docs will allow you to understand the major step up that has happened to Quasar. You won't miss anything and most devs can tell you that upgrading to 0.15 is a matter of one or two days in the worst case. If docs are not enough, you also got the wonderful community on Discord always willing to help out.

Quasar is not just a component's library. Quasar is innovating in all fields that it touches. I urge you to take a step back and see the big picture. If you read the docs you'll understand just how easy it can all be once you get a grip on the "Quasar way", which again, is not hard! There's no other framework allowing you to write code once and then deploy as website / spa / mobile app / electron app with the flip of a switch button, like Quasar does. But this alone requires innovation, and mind that the underlying tools change too. Look at Webpack switching from v2 to v3, then from v3 to v4. Sometimes in order for progress to take place some changes are needed for the greater good. But in your post you make it like v0.15 is a whole new framework from what it was with v0.14, which is not true and might be misleading to people wanting to give Quasar a first try and reading this.

Sometimes Webpack changes, other times some other dev lib changes. The new architecture (which for devs just means moving some files around) hides away all the complexity that lies beneath it and lets us deal with it for you while you are sure everything "just works". We've got tired of Quasar taking the fault for breaking changes in dev libs and having to require devs to spawn a new starter kit when upgrading. Or for telling "do not upgrade to Vue version x.y.z yet which has an issue with its Y feature". Or for getting HMR broken in Webpack version x if used along package XYZ.

"I tried to change one of my routes to render a component without a layout component and I got an error stating that I had to use a layout component with a child component." --> QLayout is NOT required. But QLayout-ish components (QLayoutHeader/QLayoutFooter/QLayoutDrawer/QPageContainer/QPage/QPageSticky -- you were probably trying to use one of these) require to have a QLayout to stick on to. That's the component managing positions and offsets and it's the whole point of using QLayout. However you can very easily go on your own path and not use these components, but you can't just cherry-pick a layout component and use it by its own. Docs even have these grouped under the same roof/section. The sole fact, for example, that you now have a QLayoutHeader instead of using a QLayout slot, allows you for far greater flexibility -- the most obvious example is that each page can now have its own header or drawer, or footer.

I'm not sure what was your use case for the QSelect with chips and why it did not render fast for you. Sometimes the smallest details in how you use your Vue scope and computed properties matter a whole great deal. Join Discord, let's see it, let's break it down and improve your app. Let us help you. I am so sad to see someone talking about bad performance, because performance is a priority when developing the framework. If we missed something, let's discuss it and if it's indeed an issue with Quasar we'll improve it.

I really hope you reconsider all of these or at least talk to us on Discord if something seems "impossible" (because I assure you it's not), instead of opening up a Github ticket to offload negative feelings. It doesn't helps anyone, not you, not us, not to mention it's kind of rude.

[syntacticsolutions]

I'm not trying to be rude. I understand that this takes an immense amount of energy and I very much appreciate that you have built this framework. I have used it on a number of very successful projects.

I agree that Quasar has a lot of neat features. But I don't trust frameworks like Cordova that claim to be multiplatform anyways. I prefer to just write in Java or Swift4. I use Quasar because it has an amazing webpack configuration, and it works out of the box with a lot of styles and features, but I have come across a few issues. Maybe this has changed in v.15, but I think that the multiselect in v.14 could be optimized. So much so that it was making my page lag for like 10 seconds from rendering 15 records in a table that had a few input elements inside of them. I switched it to v-multiselect and the lag disappeared completely. It's definitely great to have such granular control over features of a framework, but I think there are ways to make it snappier. Also don't know if leaving the "IE" lines uncommented didn't work for me in IE11 because I quickly switched to using babel-polyfill and importing es6-promise afterwards. I didn't bother to raise an issue.

In the post you mentioned, I wanted to use the VueRouter in the normal way. I didn't want to use a component that lives in the src/layouts directory of your new CLI's structure so I instead tried to write the code the way it's normally written. Instead of having the parent-component-containing-the-child-components structure I just required the component that I wanted directly from the components folder. This is how I got the error.

Again, not trying to be rude or anything. I'm definitely invested in this framework. I even used the webpack config with a small project I did to test iview with. I just think that changing the way Vue and VueRouter does things is not the right way. That doesn't mean that I don't think it's an awesome feature. I think it's super cool to be able to use layout components with several children because then its possible to set different themes or have a mobile and desktop layout that render for different platforms.

By the way, I really really do appreciate what you guys do. Honestly, I've written a small UI framework and it was a shit ton of work and I think I only finished like 6 or 7 components. I haven't touched it for a while and I probably won't for another little while, but it was fun to get started. Kudos to you guys man.

[syntacticsolutions]

I think it would be best to separate the multiselect into another component that isn't the same as the select because there is a lot going on. I think that too many css features are being stored as variables on the components. I understand that it makes them look really cool, but it's probably using a lot of memory. I think that it's better to give some cool features and then leave the rest to the artist. Let CSS do as much of the heavy lifting as possible. I think most prominent features would probably be the coolest to keep. I honestly kinda want to help with this framework, but I don't want to be that guy who just comes in and tries to rip apart code thats been built over a long period of time. Love the framework though. It's definitely on the top of my list of favorite frameworks because it's extremely useable and it does look nice for the most part.

[laurentpayot]

I had a look at iView and in my humble opinion it is 一半完成 compared to Quasar :wink:

[natxocc]

Before Quasar I test with IView. It's a great framework, but when I grown my code I see that the performance was no soo good doing it with Quasar, all is ordered and my response is better. IView is easy to start to, but fault to sync between components as Quasar does. At the end, one of the things take me to Quasar was responsive modes: IView, Element UI... works well for desktops, but horrible or impossible in phones. I need to code once for everywhere, and only vuetify and Quasar does like I need. But I decided for Quasar for Razvan, is a great talent and does a great effort every day sharing his work to all.