Software-update: Vue.js 3.0

Vue.js is een opensource model–view–viewmodel JavaScript-framework waarmee gebruikersinterfaces en single-page applications kunnen worden gemaakt. Vue.js behoort, naast React en Angular, tot een van de meest populaire front-end javascript-frameworks. Het is een creatie van Evan You en wordt door hem met behulp van een zeer actieve community onderhouden. Vrijdag is versie 3.0 van Vue.js uitgekomen en de release notes voor die uitgave kunnen hieronder worden gevonden.

Vue.js version 3.0.0 One Piece

Today we are proud to announce the official release of Vue.js 3.0 "One Piece". This new major version of the framework provides improved performance, smaller bundle sizes, better TypeScript integration, new APIs for tackling large scale use cases, and a solid foundation for long-term future iterations of the framework.

The 3.0 release represents over 2 years of development efforts, featuring 30+ RFCs, 2,600+ commits, 628 pull requests from 99 contributors, plus tremendous amount of development and documentation work outside of the core repo. We would like to express our deepest gratitude towards our team members for taking on this challenge, our contributors for the pull requests, our sponsors and backers for the financial support, and the wider community for participating in our design discussions and providing feedback for the pre-release versions. Vue is an independent project created for the community and sustained by the community, and Vue 3.0 wouldn't have been possible without your consistent support.

Taking the "Progressive Framework" Concept Further

Vue had a simple mission from its humble beginning: to be an approachable framework that anyone can quickly learn. As our user base grew, the framework also grew in scope to adapt to the increasing demands. Over time, it evolved into what we call a "Progressive Framework": a framework that can be learned and adopted incrementally, while providing continued support as the user tackles more and more demanding scenarios.

Today, with over 1.3 million users worldwide^*, we are seeing Vue being used in a wildly diverse range of scenarios, from sprinkling interactivity on traditional server-rendered pages, to full-blown single page applications with hundreds of components. Vue 3 takes this flexibility even further.

Layered internal modules

Vue 3.0 core can still be used via a simple <script> tag, but its internals has been re-written from the ground up into a collection of decoupled modules. The new architecture provides better maintainability, and allows end users to shave off up to half of the runtime size via tree-shaking.

These modules also exposes lower-level APIs that unlocks many advanced use cases:

• The compiler supports custom AST transforms for build-time customizations (e.g. build-time i18n)
• The core runtime provides first-class API for creating custom renderers targeting different render targets (e.g. native mobile, WebGL or terminals). The default DOM renderer is built using the same API.
• The @vue/reactivity module exports functions that provide direct access to Vue's reactivity system, and can be used as a standalone package. It can be used to pair with other templating solutions (e.g. lit-html) or even in non-UI scenarios.

New APIs for tackling scale

The 2.x Object-based API is largely intact in Vue 3. However, 3.0 also introduces the Composition API - a new set of APIs aimed at addressing the pain points of Vue usage in large scale applications. The Composition API builds on top of the reactivity API and enables logic composition and reuse similar to React hooks, more flexible code organization patterns, and more reliable type inference than the 2.x Object-based API.

Composition API can also be used with Vue 2.x via the @vue/composition-api plugin, and there are already Composition API utility libraries that work for both Vue 2 and 3 (e.g. vueuse, vue-composable).

Performance Improvements

Vue 3 has demonstrated significant performance improvements over Vue 2 in terms of bundle size (up to 41% lighter with tree-shaking), initial render (up to 55% faster), updates (up to 133% faster), and memory usage (up to 54% less).

In Vue 3, we have taken the approach of "compiler-informed Virtual DOM": the template compiler performs aggressive optimizations and generates render function code that hoists static content, leaves runtime hints for binding types, and most importantly, flattens the dynamic nodes inside a template to reduce the cost of runtime traversal. The user therefore gets the best of both worlds: compiler-optimized performance from templates, or direct control via manual render functions when the use case demands.

Improved TypeScript integration

Vue 3's codebase is written in TypeScript, with automatically generated, tested, and bundled type definitions so they are always up-to-date. Composition API works great with type inference. Vetur, our official VSCode extension, now supports template expression and props type checking leveraging Vue 3's improved internal typing. Oh, and Vue 3's typing fully supports TSX if that's your preference.

Experimental Features

We have proposed two new features for Singe-File Components (SFC, aka .vue files):

• <script setup>: syntactic sugar for using Composition API inside SFCs
• <style vars>: state-driven CSS variables inside SFCs

These features are already implemented and available in Vue 3.0, but are provided only for the purpose of gathering feedback. They will remain experimental until the RFCs are merged.

We have also implemented a currently undocumented <Suspense> component, which allows waiting on nested async dependencies (async components or component with async setup()) on initial render or branch switch. We are testing and iterating on this feature with the Nuxt.js team (Nuxt 3 is on the way) and will likely solidify it in 3.1.

Phased Release Process

The release of Vue 3.0 marks the general readiness of the framework. While some of the frameworks sub projects may still need further work to reach stable status (specifically router and Vuex integration in the devtools), we believe it's suitable to start new, green-field projects with Vue 3 today. We also encourage library authors to start upgrading your projects to support Vue 3.

Check out the Vue 3 Libraries Guide for details on all framework sub projects.

Migration and IE11 Support

We have pushed back the migration build (v3 build with v2 compatible behavior + migration warnings) and the IE11 build due to time constraints, and are aiming to focus on them in Q4 2020. Therefore, users planning to migrate an existing v2 app or require IE11 support should be aware of these limitations at this time.

Next Steps

For the near term after release, we will focus on:

• Migration build
• IE11 support
• Router and Vuex integration in new devtools
• Further improvements to template type inference in Vetur

For the time being, the documentation websites, GitHub branches, and npm dist tags for Vue 3 and v3-targeting projects will remain under next-denoted status. This means npm install vue will still install Vue 2.x and npm install vue@next will install Vue 3. We are planning to switch all doc links, branches and dist tags to default to 3.0 by end of 2020.

At the same time, we have started planning for 2.7, which will be the last planned minor release of the 2.x release line. 2.7 will be backporting compatible improvements from v3, and emit warnings on usage of APIs that are removed/changed in v3 to help with potential migration. We are planning to work on 2.7 in Q1 2021, which will directly become LTS upon release with an 18 months maintenance lifespan.

Versienummer	3.0
Releasestatus	Final
Website	Vue.js
Download	https://github.com/vuejs/vue-next/releases/tag/v3.0.0
Licentietype	GPL

Reacties (30)

[GBB1]

Ik ben een tevreden Vue 2 gebruiker met de Vue composition API. Super handig en super flexibel! Een jaar geleden was ik begonnen met een cursus Angular maar dat bleek wat te complex voor mij. Met Vue is de leercurve wat makkelijker en kan je ook alles doen wat je met Angular ook kan. Zeker aan te raden!

[AmazingDreams]

Ik heb veel gewerkt met Vue, een beetje React en momenteel Angular. Ik vind Vue het fijnste werken van de 3. Angular dwingt wel een bepaalde structuur af waardoor het voor de langere termijn wellicht een betere keuze is. Tegelijkertijd wordt een Angular applicatie naar mijn idee automatisch veel complexer dan dezelfde Vue applicatie

Ik denk ook dat de virtual DOM aanpak van Vue en React "beter" is dan de fysieke DOM van Angular. Bij Angular merk je soms dat het feit dat componenten fysiek in de DOM staan toch onverwachte consequenties heeft. Zo lijken Firefox en Chrome anders om te te gaan met onbekende tags en zijn statische parameters terug te vinden in de DOM

[Martinspire]

Je hoeft die componenten niet in je DOM te zetten met Angular, dat kun je omzeilen. Verder is dat vooral een CSS issue, dan een framework issue. Dan heb je op generieke componenten niet de juiste CSS staan om ze juist te renderen. Je kunt er prima CSS aan toevoegen om dat op te lossen. Of dus het element weghalen. Verder was dit meer een issue bij Angular 2 dan met de huidige browserversies.

[AmazingDreams]

Klopt je kunt CSS toevoegen aan componenten om te hier omheen te werken, het probleem is alleen dat je dat dus moet doen. Bij Vue is het noodzakelijk om een root tag te gebruiken waarmee je gedwongen wordt of je een div, a, span enz bent. De browser native styling wordt vanzelf toegepast en er is geen sprake van een default 'lege' parent zonder styling. Heb je een linkje naar meer info over de component tags niet in de DOM?

EDIT doel je op attribute selectors? Interessant om eens te proberen

[Reactie gewijzigd door AmazingDreams op 22 juli 2024 22:39]

[Martinspire]

Wat ik bedoel is dat je dan wellicht geen styling hebt toegepast op *, veel CSS frameworks doen namelijk * { box-sizing: border-box; } om ze vergelijkbaar te stylen. Een onbekend element heeft geen styling dus is het niet raar dat ie styling nodig heeft om goed te werken. Je kunt, als je wilt, ook gewoon alleen met directives werken om divs e.d. te gebruiken voor je componenten, maar er is weinig voordeel mee te behalen. De :host selector kun je ook nog gebruiken in je (S)CSS van de component.

Je geeft zelf de attribute selector al aan, dus dan gebruik je div[my-component], dat werkt gewoon prima. Het ding is alleen dat het een lapmiddel is en je beter de oorzaak kunt aanpakken. Browsers maakt het weinig uit om een extra element te renderen.

Het fijne vind ik verder aan Angular dat je niet je collectie van modules hoeft samen te stellen, maar dat je met de basismodules al ver kunt komen. Geen extra zaken nodig voor routing of state, wat ervoor zorgt dat dit ook goed geïntegreerd is in andere modules. Bij React en Vue ben je toch een tijd bezig om (soms zelfs per project) een goede module te zoeken, waarbij ook zaken als testibility en onderhoud of zelfs documentatie/tutorials goed zitten. Je kunt het wel vervangen als je dat wilt, maar voor de meeste projecten is dat gewoon niet nodig. Heb je 1 project gemaakt, dan kun je met andere projecten ook wel overweg en dat is met React/Vue toch een stuk minder imo.

De grootste stap in kennis voor het leren van Angular zit imo vooral in de stap naar Typescript, maar dat kun je vervolgens in meer projecten/libraries gebruiken. De structuur die dat vervolgens biedt, maakt dat je applicaties een stuk betrouwbaarder in elkaar zitten en het ontwikkelen een stuk makkelijker gaat.

[Reactie gewijzigd door Martinspire op 22 juli 2024 22:39]

[AmazingDreams]

Ja je kunt prima border-box toepassen op *, maar bijvoorbeeld display of font styling moet je daar niet in willen zetten, en FF lijkt anders om te gaan met een lege display dan Chrome. Je kunt ook niet eenvoudig een class toevoegen aan je host element. Wat overigens ook niet meehelpt is dat we moeten werken met een bar slecht CSS framework - als je het al een framework kunt noemen.

We kunnen ook eindeloos steggelen over wel / niet, beter / slechter, sommige dingen zijn voor bepaalde toepassingen handiger op de ene manier dan op de andere manier. Ik kom zelf ook primair uit een Vue mindset dus dingen die daar wel werken moeten nu op een andere manier.

[Martinspire]

Die class kun je zetten waar je het element gebruikt, al kun je @HostBinding ook gebruiken. En er zijn inmiddels prima CSS Frameworks te gebruiken met angular en als je wilt kun je het ook gewoon helemaal los trekken en weer een aparte stylesheet gebruiken. Ligt er allemaal maar aan wat je fijner vindt werken. Ik zelf zet ze meestal gewoon op de elementen binnen mijn component, niet op de host want dat blijft gewoon een wrapper.

Ik vind Vue wel fijner werken dan React maar zou beiden niet gebruiken voor grote applicaties. Het optimaliseren van een enkele pagina (of server rendered toepassing) kan het prima voor werken, maar als je met complexe formulieren en meerdere pagina's aan de slag moet, vind ik Angular nog steeds vele male fijner. Voor mijn gevoel zijn Vue en React meer de vervangers waar we vroeger jQuery voor gebruikten en blijft Angular toch vooral geschikt voor grotere applicaties of als je met dezelfde componenten meerdere applicaties moet bouwen. Er zijn projecten waar het overkill is of waar je wellicht sneller een demo kunt maken in React of Vue, maar dat maakt het niet meteen beter, eerder anders. Ze maken wel mooie stappen met Vue en qua organisatie loopt het ook wel prima, de vraag is alleen wel of de new kid on the block de aandacht erbij kan houden en niet straks weer wordt vervangen door the next best thing. Veel Vue ontwikkelaars zijn niet bepaald rotsvast en dat heeft zo zijn voor en nadelen

[Reactie gewijzigd door Martinspire op 22 juli 2024 22:39]

[GBB1]

Het is inderdaad zo dat Angular out of the box veel functionaliteiten biedt die andere pakketten misschien niet onmiddellijk lijken te hebben. Hoewel, sinds Vue 3 en ook Vue 2 met de Composition API is state management bvb super makkelijk geworden. Dat zit er gewoon standaard in waardoor je niet langer een ander pakker als Vuex moet gebruiken. Bijkomend is Vue 3 ook gebouwd met het oog op Typescript ondersteuning. Ik wil maar aangeven dat Vue de laatste 2 jaar echt wel enorm verbeterd is. Zeker nu je alle functionaliteit in een component niet langer moet opsplitsen zoals met de Options API en Mixins maar dat je nu gewoon een composable function kan maken die je heel eenvoudig kan hergebruiken op andere plaatsen in de app.

Met deze nieuwe zaken er bij denk ik echt wel dat Vue een geduchte concurrent is geworden voor React en Angular. Het voordeel dat Angular nog steeds heeft is "you have to build it in the Angular way becuase there's no other way". Maar dat is ook tevens het nadeel. Bij Vue is de leercurve zo laagdrempelig dat je heel snel iets moois kan bouwen en die kennis kan meenemen om in een latere fase entreprise grade apps te bouwen met standaard JavaScript kennis (refererende naar de composable functions, een eigen gebouwde event bus als je dat wil, ...).

[Reactie gewijzigd door GBB1 op 22 juli 2024 22:39]

[VanStino]

Ik ben ook begonnen op Angular een aantal jaren terug, nadien React beginnen leren en dat klikte voor mij ook veel sneller en ik zag de logica van React veel sneller dan die van Angular. Een dik jaar geleden begonnen aan Vue en voor mij werkt Vue ook het aangenaamste met React een close tweede plaats. Angular vind ik echt niet fijn werken, maar ik snap het nut van Angular wel in grote projecten.

Evan Hue heeft kort gepresenteerd hoe Vue 3 tot stand is gekomen en hoe meer ik die mens hoor praten hoe meer ik zijn visie apprecieer. Hij is ook niet beschaamd om te zeggen dat ze bijvoorbeeld inspiratie hebben gehaald bij o.a. React Hooks.

[Robert-Jan]

Tevreden gebruiker van Vue 2(.6). Het web framework zit gewoon logisch in elkaar en is daardoor prettig en intuïtief in gebruik.

In het begin de ontwikkeling van Vue 3.0 gevolgd. Toen was er nauwelijks backwards compatibility en leek de next version behoorlijk overengineerd. Het schijnt dat ze later nog flink aan de API gesleuteld hebben om het een en ander te versimpelen en in concept backwards compatible te houden.

Iemand al ervaring met de migratie naar Vue 3?

[keeperson]

De migratie an sich valt wel mee. In de CLI zit een tool om je project te migreren. Anders dan dat zijn de Vue.use calls wat veranderd, het definiëren van (niet class) components wat anders en zijn er wat libraries toegevoegd.

[GBB1]

Gewoon dit filmpje even bekijken en je bent mee.

[Finder]

Deze tutorial site is echt wel de moeite, en ga ik gebruiken om de overgang naar 3 te maken: https://www.vuemastery.co...o-to-vue-3/intro-to-vue3/

[HollowGamer]

Het kan aan mij liggen, maar waarom kijkt iedereen video tutorials? Het is zo onhandig, zeker als je met coderen bezig bent en voorbeelden niet kunt copy/pasten.

Anyway, erg benieuwd naar Vue3. Er zijn grote stappen gemaakt en vooral Typescript zou nu goed supported moeten zijn. Het enige waar ik mij zorgen om maak zijn de plugins/modules, die zijn zowel Vue/Vuex. Gelukkig gebruik ik wel al een framework (Nuxjs, Quasar, etc.), zodat je zelf die overstap makkelijker maakt.

[Timo002]

Omdat in een video vaak uitgelegd wordt hoe iets bedoeld is? Beetje copy pasten wordt je niet veel wijzer van.

Daarbij, ze leveren voorbeeld code mee. Die kun je via GitHub gewoon klonen.

[Reactie gewijzigd door Timo002 op 22 juli 2024 22:39]

[Jogai]

Dat kan in een blog ook. Maar in een blog kan je met ctrl+f veel makkelijker zoeken, en een artikel even snel scannen gaat ook veel makkelijker dan een video. Copy-pasten wordt je niet wijzer van, maar vaak kijk ik in blogs e.d. even terug hoe het ook al weer zat, en dan is het makkelijker dat het wel kan. En daarbij kan je veel sneller de essentie er uit halen, want meestal wordt de uitleg best uitgebreid gedaan om alle nivo's te kunnen bedienen.

[Jogai]

Ik snap dat format ook niet. Voor echte beginners, of als iets compleet nieuw is dan zal het wel ok zijn. Waarschijnlijk is het makkelijker te monetizen.

[apokalypse]

De licentie is MIT, zeker geen GPL

https://github.com/vuejs/vue-next/blob/master/LICENSE


Een migratie guide kan je hier vinden:
https://v3.vuejs.org/guide/migration/introduction.html

[Reactie gewijzigd door apokalypse op 22 juli 2024 22:39]

[HollowGamer]

Er zijn wel flink wat wijzigingen zo te zien, vooral hoe de API werkt. Het valt mij ook op/tegen dat bepaalde zaken zijn verwijderd zoals listeners, filters, etc. Die zul je nu dus op andere plaatsen moeten neerzetten of een store moeten gebruiken.

Listeners vind ik persoonlijk wel handig, niet alles hoeft in een store, al begrijp ik de verwijdering opzicht wel omdat velen deze niet goed gebruikte of niet begrepen waarom een event niet aankwam.

[mnugter]

Mooi, ziet eruit als een grote stap voor Vue.

Bijna jammer dat ik nu alleen nog maar met Elm werk

[HollowGamer]

Het probleem is wel dat er gigantisch veel is op JavaScript gebied en dit ook continue veranderd. We begonnen met iets als jQuery, Angular, React en nu dus ook Vue. Het is leuk dat er steeds verbeteringen komen en de andere weer fijner werkt dan de vorige, maar soms word je ook gek van al die nieuwe talen, de markt verwacht ook maar even dat je die zo onder knie hebt. Echt goed programmeren met één taal kost gewoon tijd.

Als voor jou Elm werkt, dan is dat niet perse iets slechts. Genoeg die ook nog met jQuery werken, al zou ik persoonlijk niet meer dit gebruiken en volledig overstappen op één taal zoals dus Vue.

[Reactie gewijzigd door HollowGamer op 22 juli 2024 22:39]

[Jogai]

In die ontwikkeling zitten nog wel wat tussenstappen, zoals knockout. Het is een soort evolutie denk ik dan maar.

Overigens is het allemaa 1 taal (js) maar je hebt wel gelijk, doordat het een ander paradigma is moet je wel even schakelen.

[SideShow]

Ik hoop dat TypeScript optioneel is.

[Jogai]

Het is.

[SilentLucidity]

In typescript kan je gewoon JavaScript schrijven. Of je gebruikt alle pluspunten die TS met zich meebrengt. Beetje rare opmerking naar mijn mening

[Cyb]

Ik kan zijn reactie wel begrijpen, even los van of het terecht is.

Maar ik vind het wel een opvallende en interessante ontwikkeling: statically typed vs dynamically typed languages. Programmeurs vallen vaak in 1 van de 2 kampen, en hebben vaak een hekel aan het andere kamp. Puur TypeScript maakt code veiliger en gemakkelijker te onderhouden, maar verhoogt ook de leercurve en kan de complexiteit verhogen indien je bloot wordt gesteld aan allerlei types van een api.

Evan You zegt over JavaScript in de codebase van Vue: "code like this in plain JS will be a nightmare to maintain in the long run".

Angular was vroeger in JS, nu in TS. Node.js is JS, maar de maker heeft het herschreven naar TS in Deno. Nu is Vue dus ook herschreven van JS naar TS. De documentatie is echter wel in JS. Ik ben benieuwd of ze in de toekomst TS ook als default gaan hanteren.
Doordat JavaScript een steeds grotere rol heeft gekregen, van niet alleen meer een DOM taal in de browser, naar taal op front-end en back-end, trekt het een groter public aan programmeurs aan, en is de vraag naar static typing voor JavaScript ook groter geworden.

[Mar2zz]

Wellicht komen die 2 kampen voort uit het principe onbekend maakt onbemind. Ik ben van origine, en voor mijn brood altijd "typeloos" aan het programmeren geweest.

De leercurve was me ook altijd net wat te hoog als ik eens met types speelde. Maar nu de IDE's zo goed zijn geworden met intellisense is de curve minder hoog. Ik heb juist door typescript veel meer kennis en feeling gekregen voor Javascript. Het geeft ook veel meer informatie als je code van anderen leest als het typed is. Het voelt natuurlijker ook, direct vertrouwder.

Je ziet andere talen er ook heen bewegen, zoals php, en wie had dat vijf jaar geleden gedacht?

Over een jaar of 10 zien wel alleen nog typed languages waarschijnlijk, het zal in ieder geval business level verwacht worden dat je typed oplevert.

[Martinspire]

Ik denk dat het niet heel handig is om beiden te hanteren, je gaat dan krijgen dat mensen problemen hebben, daar oplossingen van zoeken die niet matchen met wat ze nodig hebben. En dan ben je dus weer werk aan het doen om dit te fixen.

Daarom snap ik wel dat Angular over is gegaan naar TS zonder verdere ondersteuning van JS ernaast.

Het grote pijnpunt van Typescript is vooral de dependencies die je gebruikt. Als je daar zelf een interface voor moet schrijven, dan kan dat best pittig zijn. Maar wellicht is er een alternatief beschikbaar die al wel is bijgewerkt. Zeker nu Typescrpt al een tijdje op de markt is en er meerdere frameworks/libraries zijn, is het een stuk makkelijker dan toen Angular net uit was.

Ik hoop dat Vue vanaf v4 of zo ook gewoon Typescript forceert, het maakt de migratie gewoon een stuk simpeler en het maakt het ook makkelijker om scripts te schrijven die automatisch migreren (omdat je weet welke interface erachter hangt).

Ik was voorheen ook wel een tegenstander, zag het nut er niet van in, maar na een lange tijd ermee gewerkt te hebben en een goede set regels ingesteld te hebben, werkt het ook in de IDE een stuk makkelijker en sneller. Ik ga niet ontkennen dat er een leercurve is, maar die is wel erg nuttig en maakt dat het minder uitmaakt wat voor project je aan het doen bent of wat voor framework/library erachter hangt.

[Jogai]

Leuk dat dit ook in de meuktracker voorbijkomt! Niet aan gedacht om te submitten, maar best groot nieuws voor vuejs developers. Er zijn genoeg pre-releases geweest.

Leuk weetje voor de tweakers, Evan You sprak gisteren op vuejs amsterdam (via video) na de aankondiging van 3.0

[Htbaa]

Wat is eigenlijk de beredenering om deze release naar een Anime (of Manga, als die er is) te noemen?