Does anyone have any thoughts on future Vue proposed changes w/r/t Quasar?



  • See below for a raging discussion on proposed changes to Vue:

    https://news.ycombinator.com/item?id=20237568

    And here is a direct link to the RFC:

    https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs/0000-function-api.md



  • Don’t be influenced by the FUD. 😁

    Scott



  • Well, firstly I’m quite impressed that they have a courage to say “classes doesn’t work for us - we tested them and js is a protype based so we will use that”. I have a similar feeling, that using classes in JS is a cancerous concept from Anders Hejlsberg, who sadly by last 30 years tries to put those simplistic delphi 2.0 style views on every technology that he touches.

    In the context of Quasar, I assume, the biggest clash of ideas/potential for improvement will be in the app extensions. This is very similar concept because Quasar needed a way to extend itself on many levels of abstraction. With the new function based component setups I assume it will be possible even without app extensions. As for now, it is at the RFC level, obviously they see the problem. As for now, I trust them because, they saw the future in the past, and that’s why I started to use Vue. I have a feeling, that with those new concepts, they see the future again.



  • With the new function based component setups I assume it will be possible even without app extensions.

    “It” I assume being Quasar? Um, App Extensions offer a whole lot more for developers than the new API offers for Vue. The Vue API is at component level. The App Extension API is at Quasar Framework level. 😄

    Scott



  • Seems ok at first look, but i certainly don’t like the define first then expose (that’s like writing java) had few run ins with kotlin made more sense but then flutter came (…screw it), and it’s easy to get lost in a god function (although one can organize data/methods/computed etcc… but then after defining that, expose again xd). As much as i like native perf, it’s a big pain in the ass to maintain (dunno bout ios), beside webviews have come a long way… no need to panic, the old api will still be supported, so you don’t have to go crazy about refactoring. Have to see what they’d do with vuex tho, so far only saw removal of mapXxx helpers. And i agree about classes for non oop language.



  • But JavaScript at it’s heart is OO. It’s not a class based OOP language, yes, if that is what you meant. The define and then expose is needed for better TS support, from what I understand. So yeah, unfortunately more like Java, but still far from Java really, thank god!!! 😁

    Scott



  • I’m a very simple guy … and I’m not a full-time programmer like many of your guys … so what attracted me to Vue in the first place was how simple and understandable it all felt …

    To me … I want simplicity and stability (and hopefully longevity) over all else … Vue 2 gives me all that now … Quasar gives me a great component framework over the top of that … I have what I need …

    I haven’t read the RFC … mainly because I probably wouldn’t understand a lot of it …

    BUT …

    From the sounds of those discussions … if Vue push ahead with radical changes … it sounds like there might be a community driven fork of Vue 2 …

    AND … Quasar could potentially move forward using that …



  • See…that’s the FUD working. Read the RFC please!. Here are some points to thwart the FUD.

    • The changes aren’t radical, just better and more composable JavaScript.
    • I’m fairly certain Razvan is also in the background helping mold these decisions. @rstoenescu - do correct me if I am wrong.
    • If true, that means, the decisions being made will help Quasar become better too (which I believe are true anyway), like for TS support, which seems to help businesses jump on the Vue bandwagon, which theoretically can help Quasar with the mullah!
    • I highly doubt anyone will fork Vue, as long as the Vue team are still going strong making Vue better. The changes being made seem like they are major, but they aren’t. They just require more responsible and proper development, which means it’s on us. And yes, it means some work to refactor. But, that shouldn’t be a reason not to change for the better.

    To be fully honest, I am also fighting the urge to be on the detractor side of this RFC, only because as an intermediate developer, the clear “constraints” of the options object based API helped me do fairly good Vue programming and helped me jump into other people’s code and understand it fairly easily. You’ll notice in the discussions a number of people also note these reasons for taking Vue over React.

    However, as I gain experience, I see that the options-object based API has limitations. You can get easily 80 to 90% of an app done with it, but if things get complicated and larger, being able to better “split up” your code means better scalability and in the end, if done right, even better code comprehension.

    You see, currently Vue with its options object is predetermining where certain pieces of an SFC’s code should go. data under data, methods under methods, computed under computed, watchers under watchers, etc. This in turn means, a feature of a component may be spread out over a number of options. Let’s say for a certain feature, you need data, some methods, some computeds, and a lifecycle hook or two. If you have a couple of other features mixed in that same component, then you are looking up and down the component in the different option groups to make sense of the feature. With the new API, a feature can be encapsulated in a single function and all of the necessary other “hooks” like state/value (instead of data), methods, computeds, lifecycle hooks, can be “bundled” up in that function.

    The examples in this gist don’t quite show this, but in the end, it does show the API differences and I hope you can agree, they aren’t that major. Look at the to-do app..

    The ability to better “compose” features of SFCs into their own functions means, a feature can be easily “broken out” into its own module and viola, you have a better more extensible Vue system (replacing mixins and their disadvantages). I read this article from Sarah Drasner and at the time I thought, “Yeah, whatever”. But now. Wow, it makes total sense to me. 😄 BTW, please don’t get confused by what Sarah writes. It was a pre-alpha POC that she refers to from Evan. The new API is different (but the concepts are the same). Read the RFC!!!

    Sometimes, you have to trust those who know more than you to lead you in the right direction, that even the best people get things wrong and need to do things differently to make everything better for everyone. This is a situation like that.

    And, that’s my take on the new API. 😄

    Scott



  • @s-molinari said in Does anyone have any thoughts on future Vue proposed changes w/r/t Quasar?:

    Sometimes, you have to trust those who know more than you to lead you in the right direction, that even the best people get things wrong and need to do things differently to make everything better for everyone. This is a situation like that.

    And, that’s my take on the new API. 😄

    Scott

    That was actually my point …

    I haven’t read the RFC because it’s above the level where I am competent to comment …

    SO … I will just continue with my Quasar development … quite confident that if Razvan feels that Quasar needs to stay with the Vue 2 model of things … then the possibility of a fork of Vue provides that option … and if Razvan feels that the Vue 3 model of things is the way to go … then Quasar will follow that … and I will follow Quasar.

    Whatever … I’m just going to trust that the experts in charge of Quasar will lead me in the right direction and for now I will focus on just utilising the existing Quasar and Vue to provide the apps and solutions that I wish to create



  • Yeah just ultimately ignore those reddit/etc… posts and go straight to the official rfc site. Just read whole of it last night, nothing like what the fud nay sayers are complaining about, if you notice those peeps just shoving you with wat framework they want you to use. Vue will be fine :).



  • Good news! The object API will currently NEVER be deprecated!!!

    So, everyone can relax and concentrate on the problem at hand. Making the new API more acceptable (either through concrete suggestions or teaching). 😃

    Scott



  • Yeah, it was to be expected xd. Would definitely try the new api tho, along with learning ts, been aching to learn it for ages but nvr got the chance lol.



  • It’s actually being added to Vue 2.0 as a plugin!!! How cool is that? 😁

    Scott



  • Oh, that is indeed cool, so peeps can slowly adapt it before v3’s release.



  • Yup! 😄

    Scott


Log in to reply