@joaopaulofilho @MusicForMellons @rstoenescu
I believe that if we could get apollo working with Quasar, in what ever way necessary (and naturally as professionally as possible) we could also “spread the word” within GraphQL circles (which is growing in leaps and bounds) about Quasar and possibly get some traction with that community.
Scott
@Nicholas said in The 0.14 beta release is available!:
0.14 Beta looks fantastic! Awesome job!
Do you have any idea of a possible release date for the final version of 0.14, or a timeframe?
Razvan will be taking a well earned vacation in the next few days. He’ll be off for up to about 10 days. When he comes back 0.14 will be finalized. So, 0.14 final will be determined towards the end of July.
We feel the beta is pretty stable currently and there are no plans to make any more major changes. So, there should be no worries on anyone’s part to run with 0.14 now and to build beautiful apps with it. 
Scott
Ionic Vue is still in its infancy. It’s still alpha. And it’s not getting that much love. It was a third party addition and was later added to Ionic. So, it wasn’t even developed by the core Ionic team. And, Ionic/Vue is still only the new Ionic Stencil bit in Ionic 4 (i.e. the abstraction of the components from the Angular core) bound to Vue. It’s not really a Vue.js based framework, where the components are also built from Vue.
That alone should be enough to tell you, Quasar is a better choice.
But, there is more.
The Quasar CLI takes care of building your different applications. With Ionic. You must use Vue, so you are talking the same disadvantages (or advantages) as if you were using Vue CLI and Quasar as a Vue CLI Plugin. See here please: https://quasar-framework.org/guide/
Quasar’s Vue based components are built for speed and developer efficiency, and not only for SPAs, but for all manner of applications possible with Quasar. With Ionic, you aren’t getting this TLC for developer efficiency. Quasar has been built for over 2 years now and only on Vue. Ionic can’t come even close to this.
With Vue 3.0 coming around the corner with even more efficiencies, you’ll gain those efficiencies right off the bat with Quasar. With Ionic, this isn’t a given at all.
Quasar has more components for you to work with. And again, they are Vue based. That means consuming them as a developer will just make better sense.
Quasar’s team are Vue aficionados. That means, you’ll get more direct help, if something goes wrong. And, I’d say the Quasar community is larger now, than the Ionic/ Vue community is. So, if you get stuck, and you are more likely to get stuck with Vue/Ionic, because the Vue binding code for Ionic is still alpha, you more than likely won’t get the help you will get with the Quasar community.
Are you sold yet? 
Scott
As of Quasar version 0.13.2, you can now use a Vue config setting to turn off the (annoying) production tip you see in the console, when working with Quasar in dev mode. You know, this one:
You are running Vue in development mode.
Make sure to turn on production mode when deploying for production.
See more tips at https://vuejs.org/guide/deployment.html
To get rid of it, all you need is:
Vue.config.productionTip = false
Happy programming!
Scott
We have a PR for a feathers API wrapper. https://github.com/quasarframework/quasar-wrapper-feathersjs-api
And the maker of that did a tutorial too. https://github.com/claustres/quasar-templates/tree/feathers-api
Do let us know, how the rest goes (haha, pun not intended). I’d be very interested in how you get Quasar running with Nuxt.
BTW, I am working on a GraphQL API for Quasar. The start is also made with a simple wrapper. https://github.com/quasarframework/quasar-wrapper-graphql-api
And a demo app is also in the works, similar to the Feathers demo. All of this is WIP, so take it with a grain of salt.
Scott
Good news! Version 0.14 will have more icons.
The docs are still rough, but it should give you an idea of what is coming.
https://github.com/quasarframework/quasar-framework.org/blob/dev/source/components/icons.md
Scott
I’ve been working on the docs and I can attest to the fact that 0.14 is practically like a new Quasar. There are so many improvements. And to think Quasar was already a great piece of work. This release is going to be awesome.
Scott
Hey Jeff.
I believe the main cost is an OSX native device (i.e. MacBook or MacMini), which Razvan would need to build the app and upload it to the app store for approval.
If you are really interested in Quasar and have the money to spare, you can donate to Patreon for recurring donations or to Paypal for one time donations.
Scott
This is currently the only admin “app” built on Quasar I know of.
https://github.com/odranoelBR/vue-quasar-admin-example
https://quasar-admin.firebaseapp.com/#/
Scott
I’ll tell you what. Once I get spinner and the new observable sections out of the way, I’ll jump on layout to get it documented for you. Ok?
Scott
It isn’t my call to make, but I currently can’t see why 0.14 won’t be released today. The reason for the delay was the unfinished Play App, and as I mentioned above, it seems 99.9% finished to me. So, I think the release is on for today. Or worst case, Razvan doesn’t wake up from what must be like a comma to him. He’s been putting in some really wicked hours to get 0.14 ready. He worked until almost 6 a.m. this morning. 
I am excited for the release too.
Scott
Out of curiosity, what else is it that tachyons has, that is missing for you in Quasar?
You mentioned these
tachyons has the small/medium/large breakpoints
tachyons has some colors that are similar but do not match up to the palette in Quasar.
Which Quasar has or offers ways to get around itself.
Breakpoints: http://beta.quasar-framework.org/components/flex-css.html#Responsive-Design
Theming your own colors: http://beta.quasar-framework.org/guide/quasar-theming.html
Scott
https://github.com/alibaba/weex/releases/tag/v0.10.0
Native apps with Vue 2.0 made possible now with Weex, Alibaba’s new development platform for iOS and Android, which is based on Vue. It is a great milestone for Vue. I would guess it will be only a matter of time to be able to use Quasar to build native apps? Maybe?
Scott
To me, this is another great example of a devland OSS or even paid for component. Quasar should be a basis for such additions, not have them built into it.
Scott
Although I agree with NOT needing jQuery to build a Bootstrap like theme. It would be super excellent, if the theming feature of Quasar was more abstracted out of the source code. By that I mean, one could come up with a similar look to bootstrap with Quasar “base” components. In other words, the Quasar components should be broken down so far, that other devs can create their own themed components with them.
Currently what Quasar has isn’t theming. It’s styling. The title of that section of the docs has always bothered me.
For instance, currently QBtn has the ripple directive built in. This is a step too far in terms of theming. QBtn should be “theme free”. There shouldn’t be any decision making code for any theme in any “base” component! So, let’s call the base button QBtn and have QBtn-md or something to that effect. With this kind of direction/ thinking/ concept, another dev could take up QBtn and make a QBtn-bs for Bootstrap. Or QBtn-ios for an iOS theme, or Billy Bob could come up with some new theme standard and call it QBtn-bb, 
etc. etc.
Oh, and the ability to include components into the package system should be extended to any component “theme built”, not just Q’s components. So, if devland wants to package either iOS and MD or even BB as part of their Quasar usage, they can.
I’m just rambling with no idea if this is feasible. But, it certainly would be super cool, if it were possible. For sure, currently, Quasar is much too opinionated for it to be theme-able. It is an iOS or Material Design themed component framework, with a styling option. It is not an open component framework with packaged MD and iOS themes, with components which are “theme-able” from other devs. Quasar would be THE most awesome framework, if it were. 
Scott
Sure, you CAN use the components/ features of other frameworks, but then you are adding the bloat of an extra framework to your site/ app just for those one or two features. That sort of defeats the purpose of having “A” framework. Right? So, there are two concerns to have, when mixing frameworks. One is the side-effects they may have. The other is the bloat.
Better to use Vue’s version of sticky as a directive: https://github.com/rguanghui/vue-sticky
Edit: There are times, where you need other “frameworks”. But, they should be specialized in doing things outside of DOM manipulation. One example was in another thread here in the forum, where a user was adding Apex Charts to their application. That is an SVG Charts framework. Sure, it manipulates the screen, but it isn’t a DOM manipulation system per se. I think you get my point.
Scott
I don’t know of one. Looking at the Material Design spec, there is also an “exposed” select type, which Quasar doesn’t yet offer. Might be worth a suggestion?
Scott
There is something that I think people tend to take falsely, when they see Vue for the first time. They think, “Ha, that is a toy. It’s not going to work for more powerful applications.” What they are misconstruing is Vue’s affinity to attract newcomers to it as being “too simple to be used for something complex”. It’s because it’s API, it’s way of doing things, is much more beginner friendly. This beginner friendliness starts with its CLI being a first class citizen, to the UMD version, for implementing it in existing projects, to it’s concepts, which make sense at any level of experience (except for the concept of slots maybe , which once learned, is amazing).
People say, Vue’s API and having to learn it up front is more complex than React’s. I say, in the beginning maybe. However, Vue’s bit of opinionation in this regard means a form of constraint and constraints are good in programming, as long as what can be done with it as a tool is flexible. Over time, these constraints mean code bases are similar and easier to reason about and require less “best practices”. Less best practices means better more stable code i.e. better quality and for sure, a lot less cognitive load over time.
I don’t know if you’ve noticed, but in Twitterdom, Evan You started a bit of a flurry, when he noted how he likes React hooks. Well, if you went to the React side of the ball park to find out why they came to life, you will find this article from Dan Abramov:
https://reactjs.org/blog/2016/07/13/mixins-considered-harmful.html
There is also this video, where hooks was presented as the solution to “what sucks in React” (remember, this is Facebook telling the world what sucks about React):
https://www.youtube.com/watch?v=V-QO-KO90iQ&feature=youtu.be&t=284
Classes ( I still get a good chuckle thinking about this design decision being a mistake)
Wrapper hell / Logic Sharing
Giant Components
Those are some major problems. I’ve not seen these same issues in all of my time watching and listening to the Vue community. Maybe nobody has gotten to the size of Facebook yet, but still, I can’t imagine them being a Vue problem.
Yes, hooks have clear advantages over mixins, but I would say, because Vue didn’t go down the road of inheritance, and instead followed the mantra, “prefer composition over inheritance”, it could avoid most of those problems for the most part. And I truly believe, if your components follow SRP, issues with mixins are limited too.
Of course, React is now going back to functional components and with hooks, it solves it’s ugly problems. So, it is advancing. That’s a good thing. And if you watched that video, React is starting to look more and more like Vue. Hahaha!
At any rate. Both Vue and React are powerful reactive UI libraries. I still think Vue has advantages over React, because it does it’s job smartly, in a way that is simple, yet powerful. That is the ultimate goal in programming such a tool. React, to me, is less simple and maybe too powerful and that “too powerful” can be understood as, allows for too much crap. Which, as you can see, even Facebook found out about the hard way.
Scott
