Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API

From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "vuejs"
-
I always had this mentality that I shouldn’t rely on a certain library or framework for my entire project because what if one day they stop supporting it. (Yeah I’m talking to u vuetify) That’s why I came up with this code structure that for everything that I wanna do I have a ‘driver’ library all coded by myself that interacts with that third party framework or library so if they stop supporting it I could just change a couple of lines of code in my driver file and my codebase should be working again. But I feel like this ‘driver’ approach is not the most efficient way of going in terms of memory usage. Do you guys think I should keep it simple and directly use those libraries or this is actually not a bad approach.7
-
That feeling when you get the job because of the JS but most of the work is fixing server side xml to play nicely with several vuejs components on the client side.
Or vice versa. Probably the vice versa.2 -
I recently refactored a form with complex client side interactivity for one of my clients replacing jquery with vuejs in the process and I'm absolutely baffled by how easier it is to reason about everything when you think of the UI as a function of the state. Only devs who have done both imperative and declarative DOM manipulation at some point in their life can understand the joy of doing this. And all of this can be done with just a simple script tag without having to bring in complex build process that has plagued the Javascript ecosystem.