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 componen...
For further actions, you may consider blocking this person and/or reporting abuse
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.
From its existing user base and previous vision, it's not a selling point being similar to React.
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.
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
Two things I'd like to point out.
setupwithout the syntax sugar from the RFCI 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.
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.
Hey! Want to help clarify this a bit:
exportisn't binding fields to the template, it's creating a JS object which Vue builds into a "reactive" object when you run thebuildcommand to compile the code. This is why we includeexport defaultormodule.exportswhen we write a single file component in Vue 2.X.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.
On the contrary! I'm stating that
exportis still being used exactly the same as in Vue 2.The unique piece for Vue's build tools in these examples is the
setupin<script setup>of the third block.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
My clarification of the template tag was trying to clarify this part of your question:
Which the answer is "Not exactly".
I like this example. In Vue 2 we exported an entire object using
export defaultfor the template to use. With<script setup>we export individual parts for the template to use. It's quite similar.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
buildtask 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 specifysetupin your script tag, otherwiseexportloses its meaning tobuildtask.Can't you see the issue here?
I think there's a disconnect here, so I want to summarize the key points of what I was trying to clarify:
exportin Vue works the same as in Vanilla JS.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@clickor<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.
So you're just telling me that
exportis used by Vue like always, Vue imports constants, functions, etc... from myscriptand with that it builds the component?scriptjust 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
Reminds me of Svelte. I love it.
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....
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.
I've been doing Vue since 2 came out. These proposals for 3 are borderline ridiculous. I'll be switching to React or Svelte.
But they are inspired by React and Svelte :/
Or you could just continue using Vue 2.x syntaxing? No one is forcing you....
right? and there are nice improvements from a performance perspective in Vue@3 compared to Vue@2
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.
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.
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.
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
Could you elaborate that?
Sorry i simply prefer Vue 2 and how we handle the component over v3, we shall see