6 ms·

Vue: We no longer have any plan of deprecating the Object API

161 points by dtien 7y ago

datpuz 7y ago
Glad they listened!
skunkworker 7y ago
I'm glad they listened, and after reading more into some of the use cases there are times in which having this function api could be very helpful to group certain parts of the code together. https://dev.to/stefandorresteijn/vuejs-is-dead-long-live-vuejs-1g7f https://dev.to/stefandorresteijn/vuejs-is-dead-long-live-vue...
- hanniabu 7y ago
  It was never definitive, just a proposition they had put forth looking for feedback on
devoply 7y ago
Glad this is a publicly funded small team project that responds to its users rather than trying to push developer agenda on everyone.
- noir_lord 7y ago
  I'm just glad they listened. In many ways Vue is a spiritual descendant of KnockoutJS (except cleaner because the web platform had moved on) and those folks where amazing for compatibility relative to everyone else. Changing everything ever version is definitely not what I want from Vue, there are plenty of frameworks already doing that and it's just tiresome after a while. All in all it's a decision I'm pleased they made.
nlh 7y ago
I have to admit - I had the same reaction that many people had when the function api first appeared ("what is this insanity and why are you breaking everything i love"). But I read through, checked out the new (simpler) example, read Evan's arguments about logical task grouping, and on a second read with a more-open mind, I actually kind of like the new syntax and am now looking forward to trying it out. I'm glad they agreed to keep the object syntax around though :)
- dmix 7y ago
  My favourite part is the re-usability of the functions it encourages and the fact it breaks up the core Vue into individual functions (instead of one big module with options) which means Webpack can tree-shake not only your code but Vue's, resulting in far smaller libraries. Edit: After reading deeper it looks like the "lean" version of the library with full tree-shaking stuff is taking a backseat and they hope to provide some better library reduction in the future :/
  - no1youknowz 7y ago
    > After reading deeper it looks like the "lean" version of the library with full tree-shaking stuff is taking a backseat and they hope to provide some better library reduction in the future :/ That's a bit of a shame. I know it's a bit more work, but I wonder if they could have added in a switch where the compiler knows whether its object syntax vs function component syntax where the tree shaking is expected.
codingstuffs 7y ago
I was pretty worried, both by the deprecation of the Object API, and if the Vue team would listen to feedback on RFCs (and change parts if necessary). Very glad to see that both points turned out well. I was really not looking forward to trying to find/learning yet another JS framework.
bfrog 7y ago
I think the new API is great, I think the terms compatible/deprecated scared everyone
moogly 7y ago
As a TypeScript user who always disliked the object API and preferred vue-class-component, I feel a bit left out in the fallout of this. JavaScript users are always the loudest. IMO there is no clear, great option for people who are TS devotees. Again it feels like TS was an afterthought. Will have to experiment a bit. Maybe it's possible to do something decent with some helper functions.
- dean177 7y ago
  Don’t the existing and new apis have type definitions? Why do you feel left out?
  - moogly 7y ago
    I started writing a huge post with examples from the RFC and how I'd like things to look, but it became too involved and large, and no one wants to read that crap. I'll just summarise it with that props are problematic, both the old-school ones (which don't use TypeScript types at all, instead uses its own ad-hoc type system `{type: ..., required: ..., defaultValue: ...})` and the rather horrible `(null as any) as PropType<{ msg: string }>` type annotations for complex types and the "TypeScript-only Props Typing" which is better but does not have a way to set default values that I can see. Oh, also all props are optional per default which is not what you want in a `--strict` TypeScript project (which should be any new project). Generally it's relying strictly on type inference instead of interface declarations, which might make edit-time type safety work OK, but lack in error messages (spewing out complex inferred type definitions) and overall readability (much more easier to reason about an interface you wrote yourself). Also, everything inside the setup function are just variables and functions, so your editor will colour/highlight everything the same, whereas in the class proposal, you have clearer separation between properties (props/data), getters (computeds), methods and even static methods. It's just less messy. Now, I get that classes don't work with React hooks, and the other reasons for dropping classes are rather sound, but I really think that whole setup "God" function is a massive eyesore. TypeScript isn't only about correct type inference, it's also about improved ergonomics, readability, and, pardon the pun, less typing (on a keyboard). I guess I wrote too much again...
- 7y ago
TeMPOraL 7y ago
Reading the comments here and on previous Vue thread, I see a nice example of psychological reactance at play. First, it was "You're going to replace the API? No no don't do this, don't force us to use this new thing that sucks over the old better one!". Now, it is "Oh, so you're not going to replace the old API? Come to think of it, the new API is a really nice idea, has some pretty useful concepts in it!". :).
- viraptor 7y ago
  People are always more motivated to criticise. I love the idea of the new API for a few reasons, but wouldn't just comment "yay, that's cool" on the previous post. I'm happy it stays as a plugin though.
- geezerjay 7y ago
  Are you sure that both complains are being made by the same person? Vue is a popular project, and unless an idea is backed unequivocally by 100% of its user base then you'll always hear some users arguing in favour and others against.
superasn 7y ago
I think the best part about Vuejs right now is how simple it is and everything just works! A vue component is still as simple as {template: 'hi'}. You don't need webpack or any transliteration for it to work. Just drop the script tag like the good old jQuery and it's working! No wonder it has gained so much popularity as I don't think you can make it more KISS. Transition from vue1 to vue2 was really simple. I just hope that when the dust settles and things are finalized, Vue remains true to it's core of keeping things simple.
- williamdclt 7y ago
  I keep hearing this "a vue component is still as simple as {template: 'hi'}". Genuine question: I've been using Vue for the last couple of months, is anybody actually using this in the real world? Instead of vue-cli apps with single-file components (which is the other argument often seen)?
  - DanielBMarkham 7y ago
    I am. I wrote a bang-simple extensible blogging system several months ago using Vue. I started very, very simple. I ended up with multi-component files. No vue-cli. Three files. A few hundred lines of code. Works fine. Never had to touch it again.
    - Waterluvian 7y ago
      Might I ask if you could open source it? I badly need dead simple Real World examples.
      - DanielBMarkham 7y ago
        Sure. Hell I'll not only open-source it, I'll do a 10-minute video walkthru if I can get some coders to watch and ask questions.
        brylie 7y ago
avinium 7y ago
Kudos to Evan and the team for listening to the community. There was a big pushback against the RFC, which can sometimes be attributed to sticks in the mud. In this instance, though, I do feel that the changes weren’t necessary. All API changes come with a cost, and I’m unconvinced that the benefits outweighed it this time round.

161 points by dtien 7y ago

Glad they listened!

I'm glad they listened, and after reading more into some of the use cases there are times in which having this function api could be very helpful to group certain parts of the code together. https://dev.to/stefandorresteijn/vuejs-is-dead-long-live-vuejs-1g7f https://dev.to/stefandorresteijn/vuejs-is-dead-long-live-vue...

hanniabu 7y ago
It was never definitive, just a proposition they had put forth looking for feedback on

devoply 7y ago

Glad this is a publicly funded small team project that responds to its users rather than trying to push developer agenda on everyone.

noir_lord 7y ago
I'm just glad they listened. In many ways Vue is a spiritual descendant of KnockoutJS (except cleaner because the web platform had moved on) and those folks where amazing for compatibility relative to everyone else. Changing everything ever version is definitely not what I want from Vue, there are plenty of frameworks already doing that and it's just tiresome after a while. All in all it's a decision I'm pleased they made.

nlh 7y ago

I have to admit - I had the same reaction that many people had when the function api first appeared ("what is this insanity and why are you breaking everything i love"). But I read through, checked out the new (simpler) example, read Evan's arguments about logical task grouping, and on a second read with a more-open mind, I actually kind of like the new syntax and am now looking forward to trying it out. I'm glad they agreed to keep the object syntax around though :)

dmix 7y ago
My favourite part is the re-usability of the functions it encourages and the fact it breaks up the core Vue into individual functions (instead of one big module with options) which means Webpack can tree-shake not only your code but Vue's, resulting in far smaller libraries. Edit: After reading deeper it looks like the "lean" version of the library with full tree-shaking stuff is taking a backseat and they hope to provide some better library reduction in the future :/
- no1youknowz 7y ago
  > After reading deeper it looks like the "lean" version of the library with full tree-shaking stuff is taking a backseat and they hope to provide some better library reduction in the future :/ That's a bit of a shame. I know it's a bit more work, but I wonder if they could have added in a switch where the compiler knows whether its object syntax vs function component syntax where the tree shaking is expected.

codingstuffs 7y ago

I was pretty worried, both by the deprecation of the Object API, and if the Vue team would listen to feedback on RFCs (and change parts if necessary). Very glad to see that both points turned out well. I was really not looking forward to trying to find/learning yet another JS framework.

bfrog 7y ago

I think the new API is great, I think the terms compatible/deprecated scared everyone

moogly 7y ago

As a TypeScript user who always disliked the object API and preferred vue-class-component, I feel a bit left out in the fallout of this. JavaScript users are always the loudest. IMO there is no clear, great option for people who are TS devotees. Again it feels like TS was an afterthought. Will have to experiment a bit. Maybe it's possible to do something decent with some helper functions.

dean177 7y ago
Don’t the existing and new apis have type definitions? Why do you feel left out?
- moogly 7y ago
  I started writing a huge post with examples from the RFC and how I'd like things to look, but it became too involved and large, and no one wants to read that crap. I'll just summarise it with that props are problematic, both the old-school ones (which don't use TypeScript types at all, instead uses its own ad-hoc type system `{type: ..., required: ..., defaultValue: ...})` and the rather horrible `(null as any) as PropType<{ msg: string }>` type annotations for complex types and the "TypeScript-only Props Typing" which is better but does not have a way to set default values that I can see. Oh, also all props are optional per default which is not what you want in a `--strict` TypeScript project (which should be any new project). Generally it's relying strictly on type inference instead of interface declarations, which might make edit-time type safety work OK, but lack in error messages (spewing out complex inferred type definitions) and overall readability (much more easier to reason about an interface you wrote yourself). Also, everything inside the setup function are just variables and functions, so your editor will colour/highlight everything the same, whereas in the class proposal, you have clearer separation between properties (props/data), getters (computeds), methods and even static methods. It's just less messy. Now, I get that classes don't work with React hooks, and the other reasons for dropping classes are rather sound, but I really think that whole setup "God" function is a massive eyesore. TypeScript isn't only about correct type inference, it's also about improved ergonomics, readability, and, pardon the pun, less typing (on a keyboard). I guess I wrote too much again...
7y ago

TeMPOraL 7y ago

Reading the comments here and on previous Vue thread, I see a nice example of psychological reactance at play. First, it was "You're going to replace the API? No no don't do this, don't force us to use this new thing that sucks over the old better one!". Now, it is "Oh, so you're not going to replace the old API? Come to think of it, the new API is a really nice idea, has some pretty useful concepts in it!". :).

viraptor 7y ago
People are always more motivated to criticise. I love the idea of the new API for a few reasons, but wouldn't just comment "yay, that's cool" on the previous post. I'm happy it stays as a plugin though.
geezerjay 7y ago
Are you sure that both complains are being made by the same person? Vue is a popular project, and unless an idea is backed unequivocally by 100% of its user base then you'll always hear some users arguing in favour and others against.

superasn 7y ago

I think the best part about Vuejs right now is how simple it is and everything just works! A vue component is still as simple as {template: 'hi'}. You don't need webpack or any transliteration for it to work. Just drop the script tag like the good old jQuery and it's working! No wonder it has gained so much popularity as I don't think you can make it more KISS. Transition from vue1 to vue2 was really simple. I just hope that when the dust settles and things are finalized, Vue remains true to it's core of keeping things simple.

williamdclt 7y ago
I keep hearing this "a vue component is still as simple as {template: 'hi'}". Genuine question: I've been using Vue for the last couple of months, is anybody actually using this in the real world? Instead of vue-cli apps with single-file components (which is the other argument often seen)?
- DanielBMarkham 7y ago
  I am. I wrote a bang-simple extensible blogging system several months ago using Vue. I started very, very simple. I ended up with multi-component files. No vue-cli. Three files. A few hundred lines of code. Works fine. Never had to touch it again.
  - Waterluvian 7y ago
    Might I ask if you could open source it? I badly need dead simple Real World examples.
    - DanielBMarkham 7y ago
      Sure. Hell I'll not only open-source it, I'll do a 10-minute video walkthru if I can get some coders to watch and ask questions.
      - brylie 7y ago

avinium 7y ago

Kudos to Evan and the team for listening to the community. There was a big pushback against the RFC, which can sometimes be attributed to sticks in the mud. In this instance, though, I do feel that the changes weren’t necessary. All API changes come with a cost, and I’m unconvinced that the benefits outweighed it this time round.