
New Features in Vue 3 - rahaug
https://vueschool.io/articles/vuejs-tutorials/exciting-new-features-in-vue-3/
======
alipang
The React core team has done a wonderful job incorporating actual CS concepts
like algebraic effects into their framework. I understand that it's only an
approximation of the real thing, but they're clearly managing to at least get
the core idea out there into real production systems.

The Vue implementation seems to ultimately lack this core understanding, and
comes off almost a bit cargo-cultish in comparison. React has hooks, so we
must have something similar.

I don't mean this as singularly bad, I'm certain Vue can be productive and
that this can be a productive feature for Vue devs - but when will we as an
industry manage to evaluate software by semantics rather than the syntax we
prefer? Does Vue truly offer anything over React that's not in the realm of
preferred syntax?

~~~
acemarke
I'm a complete React fanboy and fully engaged in the React ecosystem, but I'd
like to speak up in Vue's defense here.

Yes, there's some obvious copying going on here, but this is not a bad thing!
There's been a lot of cross-pollination and inspiration between the major
frameworks and ecosystems.

While I haven't deeply inspected the exact details of the new Vue APIs, my
understanding based on discussions is that the Vue team has heavily adapted
the hooks APIs for a more Vue-idiomatic approach. This includes things like
removing the need for the call order limitation, only calling them once on
setup, making use of Vue's reactivity, and so on.

Those changes fit well into Vue's stated focus on ease of use and handling a
lot of behavior automatically.

This gives the Vue community a chance to benefit from some of the same
concepts and improvements that the React team has described for hooks, while
staying with their same toolset.

I'm entirely happy with React and have no plans to switch, but there's plenty
of reasons for folks to choose Vue (and similarly, each of the other
frameworks). I gave a list of some reasons why you might pick each of them a
while back on Reddit [0].

[0]
[https://www.reddit.com/r/javascript/comments/avsuei/react_vs...](https://www.reddit.com/r/javascript/comments/avsuei/react_vs_vue_a_sidebyside_code_comparison/ehi6g1m/?context=3)

~~~
palerdot
Copying is a harsh word IMO. Vue has been liberal and open in quoting prior
art, particularly from the React ecosystem. For example vuex[0] docs, actually
quotes Dan Abramov regarding flux implementations for state management.

[0] - [https://vuex.vuejs.org/](https://vuex.vuejs.org/)

~~~
bpicolo
Programming and open source is a massive ecosystem of making use of prior art
and incorporating diverse ideas to make alternative, better, or more robust
abstractions. That's the whole beauty of it. Very few things are entirely new.

------
cies
I was hoping for less (or non-at-all) "stringly typing".

Then I saw this: <button @click="increment">

And this

    
    
        function increment() {
          count.value++
        }
    

I have a hard time to deal with that the string "increment" is used to refer
to the function increment() in 2019.

There must be a way to use the actual symbol for this instead of a string?

~~~
frenchman99
The devtools (Jetbrains Webstorm for instance) automatically detect that
`increment` refers to the method. So it actually works quite well in practice.
And you can use @click="increment(any, args, here)" if you want. The syntax
@click="increment" is just syntactic sugar for @click="increment($event)", I
think.

~~~
mpolichette
It's cool if tooling helps with this. Thats important.

I'm mixed on vue because of the string bindings. I _really_ like to know where
my variables are coming from and really hate when two dependent uses but not
actually the same thing...

That said, I'm happy to re-evaluate my stance... so what does it mean to be
"the same thing"? I suppose in the past, I would say that the compiler thinks
the things are the same, and it would be easy to change either:

1\. If it is a value, I can set/change it in a single spot

2\. If it's a token, it is easy to detect and change everywhere, and tooling
will help my avoid misses.

That said, in React, if you were to mess up a 'token', the runtime would be
very upset and it would be hard to have something like `onClick={incremant}`
(note the a). Tools would make it super easy to spot.

What does vue do if you miss-type your bindings?

~~~
ktpsns
> That said, in React, if you were to mess up a 'token', the runtime would be
> very upset

The same is of course true for Vue. At runtime, it will spit an error if it
doesn't know that token (variable, function, whatever it is).

My feeling is what you don't like are really the quotation marks because it
looks weird. I had a similar feeling when I started with vue. However, it is
really a matter of taste if you prefer the Vue @click="foo" or onClick={foo}
syntax.

~~~
mpolichette
So, when the jsx is compiled for react onClick={foo} is really just part of an
object: `{ onClick: foo }` which is actually using the token.

Believe me, I agree to an extend its a matter of taste, but I too like that my
underlying understanding of whats happening under the hood can be followed by
a raw debugger without following string based mappings.

In react I can set a debugger endpoint right before the return of render and
see what all my local variables are... is anything like this possible in vue?

------
dmix
Getting rid of a giant ‘this’ and taking a more functional approach was 100%
the right direction for Vue to go.

~~~
Roboprog
I am also glad to see the new way to define event handlers. The v 2 way of
defining a “methods” prototype forces me to constantly reference “this” (which
will only exist later after the component has “really” been created), which I
would prefer to avoid.

At least in AngularJS I can capture “this” as a closure variable at the start
of the component setup “decorator” function, then alias other functions
delegated as the component “methods” (event handlers) without worrying about
object instance references for “apply” and such.

Now, I can so something similar in Vue components: get the data up front in
the event handlers definitions, and delegate to any functions I want using
closures or partially applied arguments.

Hard to understate the importance of the new event handler setup API.

------
sansnomme
Or you can skip the attempts to provide pseudo-reactivity on top of JS and
clumsy shoehorning of GUI apps into finite state machines. Just use Svelte
instead.

[https://svelte.dev](https://svelte.dev)

Transpilation and static analysis are the ways to go.

~~~
leeman2016
I actually tried out Vue after I had a production app made using svelte 3 and
was amazed how verbose Vue is in comparison. Not to mention Svelte's smaller
bundle sizes due to absent run-time library.

~~~
uhryks
The fact render functions are made on build time does not mean Svelte has no
runtime. Svelte has nice things going for it but you guys are just writing
bullshit in order to criticize Vue.

~~~
sansnomme
Not close to fully runtime-less sure, but about as close as you can get. It's
the same way C isn't runtime-less compared to assembly because it has crt.0
but compared to Java it effectively is.

~~~
ng12
> Not close to fully runtime-less sure, but about as close as you can get.

Have you looked at transpiled Svelte code? It's 5-10x bigger than the source
code because an entire runtime library is injected and your code is rewritten
to use that library at compile time.

------
RobertRoberts
After building some larger Vue apps, I am starting to see the issues with the
older system.

But I worry this will turn into React at some point. Can anyone assuage my
concerns on this?

~~~
cuddlecake
I feel like angular, react and Vue converge on. Similar set of principles.

Essentially, they learn from each other, but they will never be quite the same

~~~
mpolichette
I agree, I'm a react dev and I think Vue, and others, are great.

All of them are approaching the same problem from different directions and
paths. If each discovers something new and useful, the others can decide if it
would be a good fit for them.

It's all wins all around, so I don't understand the disparagement.

~~~
RobertRoberts
Because there are some things that are pure genius to me that Vue does that
React and others do not do, and I don't want to lose that.

But, my long term view is that Svelte (or Svelte like) library will win out in
the long term. Getting code back to basics is a great theme/trend. It's what
made me like Vue to start with.

~~~
wjmao88
Can you give some examples of those "pure genius"s?

~~~
RobertRoberts
NOTE: Those that will roast me for not spending yet enough time trying to get
other libraries to work outside of Vue, feel free to offer me your production
budget to spend on that.

Cost to start. The first time I tried Vue (after trying a bunch of other
libraries) I had something working in minutes. React required I learn many
other things before even getting a "hello world" to function. Straight html/js
connection. JSX is a nightmare.

Integration with existing systems. I work with hundreds of thousands of lines
of code in a very messy old system. I was able to gut pieces of jQuery and
nearly drop in replace with Vue.

Template focused development. I don't care how super duper awesome the
"render" function is. I don't care how fast or performant. I am need to build
a tool that I use for a couple of years and then throw away. (long story
short, having a build pipeline is a detriment in many apps that I work on
because their lifespan is so short)

I may be an amateur, but that is where Vue is genius. I don't have time to
learn 20 new entire systems, 10 new build platforms, Node.js (and all that
entails) just to get a reactive app to replace some super old jQuery junk.

I am now more capable than before, but after managing so much code for so many
years, I want things _less_ complicated, not more. Nearly 100% of the code I
wrote 20 years ago is gone now, replaced, rebuilt and redesigned. All the Vue
I will build today will be gone in a few years, that is almost a certainty. So
I have no budget for messing around.

The list can go on, but I am sure I will get harrassed with this about how
React can run live and doesn't need compilation, ha. I tried it, what a mess
it was. Learning the quirks of JS is bad enough, learning the quirks of doing
'JS exactly like React/Vue' wants you to? Ugh, that just sucks so bad I want
to pull my hair out. The less a library I have to deal with the better. The
more pure and simple code is the better. /rant.

------
preommr
I've been following the development of vue 3 for a while now and the reaction
in the js community for this new version from both vue fans and detractors has
been absolutely awful.

Some of the blame rests on the vue team because they did a poor job of
explaining the changes. But I think an even bigger issue is that the js
community is all over the place in terms of skill level, application of vue
and understanding the changes.

The new composition api is basically a way to write reusable code. Mixins also
exist, but you can't call code in between other mixins. It also allowed for
better typescript support since it's basically regular code and was easier to
implement than the class based syntax that they originally planned. It
basically killed two birds with one stone.

These changes aren't really big or earth-shattering. They are still an
improvement though, and fits well with a project that's making incremental
improvements while also being very stable.

------
meerita
Questions for devs who used vue in the past on production apps, what about
Svelte? I find it easier, cleaner and practical.

~~~
alexcroox
React for 2/3 years, Vue for 1 year building large SASS apps. I use Svelte for
my personal site and really enjoyed it, but dismissed it as a contender for my
companies latest application. It's community is still too young, there's not
enough established, battle-tested libraries for common tasks like routing. It
reminds me of React in the early days, I felt overwhelmed with choice and a
constant feeling the 3rd party library you are about to go all in with will be
shortly replaced with a better, community backed alternative.

I'd love to re-visit that in a couple of years time when it's popularity and
community has risen and is more established. Just as React did.

~~~
dmix
Mature communities are absolutely essential for any serious production
development. It's doesn't matter if Svelte is technically superior in ways
until it's been battle tested and has wide support.

Otherwise you'll be spending far too much time on things that other people
have long ago solved in other frameworks.

------
mmanfrin
This is a weirdly negative comment section.

~~~
KaoruAoiShiho
I think once you're invested into an ecosystem you become naturally
disincentivized to see another one supercede it.

~~~
ng12
Honestly I think these discussions are just pretty low quality. I find that
people are pretty good at mis-attributing their success and failures to their
tech stacks, especially in a field where there's a lot of novices like front-
end development.

------
plopz
I'm not really interested in any of those features, but does it work with
arrays and objects without having to use Vue.set? Because that was the biggest
issue I had the last time I tried it.

~~~
creatio
Yes

------
agumonkey
I liked vue guide, but now that I'm making an application, I'm dubious about
the component thing for application state trees. After seeing some
clojurescript talks it seemed quite a lot cleaner. I now wonder how different
is react..

------
conradfr
I was not that sold on the first draft but I'm now excited for Vue3's
improvements and the TS support.

------
maxfurman
This is a bit disappointing if it's really all that is new. You get... a bunch
of stuff from React that's mostly already available through libraries?

~~~
bradstewart
Personally, I find it fantastic that the core API and feature set are this
stable across an entire rewrite of the framework's internals (moving to
`Proxy` for change tracking, etc). Vue has every feature I need already.

------
ausjke
technical beside, I'm worried about the hit-by-a-bus factor, even though Evan
is no longer the sole developer, he remains to be the crucial single point of
failure. for that alone I chose React, yes it's harder to start there, but the
job market and a large company devoting to it made me sleep better.

