DEV Community

loading...

Vue 3 just got me from interested to excited

Michael Z
Software writer
Originally published at michaelzanggl.com Updated on ・2 min read

Vue 3 has been on my radar for a while, but a recent RFC got me from "interested" to "excited".

I am specifically talking about declaring components.

This is how you typically do it in Vue 2:

<template>
  <div>{{ hello }}</div>
</template>

<script>
export default {
  data() {
    return {
      hello: 'world'
    }
  }
}
</script>
Enter fullscreen mode Exit fullscreen mode

Vue 3 (not released yet) introduces the composition API. This allows you to put the logic together rather than being spread across options.

My first reaction to this was: cool, this will be useful for complex components, but I will probably stick with the old one for cases that don't require it.

After all, this is how the above component would look like:

<template>
  <div>{{ hello }}</div>
</template>

<script>
import { ref } from 'vue'

export default {
  setup() {
    const hello = ref('world')

    return {
      hello
    }
  }
}
</script>
Enter fullscreen mode Exit fullscreen mode

Now much changed for this simple component, right? In fact, it got bigger.


Now the other day, a new RFC was posted on GitHub. Using "setup", you usually don't need methods, computed, data, and life cycle hooks anymore, so setting up "script" comes with seemingly unnecessary overhead.

So this new proposal allows us to only work using the setup method directly inside <script>.

<template>
  <div>{{ hello }}</div>
</template>

<script setup>
import { ref } from 'vue'

export const hello = ref('world')
</script>
Enter fullscreen mode Exit fullscreen mode

This might look a little alien, but think about it. In Vue 2, we exported an entire object using export default for the template to use. With <script setup> we export individual parts for the template to use.

With all the indentation necessary to add a little bit of state, setting up components in Vue was always a little tedious. This svelte-react-mix completely gets rid of this problem.

Now how do we register components you might ask? This also got a DX boost. Instead of importing AND registering it, the two steps were merged into one. There still seems to be some debate on all of this, but check out the RFC for more info.

RFC: https://github.com/vuejs/rfcs/pull/182

Discussion (28)

Collapse
jsbeaulieu profile image
Jean-Sébastien Beaulieu

What's the point of that comment, on a post about Vue.js, if it's not just being purposefully controversial?

If anything, this makes Vue.js even more similar to React's functional API, so if it's V2's API you don't like, this post should have the opposite effect.

Collapse
rogerjohn0 profile image
Roger John

From its existing user base and previous vision, it's not a selling point being similar to React.

Thread Thread
jsbeaulieu profile image
Jean-Sébastien Beaulieu • Edited

It's a second API and the "old" one isn't going away any time soon. Everyone's free to ignore it altogether and keep working like before. It IS a major selling point.

Collapse
lucaguada profile image
Luca Guadagnini

oh com'on!! why?? ☹️ why can't we have a framework that uses language keywords for what they meant for?? export for binding fields to a template? what's the semantic here? export is meant for exporting "things" from a module, is template a JS module?

Svelte is just terrible and horrible on this side, and Vue 2 was just perfect (maybe it needed to simplify some things), but in this way is getting closer to what Angular 2+ is for AngularJS: bloody mess. 😕 quite disappointed

Collapse
michi profile image
Michael Z Author

Two things I'd like to point out.

  1. The new API does not deprecate the V2 options API. On top of that, you will also be able to use setup without the syntax sugar from the RFC
  2. It's still just an RFC, open for feedback and comments
Collapse
lucaguada profile image
Luca Guadagnini

I know but it's not what I meant, such kind of dirty tricks do not improve in any way the development consistency and conventions. And I don't get why some JS framework development deliberately ignore this from the beginning.

I know I can be a little bit dramatic, but a RFC like this should be blasted without any discussion.

Collapse
rogerjohn0 profile image
Roger John

It’s not just an RFC per day, it rather a facade from past experience. And just like React functional components, the composition API will be the standard.

Collapse
terabytetiger profile image
Tyler V. (he/him)

Hey! Want to help clarify this a bit:

export for binding fields to a template? what's the semantic here? export is meant for exporting "things" from a module, is template a JS module?

  • export isn't binding fields to the template, it's creating a JS object which Vue builds into a "reactive" object when you run the build command to compile the code. This is why we include export default or module.exports when we write a single file component in Vue 2.X.
  • The <template> tag is semantic HTML for an HTML block that gets displayed to the user using Javascript.
Collapse
lucaguada profile image
Luca Guadagnini

So you're actually saying that I'm right, ’export’ is now a special keyword for the build task, not for the language itself. Nice.

I didn't say anything about template tag, at least that one is still complaint.

Thread Thread
terabytetiger profile image
Tyler V. (he/him) • Edited

’export’ is now a special keyword for the build task

On the contrary! I'm stating that export is still being used exactly the same as in Vue 2.

The unique piece for Vue's build tools in these examples is the setup in <script setup> of the third block.

which Vue builds into a "reactive" object

This may have been unclear wording for me to use - Vue is more optimizing the use of the exported object, not necessarily modifying the exported object.

More about export


I didn't say anything about template tag, at least that one is still complaint.

My clarification of the template tag was trying to clarify this part of your question:

is template a JS module?

Which the answer is "Not exactly".

Thread Thread
michi profile image
Michael Z Author • Edited

I like this example. In Vue 2 we exported an entire object using export default for the template to use. With <script setup> we export individual parts for the template to use. It's quite similar.

Thread Thread
lucaguada profile image
Luca Guadagnini

Yep I got the point, but what I'm actually trying to say is «export» has now another special meaning for build task, not for the language itself or for us («us» meant as «we developers that know JS only»). In order to understand what is behind the build process, we have to read docs to understand that «export» doesn't actually exports a constant, but it helps the build task to create a «special» component with your constant inside. Worst than that you have to specify a... I don't know how to call it a «hashtag»? an «annotation»? an «empty non-compliant attribute»? anyway you have to specify setup in your script tag, otherwise export loses its meaning to build task.

Can't you see the issue here?

Thread Thread
terabytetiger profile image
Tyler V. (he/him)

I think there's a disconnect here, so I want to summarize the key points of what I was trying to clarify:

  • export in Vue works the same as in Vanilla JS.
  • When Vue compiles an application, it is optimizing the code - not changing the meaning of JS keywords.

Using Vue is the same as any other framework/library in that you need to adhere to the expected format.
<script setup> is a proposed acceptable shorthand format, not unlike @click or <style scoped>.

If you have specific questions, I'd love to help clarify more. Concerns about the reliability or user-friendliness of the RFC should be expressed on the RFC.

Thread Thread
lucaguada profile image
Luca Guadagnini

So you're just telling me that export is used by Vue like always, Vue imports constants, functions, etc... from my script and with that it builds the component? script just says - if understood correctly - imports separately, not altogether like we used to do it in Vue2. Something like that?

Sorry I can't follow the entire RFC, too big :-D

Collapse
sergix profile image
Peyton McGinnis • Edited

Reminds me of Svelte. I love it.

Collapse
ortonomy profile image
🅖🅡🅔🅖🅞🅡🅨 🅞🅡🅣🅞🅝

The new composition API is actually more difficult to understand. Vue2 was very declarative with the options API. I’m not sure what advantages this brings? It’s not like you have to include all options...

Moreover, this seems like overkill to fix the mixin problem? Sounds like they just got hook envy....

Collapse
michi profile image
Michael Z Author

This post was more to show the new syntax, not the benefits of the composition API. Hence, my example is actually really bad from that stand point. Composition API shines once you have (with options API) related logic spread across different options (data, computed, methods, mounted, destroy, etc.). Composition API let's you group this logic together. It's not going to be an all-in replacement for Vue 2's options API. I can see people continue using it.

Collapse
gkatsanos profile image
George Katsanos

I've been doing Vue since 2 came out. These proposals for 3 are borderline ridiculous. I'll be switching to React or Svelte.

Collapse
michi profile image
Michael Z Author • Edited

But they are inspired by React and Svelte :/

Collapse
dennisk profile image
Dennis Keirsgieter

Or you could just continue using Vue 2.x syntaxing? No one is forcing you....

Collapse
vhoyer profile image
Vinícius Hoyer

right? and there are nice improvements from a performance perspective in Vue@3 compared to Vue@2

Collapse
rogerjohn0 profile image
Roger John

Yep most of plugins, build tools, syntaxes, etc will eventually be depreciated. Also documentation and examples will be more difficult to resource if 2.0 isn’t branched into an new project.

Thread Thread
jsbeaulieu profile image
Jean-Sébastien Beaulieu • Edited

That's dramatic. React class based components aren't gone either, a lot of things migrated to them, yet I've still to find a React dev who doesn't know about both functional and class-based.

Collapse
deckchairlabs profile image
James Edmonds

Yeah I have to agree, I like how with React it doesn't feel like there is "magic" happening behind the scenes, even though there is.

I'm not bashing Vue or Vue users here, it's fine, but after working with it on a massive codebase, I can't use it. These RFCs look like they'll improve some aspects, but I still view Vue as a tool more appropriate for smaller/prototype projects.

Collapse
ortonomy profile image
🅖🅡🅔🅖🅞🅡🅨 🅞🅡🅣🅞🅝

Seriously? I find that interesting. I love React, but I find it’s maintainability goes down very quickly as codebase grows. Vue’s single file components force devs to think very hard about reusability and working on huge code base was a dream

Collapse
michi profile image
Michael Z Author

Could you elaborate that?

Collapse
grahammorby profile image
Graham Morby

Sorry i simply prefer Vue 2 and how we handle the component over v3, we shall see