A Vue "Native" component set Vs. "JS" Component set

  • @Ben-Hayat - I answered your question, I thought. 😄

    I’ll put it another way. If a framework is doing anything other than manipulating the Vue virtual DOM (with either SFCs/ components or the render function), then it isn’t a “Vue-Native” framework.

    Maybe they are using Vue’s render function/ component system and some other DOM manipulation method. If they are, that would be like tag lining up a Vue speed boat to an oil tanker and saying “it’s still a Vue boat”. Yeah, it might be using Vue, but all the crap hanging on to it (the oil tanker) is slowing it down, making it hard to understand, etc.

    Whoever is doing that kind of DOM manipulation mix doesn’t understand Vue or reactive component UI systems and I’d stay far, far, far away from any such system.


  • excuse me mr ben hayat whera are you from 🙂

  • @schumacher ;


  • @s-molinari ;

    I hear you Scott, and I agree fully. It’s just I need a rich Data Grid, Scheduler and Kanban and mostly are from the old jQuery wrapped to run with Vue.

    I was reading an statement from DevExpress that was very interesting about “Reactive Component”

    Unlike the wrappers, DevExtreme Reactive Components are native Vue components.


  • Yeah, the wrappers I wouldn’t touch. Although I haven’t looked, they have to be a bunch of bloat.


  • I’d just like to add that it’s not necessarily a bad thing to mix direct dom manipulating components/widgets into your Vue app, as long you understand the potential problems and can verify that those components won’t cause such problems. The only thing you need to be careful about are situations in which both Vue and the non-Vue stuff are trying to update the same pieces of dom. When that happens, they’ll each overwrite each other’s changes because neither are aware of what the other is doing. But in many cases, the non-vue components (such as some jquery components) ‘own’ the sections of dom that are rendering that particular component, particularly if they’re configured to execute in Vue’s mounted hook, when Vue is done doing its thing for that render cycle, then they’re not stepping on each others toes.

    For example, I’ve used utilities like stickybits in more than a few Vue apps to aid in sticky positioned elements. StickyBits works by directly manipulating the dom and adding/removing classes to targeted elements. It’s completely safe to do so, so as long as you’re utilizing things like that in a Vue safe way. My point is, although there is a difference between vue rendered components and vue safe components, limiting yourself to only vue rendered components might unnecessarily prevent you from taking advantage of a vast library of useful stuff out there.

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


  • Hah! Forget the Vue directive. Quasar has it’s own Sticky feature. Should have known that. 😃



  • I think you’re confusing the terms “framework” and “library”. I don’t think anyone was advocating mixing together frameworks. That would be a bit… crazy. But utilizing libraries is a very different thing. And not to get off topic, but vue-sticky does not have the desired features.

  • No. I was under the impression that Stickybits was needing jQuery to function. I see that it doesn’t looking deeper. My statement is still true about mixing frameworks.


Log in to reply