Vue 3 just got me from interested to excited
Michael Z

Michael Z @michi

About: Software writer

Location:
Tokyo
Joined:
Oct 7, 2018

Vue 3 just got me from interested to excited

Publish Date: Jul 5 '20
79 28

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

Comments 28 total

  • Peyton McGinnis
    Peyton McGinnisJul 5, 2020

    Reminds me of Svelte. I love it.

  • Michael Z
    Michael ZJul 5, 2020

    Could you elaborate that?

  • Jean-Sébastien Beaulieu
    Jean-Sébastien BeaulieuJul 6, 2020

    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.

    • Roger John
      Roger JohnJul 7, 2020

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

      • Jean-Sébastien Beaulieu
        Jean-Sébastien BeaulieuJul 7, 2020

        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.

  • James Edmonds
    James EdmondsJul 6, 2020

    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.

    • 🅖🅡🅔🅖🅞🅡🅨 🅞🅡🅣🅞🅝
      🅖🅡🅔🅖🅞🅡🅨 🅞🅡🅣🅞🅝Jul 6, 2020

      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

  • George Katsanos
    George KatsanosJul 6, 2020

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

    • Dennis Keirsgieter
      Dennis KeirsgieterJul 6, 2020

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

      • Vinícius Hoyer
        Vinícius HoyerJul 6, 2020

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

      • Roger John
        Roger JohnJul 7, 2020

        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.

        • Jean-Sébastien Beaulieu
          Jean-Sébastien BeaulieuJul 7, 2020

          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.

    • Michael Z
      Michael ZJul 6, 2020

      But they are inspired by React and Svelte :/

  • Luca Guadagnini
    Luca GuadagniniJul 6, 2020

    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

    • Michael Z
      Michael ZJul 6, 2020

      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
      • Luca Guadagnini
        Luca GuadagniniJul 6, 2020

        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.

      • Roger John
        Roger JohnJul 7, 2020

        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.

    • Tyler V.
      Tyler V.Jul 6, 2020

      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.
      • Luca Guadagnini
        Luca GuadagniniJul 6, 2020

        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.

        • Tyler V.
          Tyler V.Jul 6, 2020

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

          • Michael Z
            Michael ZJul 6, 2020

            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.

            • Luca Guadagnini
              Luca GuadagniniJul 6, 2020

              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?

              • Tyler V.
                Tyler V.Jul 6, 2020

                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.

                • Luca Guadagnini
                  Luca GuadagniniJul 6, 2020

                  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

  • 🅖🅡🅔🅖🅞🅡🅨 🅞🅡🅣🅞🅝
    🅖🅡🅔🅖🅞🅡🅨 🅞🅡🅣🅞🅝Jul 6, 2020

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

    • Michael Z
      Michael ZJul 6, 2020

      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.

  • Graham Morby
    Graham MorbyJul 21, 2020

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

Add comment