When would Vue 3's end of life be?

[LarsDol]

Hi!

Just a quick question. Has anything been announced about VUE 3's EOL yet?

Thanks!

[LinusBorg]

No. We aren't even thinking about that yet.

When we do another major release, it will be much more modest and ship few breaking changes that will be easy to migrate.

We certainly don't want to repeat the pain of Vue 2 -> 3.

[LarsDol]

Ok good to know, thanks for the swift response!

[voltuer]

are you going to do it the right way like React, which hasn't broken backwards compatibility in 10 years?

can i trust Vue for a 10-year-lasting project?

[SchneiderOr]

Have you tried using react-native and do such upgrades? cause i did with more than few apps, React native they did it terribly bad there despite being such a big successor of a project, therefore no one can assure you its gonna be always backward compatible but i think that in the last few years vue built up a very strong infrastructure that can definitely stay for long

[benatkin]

I haven't found React to be easier to upgrade in practice.

[Shamoil009]

@SchneiderOr I completely agree that react-native did quite break a lot and upgrading it or its packages is quite a pain. But react on the web side is a different story.
I had to add some features and make some changes to the old Reactjs web project and it just worked and I didn't even hit a wall while doing it. It became difficult when there is an old project and its framework support was gone all its packages were deprecated and 2-3 years old.
It is difficult to add some features whose support is gone and upgrading would break other things.

[ememisya]

Exordio
on Oct 2, 2023
Of course you can’t, you can’t even think about this in the concept of modern front-end frameworks.

This reply made me laugh pretty hard. Of course you can't.

I personally decided to switch to Vue 3 because they promised a lighter framework and that really is true.

I still maintain project(s) that are Vue 2, with Vuetify 2.5 and it will likely take a long time if never for them to be switched over (perhaps a programmer after myself will do it) because of policy reasons.

More bleeding edge projects I work with use Vue 3 with Vuetify 3 and alongside better typing support I liked their more frequent use of proxying and I must say just better reactivity in general having written a few projects already using it. You instantly notice the changes during debugging as you get those infamous "'set' on proxy: trap returned falsish" errors and get warnings about badly written code whereas Vue 2 just lets you do it.

I could not break away from "vue-class-component": "8.0.0-rc.1", solely because of how much I liked the Java-ish look and feel (those are not really "annotations" but they look like them). That's a personal decision since the the back-end of the projects are Java and it just feels more familiar.

I mean look at this component for listing entitlements:

import { reactive } from 'vue';
import { Vue, Options, prop } from 'vue-class-component';
import { mapGetters } from 'vuex';
import { formatUtcToLocal } from 'gs-services-es-commons';
import type { Authentication } from '@/store/domain/authentication';
import type { SearchEntitlementsRequest } from '@/http/api/ed-entitlement';

export class Props {
  fragmentFilter = prop < string | null >({ required: false, default: null });
}

@Options({
  computed: {
    ...mapGetters(['authentication']),
    ...mapGetters('ed-entitlement', ['entitlements', 'nextPage']),
  },
  methods: {
    formatUtcToLocal,
    isNumber,
  },
  emits: [
    'loading-complete',
    'loading',
  ],
})
export default class EntitlementsComponent extends Vue.with(Props) implements PageableDataTableComponent {

  name = 'Entitlements';
  loadingBuffer: string[] = [];

  $refs!: {
    fragmentRef: VuetifyValidatableInput;
  }

  get loading() {
    return this.loadingBuffer && this.loadingBuffer.length;
  }
  //...
}

How Java is that?

Vue 3 devs made the argument that the script setup syntax is faster. While I see their point I am more comfortable with it looking more like a Java class than anything else. I know my $refs are just under the class name, I know the props are just above, and imports above that.

I don't need to get lost in the template looking for refs or props or what the component emits but I know if I scroll up above the imports there is the template.

.vue files are pointless if you really wanted to get to the root of the argument. It should all just be pure code with maybe .html imports which can all be validated separately. Once the project compiles it doesn't quite matter as it is a minified .js or .wasm file served to the user in production so we are really discussing what's more maintainable and promotes collaboration. It's a big beast to tackle but it's not like nobody tried it before. See Kotlin. A good example is KVision. Ultimately we are all trying to cut the fat off the budget. I think future generations will argue, "Is XML really necessary for HTML? Isn't it overkill? An open tag AND a close tag? Did you try JSON? You know transmission is a bit more reliable today right?" 😃

Even though Vue 3 advertises vite by default I stuck with webpack throughout my project migration efforts. One reason for that was that the projects I am building do have many individual files. Vite does not play well with numerous components and after a certain number of files you lose the performance whereas the webpack approach has the same slightly longer load time (we are talking fractions of a second) but remains the same for anything you throw at it. I did not switch to vite tools except for a single library (seen as gs-services-es-commons above) the rest of the projects share which makes use of vite's support for tools like roll-up as well as 'vite-plugin-dts'. It's also my way of keeping an eye on the newer stuff. Nothing like a library to gauge modularity.

But the main reason is that webpack is more mature and stable and has a ton of plugins to do just about everything. I also customized webpack in my setup where some didn't quite translate to vite at the time I was making the switch (will probably take another look in the future if and when the vite community has made the necessary plugins).

I think overall the migration to Vue 3 is worth it and they didn't disappoint me with everything I did convert over.

I can't say the same about Vuetify 3 but that's a risk I took and it paid off in time. That being said if you switched to Vuetify 3 early your package-lock.json file probably saved you in more than one occasion. Initially they did not have some of the core components people rely on like data tables but after a few bumps along the road it appears to be fine. If you stuck with their development headaches as they released revision updates and broke major stuff you'll notice that they finally came through and it is a bit more stable now than when it was originally released.

Vue 3 sort of takes the average JavaScript dev and forces them to use TypeScript, but slowly. That's a good thing.

Is that the end of the road for Vue and it will remain forever at version 3? I don't think so. Of course it will have an EOL and of course there will be a Vue 4. Is the optimization complete? No. Their main source of inspiration are the Web Browsers, and look at all the features they are offering today that simply isn't utilized.

If you really thought about it .wasm is what the entire web should be based on but there are security and other reasons why that is not the case yet you can't beat the performance. This is what the only JavaScript on your page should look like: https://wasm.continuation-labs.com/d3demo/d3wasm.js

There absolutely is room for Vue 4 and many others as the browser isn't quite utilized to its full capacity and that's also subject to change depending on what those global browser conferences appear to conclude in public but my personal guess is that Vue 3 is trying to marry the world of React devs and the jQuery/Dojo people from the prior generation and it's doing a fantastic job at that.

[ankitsinghaniyaz]

A heartfelt note, I've always loved Vue and the breaking changes in Vue 3 were quite disappointing. I successfully migrated multiple Vue projects and I can say it was fairly easy if not completely.

Most of the things in the majority of the projects used were backwards compatible. The harder shock for the consumers was the package ecosystem but I think that was one off and would not happen. It has set Vue back by 3 years, which is a big loss to Vue when competing with React though I hope it was a pit stop.

The painful bit was maintaing those projects on Nuxt. That migration is painful to say the least. I also assume a good portion of vue projects would be based on Nuxt and that could be another source of discomfort.

I also agree to the point that eventually web will have so much things that adaption framework to use those will be the only sensible way and that could have breaking changes.

The web components are such a noble thought but currently not priortised by the community. It can cancel the whole framework fair! All frameworks would do is provide a wrapper around it.

With AI being more prominent a larger overlapping abstraction only makes sense.