6

When using Vue as a detached SPA, surely there aren't going to be any major 'vulnerabilities' discovered after its EOL in Dec 2023.

My use of Vue is as a detached front-end SPA, with an Express REST API backend, practically all the 'risk' is in the back-end, so I imagine if I have properly configured my front-end (use of env variables etc.), Vue 2.7 should still be production-ready well into 2030? Whether it should be used up to 2030 is a different question.

I have business-legitimate and personal reasons not to upgrade to Vue 3.x. Most people upgrade because the ecosystem followed Vue 3, I only rely on Vue-CLI and my Vue 2 codebase is too large to refactor without security motivations.

This is a difficult question because most software isn't capable of being used as a detached front-end, therefore there isn't a lot of evidence available from what I've gathered on the internet about security vulnerabilities for this kind of framework, post EOL.

Leon
  • 255
  • 3
  • 12
  • 2
    Why not use Vue3? – kissu Oct 10 '22 at 05:54
  • business reasons? way too much vue 2 code that would need a complete re-do for vue 3. personal reasons? hate the direction vue is going, despite the options API everyone seems to push composition. you might like composition API though, and that's cool – Leon Oct 10 '22 at 11:41
  • 1
    You still can write Options API in Vue3, no need to rewrite the whole thing in Composition API. Everyone is pushing for it because it's more flexible and readable when writing bigger projects, not mandatory tho. – kissu Oct 10 '22 at 17:31
  • 1
    @kissu I understand your point on Composition API not being mandatory. I feel as though it is a common sentiment that Composition API is better for bigger projects, but I'm still yet to see a compelling compilation of reasons (evidence) as to why this is the case. For the record, I recommend new devs invest their *learning* time into Vue 3 instead of Vue 2, my question is for the vast majority of actual Vue developers who have actually built stuff with Vue, and know / understand its actually a really big change going to Vue 3. Not quite a new framework, but its like going Python 2 -> Python 3. – Leon Oct 12 '22 at 06:10
  • And to expand on personal reasons, I think Vue 2 was very nearly perfect from a developer's perspective. After about 1,500 hours with the framework as an end-user web dev, I've learnt to identify the shortcomings of Vue, but those short comings aren't looking fixed in Vue 3. You can definitely still make the same mistakes in big proejcts and its a learning curve. TypeScript is about the only reason I can understand people liking Vue 3, but from my experience, its because of TypeScript (and how cumbersome it is) that people loved Vue 2, it is just so intuitive compared to Angular – Leon Oct 12 '22 at 06:16
  • Everything is pretty much explained here: https://vuejs.org/guide/extras/composition-api-faq.html#why-composition-api Even if it doesn't apply to your, it's understandable why people are moving towards this direction. Direction that a lot of other frameworks have taken btw. So yeah, you may not find TS useful (I do not like it either) but for some people (dev + maintainers) it's quite the best thing ever created for obvious reasons. Vue3 is just following what other people like in the JS ecosystem overall (types + reusability). – kissu Oct 15 '22 at 11:40
  • Hi, so I guess that you got your answer or do you still want to wait for another one? – kissu Oct 19 '22 at 04:03

1 Answers1

4

I wouldn't bet such thing on a JS framework, you never know what may happen. Especially since if Vue uses a dependency of some sort (like lodash or whatever) and it's get's some vulnerability, you will not have an upgrade I guess.

So yeah, probably not a good idea to bet on JS for long term apps. But at the same time, as you said: there is nothing that critical into a client side JS framework.

It all depends on what you gonna use it with/packages around Vue too.

Using some backend to render the views will be safer (then adding some vanilla JS on top of it to replicate SPA's behavior). Otherwise, everything that is far from JS and more on the server side will be safer for sure.

TLDR: JS requires maintenance.

kissu
  • 40,416
  • 14
  • 65
  • 133
  • 1
    IIRC there were considerable security issues in Angular 1 but they were fixed long before the eol. Nothing that would ring a bell in Vue 2 so far. – Estus Flask Oct 10 '22 at 06:18
  • Thank you both for your insight. I do see a dependency vulnerability being a possibility (albeit an insignificant one by likelihood), however npm audits and manual updates of these dependencies could resolve it. Of course, a dependency update could break vue if it were a major update (say a version jump for axios). I also see that as insignificant by likelihood, though admittedly possible. I'm hoping I can push my luck with Vue 2 until at least 2025, 2 years after its EOL. By then who knows maybe a better framework will both a) release and b) gain popularity like vue 2 did! – Leon Oct 10 '22 at 13:25
  • @Leon I mean, if it's critical Vue2 may totally have it patched up. But at the same time, I'm not sure what would block you from using Vue3 since pretty much all packages have already done a migration. Otherwise, they will by the EOF. Also, if the package have not done the migration and it's not monkey patchable by yourself, it's probably not a good idea to use that anyway. There are quite some new frameworks daily, if you still want to write Vue3 Options API, it's feasible and getting anywhere so far. Otherwise, give Svelte a try maybe (cool syntax + simple approach). – kissu Oct 10 '22 at 17:36
  • 1
    @Leon Axios is third-party lib that Vue doesn't depend on, can be updated independently. Vue 2 doesn't have runtime deps, and vulnerabilities in dev deps don't matter https://stackoverflow.com/questions/51377148/how-to-fix-npm-vulnerabilities-manually – Estus Flask Oct 12 '22 at 20:05
  • @EstusFlask good point, libraries to do with networking are the most vulnerable, and at its core I'm unsure how many networking libs Vue depends on if any, possible that any internal core networking code could have security vulnerabilities in the distant future? – Leon Oct 13 '22 at 21:40
  • 1
    @Leon You can see the deps in Vue's package.json. A built Vue app has no deps except ones that you've brought (Axios, etc) .These are dev deps that constantly have vulnerability problems, but you don't deal with them, unless you develop Vue. You may get security alerts for the deps of your setup (Vue CLI, etc) but there's virtually no attack vector for a way they are used in Vue devserver and build process. – Estus Flask Oct 14 '22 at 10:31
  • I appreciate you sharing that information with me, it has convinced me that ecosystem aside, there is no reason for me to ever pick up Vue 3. Feel free to collate your info in a new answer and I'll award the bounty – Leon A Oct 15 '22 at 11:29
  • I really can't understand the hate regarding Vue3 even after your [last comment](https://stackoverflow.com/questions/74010317/can-vue-2-or-any-other-front-end-framework-be-sustainability-securely-used-a/74010696?noredirect=1#comment130725044_74010317) on the subject since you can still totally use Options API and follow the various updates of the framework. But it's your decision to stay stuck at a given version. I'm not a huge fan of CAPI either, but I still enjoy the new things around Vue3. As of why CAPI is better, there are a lot of resources explaining the exact reasons (scalability). – kissu Oct 15 '22 at 11:37
  • I think the hate comes mostly from seasoned devs who have actually built stuff in Vue 2 that needs maintaining etc. Most of the 'hype' of Vue 3 is by learners / new programmers – Leon A Oct 15 '22 at 11:39
  • @LeonA go to a conference and you'll see that everybody uses CAPI + TS. I was there (VueJS Berlin 2022) and most of the people there are quite seasoned devs who are indeed maintaining/migrating their codebase but eh, it's also our job to do such things. Letting something stuck at a given version is letting the codebase die and is too easy as an excuse. Especially since all the other JS packages will move along, with or without you making the move. I don't hate Vue3 even if it requires me to learn quite some new stuff, actually it's pretty exciting tbh but daunting, for sure. – kissu Oct 15 '22 at 11:43
  • 1
    @kissu I really do appreciate how you are trying to remain neutral in your reasoning. From a purely developer's perspective I tend to agree with you that when software moves, you should move with it, as it's not going to wait for you. From a practical perspective however, if something isn't broken, don't fix it. Vue 3 brings a ton of breaking changes to Vue 2, they try to sugar coat it but migration is not easy, at all. The only real improvements left for Vue 2 are improved debugging experience. I want to be able to know exactly when / what changes my variables' state. Next comment expanding – Leon A Oct 15 '22 at 12:19
  • Ideally I want to be able to visualise the lifecycle of the application with step'd created / mounted stop points. None of these concerns are even remotely addressed in Vue 3, they just wanted to change the internal structure of Vue for a mere performance boost, as if its Vue that is the bottleneck for slow websites. if they wanted to change the inside of Vue, they should have called it something else. Look at what the Angular major version changes did to the Angular community / developer satisfaction – Leon A Oct 15 '22 at 12:21
  • Expanding on practical perspective, we all have busy lives to live. If Vue 3 solves problems that *most* developers in Vue 2 had, I'd accept it with open arms and bite my tongue on the push toward Composition API. The reality is, Vue 3 isn't any bit easier than Vue 2, even for the new dev, they will struggle far more with Vue 3. The documentation may have been cleaned up, but now there are 2 versions of everything. The debugging experience was the main and pretty much only thing Vue needed for improvement. I don't see how Vue 3 offers that. – Leon A Oct 15 '22 at 12:25
  • @LeonA in Frontend things are moving really quickly so the "don't fix it" sentence is not viable in that space unfortunately. It can be true for a monolith backend that will not have a lot of moving parts/updates. Especially if it's based on Java or PHP hence why people are sometimes feeling JS fatigue. The migration is not that difficult IMO and we had quite a few time to grasp the changes and make a gradual migration over the past 12/24 months. I'm not saying that it's cool neither simple for sure, requires quite some work but it's feasible IMO. Debugging wise, I feel like it's still totally – kissu Oct 18 '22 at 15:55
  • feasible. It's actually even more flexible and decoupled, because you can get a more fine-grained control of each part thanks to CAPI. Vue's lifecycle is not part of the framework, more of the devtools. I never thought about some plugins for debugging that specifically (I don't need it personally) but that could be a nice improvement that could be submitted as an improvement for sure! And it could be quite agnostic (usable by both Vue2 and 3). Vue3 solves a lot of shortcoming of Vue2: reusability, typing, simplicity in 3rd party integrations, performance of the compiler etc... but is also – kissu Oct 18 '22 at 15:55
  • a big deal for maintainers who had a heavily rewritten codebase. As a user of the framework, it may be quite useless but it brings a lot of flexibility to maintainers who can iterate faster, in a cleaner and self-documented way. This burden-release is not to take lightly because it's quite a big deal. As for the comparison between Vue2 and 3, the CAPI is for advanced users for sure. But for beginners, you can still use Vue3 with Options API and...it's an easier version than Vue2 because you have less drawbacks. Nothing forces you to use CAPI if you don't like it, Options will not be removed. – kissu Oct 18 '22 at 15:55
  • 1
    You make a great point I didn't think about, that this change in internal structure may make it easier for package devs to more rapidly create / maintain packages. I've awarded your answer as a bounty because of your effort to explain your view, though I don't agree with the overall sentiment that Vue 3 is better, I do see your argument. As a final comment, Vue jobs are already far and inbetween, unlike React, the CAPI is only going to make it harder. Soon CAPI devs will demand more $ salary than OAPI devs. The implications are > than just developer experience. Vue is dead, Long Live Vue – Leon Oct 19 '22 at 03:50
  • @Leon CAPI is of course for advanced Vue devs no doubt about that (or people coming from React hooks). It's logical that somebody more experienced will get more money, in the same way that if you know how to use TypeScript, GraphQL or any kind of "hot tech" for companies currently. Any new skill adds to your value on the market, CAPI is one of them of course. I do totally understand your point too, it's quite a big change overall. Thanks for the bounty btw! – kissu Oct 19 '22 at 04:02