New Features in Vue 3

https://vueschool.io/articles/vuejs-tutorials/exciting-new-features-in-vue-3/

by rahaug • 7 years ago

164 108 7 years ago

dmix2• 7 years ago

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

Roboprog• 7 years ago

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.

cies• 7 years ago

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?

bradstewart2• 7 years ago

You can use render functions instead of templates if you really want that.

It doesn't bother me though. Tooling (ESLint or TypeScript) will catch typos, missing methods, etc for you.

frenchman99• 7 years ago

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.

cremp• 7 years ago

I think what he means is why not use ++ in the click handler. We don't need a function to increment something.

Standard HTML, onclick="var++"

lima• 7 years ago

Still makes it harder to refactor, use code analysis/indexing tools and so on.

mpolichette3• 7 years ago

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?

jsmith45• 7 years ago

Would you be happier with the following?

That is legal (or at least it is supposed to be, I've not tested it), but is not really different. This part of Vue parsing is dictated by the whatwg html specification, and the html spec says that <html lang=en> and <html lang="en"> are the same thing.

ng129• 7 years ago

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

It's the curse of the template. Once you have them you inevitably start encoding more of your logic in magic-voodoo template directives.

zamalek4• 7 years ago

TSX is supported by Vue and, unlike templates, that is not opaque to the compiler. I recently switched the code in a side project of mine to TSX and it was worth the change.

Rapzid2• 7 years ago

Do you have any pointers on setting up TypeScript properly for the jsx render function while preserving intellisense? "Supported" is a bit tenuous based on the manual setup and shim creation required to get it all working nicely..

Vinnl• 7 years ago

But that feels a bit like saying you can use React without JSX. Sure, you can, but it appears that the templates are a major selling point for Vue to many people. That's the part that's most baffling. (Well, not really baffling, as it's a pretty subjective matter. But not for me, at least :)

hateful• 7 years ago

In vue you can do <button @click="increment()"> and it treats it the same. I tend to put the (), especially since I am almost always passing in some sort of object inside a loop.

hermanradtke• 7 years ago

Isn’t that still a string?

maxfurman• 7 years ago

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?

mixmastamyk• 7 years ago

Better than a poke in the eye with a sharp stick, aka compatibility break.

bradstewart2• 7 years ago

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.

aliveupstairs3• 7 years ago

because these are the things everyone comes in contact with and uses. there are indeed new features (in Vue 2 even) that have to do with dynamic Vue directives in the template and other three or fours features that unless you are writing an insanely reusable component or a Vue plugin, you would settle for a more orthodox and long way of doing things approach.

alexcroox2• 7 years ago

I'm most excited about the reduction in bundle size and the ability to tree-shake the source.

KaoruAoiShiho3• 7 years ago

It's not, this is just a few standout features that the website found compelling. I'm more excited about the massive performance improvement and typescript support.

preommr4• 7 years ago

This is a major rewrite, so there are a lot of cool changes like much better performance, better ts support, separating the underlying parts of vue to do things like have better control of making things reactive, then the api change that everyone has been panicking about, use of proxies (the implications of which I can't remember now), etc.

RobertRoberts3• 7 years ago

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• 7 years ago

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

mpolichette3• 7 years ago

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.

alipang2• 7 years ago

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?

nickdandakis• 7 years ago

Preferred syntax should be enough, but here's a couple more differences:

- Vue has a set of core libraries (Vuex, vue-router, etc) maintained by the same org.

- Single file components with scoped styling out of the box.

- Vue integration as a standalone runtime is a little easier than React (unsure about this one).

You can read more about the differences here:

https://vuejs.org/v2/guide/comparison.html#React

I couldn't find any official comparison documentation from the React docs, though.

ng129• 7 years ago

Single file components

Honestly I think this is a step backwards. How many components my "component" is built out of should be an implementation detail.

Rapzid2• 7 years ago

Wouldn't mind some other opinions on this but having used Mobx a lot in the past and starting to look at Vuex for current employer it's not looking enticing in comparison.. Mobx will work with Vuejs and I'm reading about a lot of people who have switched from vuex and been very happy. Considering just jumping in with Mobx and the bindings..

My and many others dev environments lean heavily on Vetur and it.. Is plagued with various issues in various releases. JSX/TSX JustWork™ while SPCs are okay sometimes but other times are found wanting..

jaequery• 7 years ago

"The React core team has done a wonderful job incorporating actual CS concepts like algebraic effects into their framework"

Is that a good thing?

acemarke• 7 years ago

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

brlewis3• 7 years ago

More on the relationship between hooks and the proposed Composition API: https://vue-composition-api-rfc.netlify.com/#comparison-with...

palerdot• 7 years ago

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/

lhorie2• 7 years ago

Approximating Suspense to algebraic effects is a pet peeve of mine. Algebraic effects are more akin to DI or at best to using a generator than the throw-and-retry-everything hack that Suspense does. And to boot, that's not even necessarily the right abstraction (e.g. AFAIK multiple nested suspense things are still an open issue).

I do agree that Vue seems to be reactive in its choice of features, in the sense that it tries to be everything to everyone.

The underlying problem IMHO is that these frameworks are unwilling to create major breaking changes (since that would hamper marketability) so it's easier to just shove things into the unused edges of the semantics space until they becomes a hodge podge of a million ways of doing the same thing.

I feel like Angular is the one framework that sorta "gets it" now. It went all the way to CS lala-land w/ 1.x and rewrote from the ground up for v2 taking several lessons from its v1 and from elsewhere.

brlewis3• 7 years ago

The underlying problem IMHO is that these frameworks are unwilling to create major breaking changes (since that would hamper marketability) so it's easier to just shove things into the unused edges of the semantics space until they becomes a hodge podge of a million ways of doing the same thing.

Sounds like you want Mithril, but keep in mind that backward compatibility and marketability are, in fact, useful features.

Scarbutt• 7 years ago

Picking on your brain and hindsight ;) , and as someone who did little ES5 and DOM/browser API programming in the past, what would you recommend today for a fast track to a SPA for a solo project? (The learning process is not an issue). The interactivity is not very high but the UX can benefit from a SPA, is an invoicing system.

JS Framework, CSS methodology(UI framework?), etc... or any other perspective you want to share.

preommr4• 7 years ago

a wonderful job incorporating actual CS concepts like algebraic effects into their framework.

What does "actual CS concepts" event mean? This is the first time in my life that I've heard about algebraic effects.

If I am understanding your comments, the implication seems to be react is implementing concepts that elevate the tool while vue goes around in circles to make an alternative syntax.

I don't even agree that the react team has done a good job with implementing a clear concept for their framework. Things like Elm have done a much better job of that. Granted that's a lot easier to do when they don't have to force themselves to deal with js directly.

But even then, why is react implementing hooks not bad, but vue implementing them is? There's a reason why react made the switch, and some of those advantages also apply in vue. These changes aren't just made to follow trends.

alipang2• 7 years ago

There's been an unfortunate trend in the JS world where a lot of frameworks are created, but without any real meaningful sense of progress, resulting in a sense of going around in cycles in various "reskins" with different syntax and conventions, all round some kind of core MVC idea.

When I say "actual CS concepts" I mean things that have been broken down into it's core using a suitable mathematical model. This is ultimately a much more suitable way bo build tools used by engineers.

My personal concerns is that Vue to me is mostly just a reskin with new syntax on things that are already in React. Hooks become the "composition api". Redux becomes VueX. Is this necessary?

Could VueX just have been an alternative to Redux, like MobX is?

Could we just have implemented a Webpack-loader to put styles and react components together?

Some people don't like that React uses `className` instead of class. Is `v-bind:class` and various `@` notations really so much better we can justify a whole new ecosystem?

So roughly - Vue provides fragmentation in the frontend ecosystem. I like competition - but what does it really offer that justifies it? I don't get it, and now what they have been working on is just catching up to React.

al2o3cr• 7 years ago

TBH, React feels like what you get when a bunch of very smart devs decide to "incorporate actual CS concepts like algebraic effects" into showing people ads.

Arguing that we should pick tools based on semantics without considering syntax is like arguing people should pick spouses based on genetics and not personality.

apatheticonion• 7 years ago

The thing that I find most amusing about modern front end is the over-emphasis developers put on the rendering engine.

Presentation is only a small portion of an application. A view rendering engine is required to do a couple of things, accept and render data.

The semantics of how it accepts data enables good software engineering practices like dependency injection and dependency inversion.

The semantics of how it renders data enable ergonomic usage of the renderer (templating, JSX).

Modern web developers tend to write "React" or "Vue" applications - not "Type/JavaScript applications that render with React"

Global objects, singletons fetched from module-powered service locators, unlimited power global stores and enough boilerplate to make the most hardened Java developer confess their sins to Oracle.

Looks like Vue 3 is fine but continues the trend of doing it all.

jakobloekke• 7 years ago

This! But I find that a combination of Typescript, MobX and React brings me very close to a good place.

neya• 7 years ago

Have you used both? This is a comment I usually see from people who have used only one, but not the other.

Let me give you some background about myself - I'm a full time consultant, I write both frontend and backend code for a living. I have worked for almost 27 companies in the last 2 years as a consultant. I have used both.

Vue may copy react, but their implementation and opinionated code structure (Eg. Single file components, Vue-Router, Vuex, etc.) is so much better than the complete freedom that React gives you. Almost all of them who used React had terrible code quality and really bad code organization. In contrast, the Vue code base I've worked with all had some level of uniformity enough for an external consultant to come in and understand what was going in. The worst code I've ever seen till date was on React from an analytics firm. I lasted 15 seconds after which I closed the tab and re-negotiated the contract to do only backend for that firm.

I'm not saying React is bad, end of the day, they're all just tools, but a vanilla TODO Vue application with its syntax is much much better to work with a vanilla TODO react app. Especially for large codebases, this is so true when you work with stuff to manage state like Flux/Vuex.

I also observed that companies using React usually also tend to do more re-writes of their codebases as it becomes unmaintainable over time without an opinionated way to do things like with Vue. Companies with Vue also seem to be more profitable and less reliant on VC money. You can feel free to verify these stats by heading over to LinkedIn/Angel.co and checkout the companies who hire for Vue/React.

So, to answer your question - Does Vue truly offer anything over React that's not in the realm of preferred syntax?

Definitely (as I explained above). I personally would never touch React for a prototype or a project that needs to go to market with less bugs.

ng129• 7 years ago

a vanilla TODO Vue application with its syntax is much much better to work with a vanilla TODO react app

These would be almost identical in structure and design. You're drastically overstating the difference between React and Vue.

aitchnyu3• 7 years ago

Picking your brain. Somehow React+Redux feels the stuff of horror stories. Which of React, React+Redux, Vue, Vue+Vuex will lead to the least disaster for a sloppy team?

nailer• 7 years ago

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.

Aren't hooks only needed because React and Vue still use a virtual DOM?

plopz• 7 years ago

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• 7 years ago

Yes

meerita• 7 years ago

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

alexcroox2• 7 years ago

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.

dmix2• 7 years ago

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.

preommr4• 7 years ago

I really want to use svelte, but I don't know when it'll be production ready. From what I can tell, it's aiming to do a lot more than be a simple js framework. For now, and probably the foreseeable future, vue is good enough. Tbh, the scope for svelte is so large I really wouldn't trust it unless it got really really popular.

wishinghand2• 7 years ago

While Svelte is being developed by a great programmer, it's too new, doesn't have all of it's Typescript stuff figured out, and last I checked the unit testing story was still a bit shaky. I'm guessing that in a year or less it'll get those three things figured out.

sansnomme3• 7 years ago

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

Transpilation and static analysis are the ways to go.

KaoruAoiShiho3• 7 years ago

I kinda agree but you should explain why your last statement is true.

eberkund• 7 years ago

In a recent presentation Evan You mentioned Svelte and basically said that their approach is better and if it weren't for backwards compatibility he'd have taken a lot more of their ideas for Vue 3

howdydoo• 7 years ago

How does Svelte help with static analysis? Genuinely curious here.

I've had my eye on this issue[1] for a while. I'm excited about the idea behind Svelte, but without static typing support, there's no way I could feel comfortable using it on a real project.

[1] https://github.com/sveltejs/svelte/issues/1639

sansnomme3• 7 years ago

Static analysis as in tracking variable mutation propagation on the compiler level. You don't need types for that.

GUI programs are inherently stateful and the functional model used by React and others boils down to shoving everything into a giant finite state machine. You explicitly specify all possible states when you code so the state of your GUI is explicit instead of implicit. In traditional GUI terms, immediate-mode versus retained-mode (immediate in the sense of DOM updates, the reference here is how often and how much do you mutate the DOM and not frames per second because the DOM is also stateful which is one of the reasons why web programming require so many hacks). Now this isn't easy in practice because of obvious reasons - the state space explodes as the number of variables increases and trying to having a single store to keep everything in sync can be difficult and annoying. Sure your code will be somewhat more bug-free in the end but you have to spend a lot of effort and end up with verbose code. Svelte on the other hand make variables reactive on the compiler level. So you get both the Excel-style reactive feeling out of the box and at the same time optimized runtime-less code that only mutates when it has to (current solutions all require a library runtime to keep track of things, diff DOMs etc.). In other words, like traditional hand written code but with the compiler preventing bugs due undefined state/variables getting out of sync issues.

My explanation is probably inaccurate/simplified in some aspects so please feel free to elaborate upon it.

leeman2016• 7 years ago

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• 7 years ago

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.

agumonkey• 7 years ago

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

mmanfrin• 7 years ago

This is a weirdly negative comment section.

KaoruAoiShiho3• 7 years ago

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

ng129• 7 years ago

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.

wishinghand2• 7 years ago

I've seen a lot of negativity towards Vue from React users pretty much since it started gaining actual usage by big companies. Never by the core React team, just the users of it. To a lesser degree, I've seen some Vue users express haughtiness because they see Vue as much less complicated.

preommr4• 7 years ago

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.

conradfr2• 7 years ago

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

ausjke• 7 years ago

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.

New Features in Vue 3

Related Stories