7 ms·

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 touc

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.

ceejayoz 3y ago
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.
PaulRobinson 3y ago
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 3y ago
  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 3y ago
    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 3y ago
``` const $ = document.querySelector.bind(document); $('.box').hidden = true; $('.box').hidden = false; ```
- troupo 3y ago
  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/ https://youmightnotneedjquery.com/ shows that jQuery remains more consistent, concise, and composable than most things in modern browser APIs
  just_testing 3y ago
  jumping in on this bandwagon... I sometimes look https://youmightnotneedjquery.com 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.
- ipaddr 3y ago
  jQuery still works great
  - demondemidi 3y ago
    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.
- 1123581321 3y ago
  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 3y ago
    What would you recommend?
    - 1123581321 3y ago
      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 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/ 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/ https://htmx.org/ If you were to pick just one, I think Vue would be the most rewarding.
MatekCopatek 3y ago
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.
- tinco 3y ago
  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 3y ago
    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 3y ago
      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 https://github.com/vuejs/composition-api
      - tinco 3y ago
        Yeah our path to upgrade is going component by component switching them to compositional style.
- joshstrange 3y ago
  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
cjblomqvist 3y ago
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 3y ago
  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 3y ago
    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 3y ago
    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 3y ago
  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.
  - CharlesW 3y ago
    > 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 https://v3-migration.vuejs.org/migration-build.html
whimsicalism 3y ago
this seems reasonable to me
demondemidi 3y ago
I'm still on Vue2 for my personal projects because the migration path is painful. Someday I'll get to 3!!!
DanHulton 3y ago
"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.

ceejayoz 3y ago

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.

PaulRobinson 3y ago

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 3y ago
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 3y ago
  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 3y ago
``` const $ = document.querySelector.bind(document); $('.box').hidden = true; $('.box').hidden = false; ```
- troupo 3y ago
  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/ https://youmightnotneedjquery.com/ shows that jQuery remains more consistent, concise, and composable than most things in modern browser APIs
  - just_testing 3y ago
    jumping in on this bandwagon... I sometimes look https://youmightnotneedjquery.com 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.
ipaddr 3y ago
jQuery still works great
- demondemidi 3y ago
  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.
1123581321 3y ago
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 3y ago
  What would you recommend?
  - 1123581321 3y ago
    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 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/ 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/ https://htmx.org/ If you were to pick just one, I think Vue would be the most rewarding.

MatekCopatek 3y ago

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.

tinco 3y ago
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 3y ago
  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 3y ago
    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 https://github.com/vuejs/composition-api
    - tinco 3y ago
      Yeah our path to upgrade is going component by component switching them to compositional style.
joshstrange 3y ago
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

cjblomqvist 3y ago

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 3y ago
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 3y ago
  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 3y ago
  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 3y ago
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.
- CharlesW 3y ago
  > 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 https://v3-migration.vuejs.org/migration-build.html

whimsicalism 3y ago

this seems reasonable to me

demondemidi 3y ago

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

DanHulton 3y ago

"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.