[tgsovlerkhgsel]

I started using VueJS when I got thrown off the deprecation treadmill by Angular.

Regardless of whether something is a hobby project that you want to only touch a couple times a year or a big project with dozens of developers, having your platform deprecated under your feet and being forced to do migration work sucks.

Vue is now on version 3 within 10 years. That means anyone who relied on v1 has had their work churned away under their feet, twice.

[MatekCopatek]

As someone who started using Vue before 1.0, I find that characterization unfair. The overall API didn't change much from 1 to 2.

3 was initially going to be a big change, but after a lot of community resistance, they decided to make the reworked API entirely optional so people wouldn't be forced to make changes. AFAIK this is still the case and the classic variant (Options API) is still fully supported.

[joshstrange]

They did drop class components though which I had heavily used for both professional and personal projects. I still haven’t gone through the process of upgrading one of those but I’ve written a new project in vue 3 with the composition API and I like it overall I just hate that I have to switch from class components

[tinco]

I fell for a feint though. Reading their docs it seemed like they were going to go in the direction of class components with attributes (class decorators). So we built our app for that, thinking we'd be future proof, but alas the community went 180 degrees the other way, and our Vue 2 app became super hard to upgrade to Vue 3.

[simultsop]

Without more context can't comment on your upgrade process. But as others stated above, there's not much difference betweeb 2 and 3, except you do not get composition api on a v2 project, while you can use composables but can't go full composition api and have to stick to options api. Other than that most of v2 code would work on v3.

[SparkyMcUnicorn]

This isn't correct. I'm using the composition API on all my Vue 2 projects. It's even baked into 2.7.

https://github.com/vuejs/composition-api

[tinco]

Yeah our path to upgrade is going component by component switching them to compositional style.

[PaulRobinson]

I was around for the first Angular deprecation treadmill, and it was jarring.

I was thinking about doing some stuff for a hobby project recently and as a mostly back-end engineer, I am very out of date for most front-end code. I did a scout around, and didn't feel too impressed.

Finally last week I was thinking "I wonder what happened to jQuery", and there it was. Just as it ever was. Updated, freshened up, but completely recognisable and completely usable.

Is it new and shiny and full of awesome features? No. Do I understand it? Yes. Are there plugins for most things I need? Sure.

I feel old, but I'd rather make progress with something unfashionable than have to deal with deprecation and learning curves with something fashionable.

[Hasu]

I'm genuinely curious - what features does jQuery have that make it better than modern vanilla JS? Back in the day the vanilla DOM APIs were bad, so jQuery was great, but I haven't felt the need to reach for it in ages.

[ipaddr]

Better and shorter syntax, plugins, ecosystem.

Hide Show

```

$(".box").hide();

$(".box").show();

vs

document.querySelector(".box").style.display = "none";

document.querySelector(".box").style.display = "block";

``` Both work. The first is more clear

[jacobr]

```

const $ = document.querySelector.bind(document);

$('.box').hidden = true;

$('.box').hidden = false;

```

[troupo]

1. Not really.

jQuery is designed not to fail. So if there's no `.box` on the page, jQuery will not do anything.

`querySelector` may return null, so `$('.box').hidden` will hard break your page if you're not careful enough

2. `$('.box').hide()` is just one such example.

The hilarious https://youmightnotneedjquery.com/ shows that jQuery remains more consistent, concise, and composable than most things in modern browser APIs

[just_testing]

jumping in on this bandwagon... I sometimes look https://youmightnotneedjquery.com when I forget how to do something with jQuery.

Also, do you know if there is a jQuery-like that actually throws exceptions? Having `$('.box').hide()` tell me there is no `.box` would be pretty useful.

[1123581321]

I would look around more. You might like one of the small reactive frameworks if you find the large ecosystem of React and Vue off-putting. My last jQuery app was several years ago, when I realized I was just maintaining a slower reimplementation of a reactive framework. These are mature technologies now that quickly save time and prevent headaches down the road. jQuery's best lessons have been absorbed into both the reactive frameworks and native JS and you can alias the handful of selectors you're used to.

For development, browsers and version managers/containers are stable enough that you won't be on a deprecation treadmill. Any pressure would come from including other people on the project, which you'd get even more of with jQuery.

I appreciate the 'do what works' mindset quite a bit but I hope you'll give a modern reactive framework or library a try; I'm glad I made the change.

[PaulRobinson]

What would you recommend?

[1123581321]

Vue with Vite (the builder/runner) is a stable, open source option. It is really a lightweight start where you're mostly writing HTML with interpolated data, and Vue is updating values correctly and performantly. Just build your reactive HTML app in one file and break into separate components as you're feeling the spirit. https://vuejs.org/guide/quick-start

Mithril if you just want to drop in want a tiny, complete reactive library that doesn't require a build step--this one is most like what you might end up creating in a large jQuery app. You can understand everything from the homepage. https://mithril.js.org/

HTMX if you really like HTML conventions. This doesn't feel jQuery-like and depends on your approach to your server app. https://htmx.org/

If you were to pick just one, I think Vue would be the most rewarding.

[ipaddr]

jQuery still works great

[demondemidi]

It certainly does but only for very flat designs. I was in jQuery camp for a solid 15 years (2000~2015) but once you get a taste of reactive design, it physically hurts to go back to jQuery. For me, that is.

[cjblomqvist]

We have a 100kloc codebase and migrated 2->3 + replaced our whole build stack (webpack -> vite) with a few dev days of effort (mostly on SSR stuff). It hasn't (at least not negatively) our general velocity at all.

A totally different thing than moving from Angular 1 -> 2 for example.

[aniforprez]

Was an Angular 1 -> 2 even possible? If I remember correctly, they were one of the first big open source projects to go all in on Typescript and even the fundamental way that the rerender and state changes were tracked were completely different. I worked on an app on AngularJS and when asked for an assessment on a migration, it felt clear to me that it would require a complete rewrite. Even the tooling was totally different

[tylerchurch]

It was a complete rewrite. Angular 1 vs. 2 share nothing besides name and some basic concepts. The actual code and tooling was completely separate.

[ipaddr]

That opening is what react used to become what it is today. With the 1 -> 2 no upgrade path it forced a rewrite and many left to react and never came back.

[mushufasa]

We're about to need to do the same thing with similarly sized codebase. Would love to hear your story. Did you find any migration tooling to help? Would be happy to DM to chat as well.

One of our issues is that we've used some component frameworks that also need to be migrated.

[whstl]

I did it to a similarly sized codebase too. Vue itself was painless.

I also migrated our component framework, from Buefy to Oruga. Some string replacement to change component prefixes, then Typescript to help catch incorrect properties. I might have fixed several bugs in the process thanks to Typescript working better with Oruga. The only real tricky part was converting customized CSS, which was A LOT in our case, but Oruga provides a better way of overriding CSS, so it was worth the time.

Took about 2 days of me doing pure coding with a blocked calendar, plus a third day for testing and code reviews by the rest of the team.

[CharlesW]

> Did you find any migration tooling to help?

With the caveat that I don't do software engineering professionally, I recently migrated a personal Vue 1/JavaScript project to Vue 3/TypeScript, and it was mostly painless. There's a migration guide¹, and Phind and Copilot were helpful.

¹ https://v3-migration.vuejs.org/migration-build.html

[cjblomqvist]

Basically, see other comments. We simply followed the migration guide. Very painless. We use few external libs, så that helped a lot. You can find me on LinkedIn with the same username as here for DM.

[yagodragon]

Going through the same migration from nuxt 2 to nuxt 3. Can you share more details? Did you also move from vuex to pinia ? If so, how did you manage the API change (dispatch, commit) scattered through the codebase. I'd love to learn more

[cjblomqvist]

We had a homegrown store lib that was very similar to pinia, so migration was basically minor renaming.

Like others have mentioned, the biggest fear was other libs we used. We are quite conservative with that though, so want a big deal.

[joshstrange]

I’d love to hear if anyone has done this migrating from vue 2 with class components. There doesn’t seem to be as nice of an upgrade path from what I can tell.

[ceejayoz]

We transitioned from Vue v0.14 to v2 to v3 without all that much code churn. Most of the work was a couple third-party components that got abandoned in the 2 —> 3 switch.

A couple major version upgrades in a decade seems reasonable.

[DanHulton]

"Version 3 within 10 years" is, in this industry, glacial pace.

And also, the work required to do those upgrades has always been relatively minimal, with a backwards path for stuff you're not ready to convert yet, but real tangible benefits for the stuff you are. I still have a few projects that are a mix of Vue 2/3 - new stuff written in 3 because it's nicer, older components not rewritten yet because they haven't needed to be touched and just still work.

[demondemidi]

I'm still on Vue2 for my personal projects because the migration path is painful. Someday I'll get to 3!!!

[whimsicalism]

this seems reasonable to me