
Vue.js 3 - simulo
https://github.com/vuejs/vue-next/releases/tag/v3.0.0
======
RNCTX
Vue is the only one of the most popular 3 frameworks that can easily be used
on a minimal basis to sort of "spruce up" old applications by selectively
adding it here and there in the templates.

Seems like they should try more marketing and community outreach toward that
end.

Gradual adoption is a feature / selling point not many web development
frameworks can claim.

~~~
swyx
i'm afraid this is pretty much plain wrong. react and svelte also support
incremental adoption, and i dont know angular but i'd hazard there's a way to
do it too if you bothered to ask angular devs.

what you're responding to is _marketing_ , which Vue has done an effective job
of. thats fine, but it is unfair of you to conclude "Gradual adoption is a
feature / selling point not many web development frameworks can claim."

~~~
SPascareli13
I can tell you that not only he is right, but I've used Vue for exactly that
purpose before and works like a charm.

You can go pretty far using Vue with a <script> tag before you start needing
build tooling.

~~~
andrewflnr
That's not where they were wrong.

~~~
AsyncAwait
Look, I've used both Vue and React for this purpose and Vue is just easier to
integrate. React can do it too, but Vue places an emphasis on it and it shows.

~~~
andrewflnr
Yes, but that's a different and less flame-baity claim than the top-level's
"Vue is the only one".

------
lykahb
I am impressed how they redesigned both internal architecture and a public API
while keeping the users happy. Many well written projects fall into the trap
of being a great fit for the contemporary practices but become less relevant
over time as the ecosystem changes. Well done, Vue!

~~~
diminish
curious how easy it will be to move from vue 2 to vue 3

~~~
aethr
I am working on this right now on a medium-sized project, and it's deceptively
more work than we anticipated. While Vue's component API itself is remaining
mostly backwards compatible with Vue 2, most of the "core" supporting
libraries have changed their APIs: Vuex, VueRouter and vue-test-utils in
particular.

After the package update and some very basic find/replace across our codebase,
about half of our 600+ tests had to be significantly updated. If your tests
regularly mock a Vuex store or a router, be prepared to be making a lot of
updates.

If you're using some of the features being removed (filters, $on/$off/$once,
etc) or make heavy use of custom plugins, it's not going to be painless.

Having said that, I love the direction the new API is heading and 95% of the
changes we have to make are for the better in the end, so it feels worth it.

~~~
Already__Taken
to be fair though you are doing this in hard mode. to transition an app you
should wait for 2.7 to get all the warnings and guides. so good job to
everyone that you didn't find it herculean.

------
didip
I am impressed with the amount of energy Evan is pouring in this open source
project.

I am curious if he ever experience boredom working on Vue.

I am also curious if Patreon based income is sustainable for the long run.
What if there's another new sexy JS framework in the future?

~~~
mushufasa
> What if there's another new sexy JS framework in the future?

That's how a market works. It's a strong incentive to keep Vue sexy.

~~~
j-krieger
The market also isn't as volatile as people make it out to be. The top most
used js frameworks (React, Angular and Vue) have been in the top spots for 5
to 7 years now. I guess the market might as well be settled. Of course there
are some new comers every year, but they don't enjoy a large market share.
Hell, I've not even seen VueJS used once in any serious project in the
industry.

React and Angular are here to stay, and there's no changing that.

~~~
erokar
Angular seems to be dying. Svelte is an interesting contender. I think it will
be React's main competitor given a year or two.

~~~
mattlondon
Angular is massive - MASSIVE - within large orgs you will have heard of but
which I cannot name for obvious reasons.

The twitterati and hobbyist crowd seem to love react, but anecdotally I've yet
to see it used seriously at a BigCo, but Ng+TS is everywhere.

~~~
sdfhbdf
Your comment seems to present anecdotal evidence as facts about $framework's
popularity. I think that's misleading.

I'm wondering if there's a scraper out there crawling Alexa TOP 1xxx pages for
use of specific libraries, frameworks? Maybe that would present a more
accurate picture about this.

Also it's often misleading since in any company with more than a few employees
there seems to be more than one team of developers which often leads to
different frameworks being used in different parts of the company. In $dayJob
we use Angular in some legacy internal stuff, React in a rewritten consumer-
facing project and preact or jQuery in a different consumer-facing project.

It's not that simple to determine marketshare of frameworks I think. We can
just present different numbers and draw different conclusions from it, e.g.
number of job postings mentioning specific frameworks, number of downloads in
a registry, number of domains using it (assuming one app per domain), number
of stars on github or number of people claiming to use it in the stackoverflow
survey.

~~~
JMTQp8lwXL
A lot of the web isn't publicly accessible. And most .com marketing sites are
built on a much different tech stack than the actual product. Example: landing
page is Wordpress, actual site is a SPA (be it React/Angular/Vue etc).

------
fyrmio
> 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
> 120% less).

What does 120% less memory usage mean, really?

~~~
tyingq
It's definitely not how to show that, but if you follow their link
([https://docs.google.com/spreadsheets/d/1VJFx-
kQ4KjJmnpDXIEai...](https://docs.google.com/spreadsheets/d/1VJFx-
kQ4KjJmnpDXIEaig-cVAAJtpIGLZNbv3Lr4CR0/edit?usp=sharing)), you'll see the
numbers.

The math is like, if it did use 100mb, and now it uses 25mb, that's 300% less,
because 25mb is the "100%", and you reduced by that amount 3 times. Odd.

~~~
huseyinkeles
Is this the lingo that statisticians/mathematicians use?

I’d just say 75% drop for 100mb to 25mb.

~~~
pletnes
No, it’s plain wrong. You could say «vue 2 uses 120% more memory than vue3»,
but vice versa is thus a different percentage (yes, 75%).

------
filipsch
I was surprised to see an update to a contemporary JavaScript framework to be
welcomed rather than boo’d by the average HN reader. That in itself is an
accomplishment.

~~~
swyx
the appetite for a credible alternative to a Facebook project is _strong_.
also the vue team has done a great job dripping out information over the past
2 years and building anticipation. very little surprises in this release,
hence mostly celebration left. you need to go back a bit further in time to
find the critical HN comments.

------
hugi
Live release announcement with Evan You going on right now:

[https://www.youtube.com/watch?v=Vp5ANvd88x0](https://www.youtube.com/watch?v=Vp5ANvd88x0)

~~~
x87678r
I didn't expect him to say "Enjoy the Vue" ha.

~~~
hugi
Programmer _and_ dad-level humor can be a pretty deadly combination.

~~~
kbenson
The combination of the two is so dangerous you could say it's dadly.

~~~
phist_mcgee
He took the joke father than he really should have.

------
umvi
So it looks like Vue releases are all named after anime?

For anyone curious, here's the full list:

[https://en.wikipedia.org/wiki/Vue.js#Versions](https://en.wikipedia.org/wiki/Vue.js#Versions)

~~~
dane-pgp
Is that a JoJo reference?

~~~
andrewflnr
It's my understanding that anything can be a JoJo reference if you want it to
be.

------
gavinray
My only wish now is for the TSX experience to be rounded out.

From a reactivity standpoint, Vue has a much more ergonomic/easy to use API
for handling component state, effects, and computed values (in my opinion)
than React.

But in the last 6-8 months, I've leaned away from Single-File Components
because when you want to do something like define a bunch of small components,
it's a lot more difficult to do than with multiple TSX functions you can chuck
in one file.

So I've been using Vue with TSX, and the experience (in the last few months
only, before that was pretty bad) is _okay_ , but not as solid as you'd get
with React.

I'm not the only one who must feel this way, because this exists and has a lot
of stars:

 _" Reactivue: Use Vue Composition API in React components"_

[https://github.com/antfu/reactivue](https://github.com/antfu/reactivue)

Unfortunately, this is a weird stance to take in the Vue community, almost
nobody uses JSX/TSX. Because of this, the development efforts towards it
aren't as much a priority.

Overall, I'd rate the experience as "decent" and "totally usable", but I hope
to see the DX for Vue's TSX community improve over the coming months.

\---

Edit 2: Disregard the below, this already exists apparently

Edit 1: Having to write two type definitions for Component Props: one TS
interface/type, and one as the JS object sucks. That's my one big complaint.

I know it's impossible because props need a runtime value but someone should
make a plugin/babel transform to decorate the "props" key from the generic
argument here:

    
    
       const MyComponent = defineComponent<MyComponentProps>
    

Use reflection on "MyComponentProps" to set "props" key.

There's another comment below discussing this drawback too.

~~~
EvanYou
> Having to write two type definitions for Component Props: one TS
> interface/type, and one as the JS object sucks.

Uh, you don't have to? TS inference works with the JS objects. There's no need
to provide the generic argument here.

Also check out this: [https://github.com/vuejs/rfcs/blob/sfc-
improvements/active-r...](https://github.com/vuejs/rfcs/blob/sfc-
improvements/active-rfcs/0000-sfc-script-setup.md#with-typescript) (auto-
generating runtime types from TS interface)

~~~
gavinray
Holy shit, Evan You replied to my comment.

Happy Vue user since 2016.

> TS inference works with the JS objects. There's no need to provide the
> generic argument here.

That's totally valid -- I am just being nitpicky and complaining because if
possible I'd prefer to do it the other way: TS type -> JS object

> auto-generating runtime types from TS interface

Whoa. Well, that solves that then.

------
quaffapint
Anyone know if Vue 3 is isolated? Like can you use it to make 3rd party
widgets and not worry about version conflict like you would with Vue 2?

------
superasn
One thing I'm really excited about with this version is Vite (the snowpack
type version of Vue that doesn't require webpack). It should make development
so much easier.

~~~
mcherm
As someone who includes we pack in my build chain in order to use vue but
doesn't _truly_ understand it and has never used Cute, can you explain the
advantages?

~~~
superasn
This is straight out of the horses mouth:

\- Lightning-fast cold server start \- Instant hot module replacement (HMR) \-
True on-demand compilation

This part should be of particular interest to you:

[https://github.com/vitejs/vite#how-is-this-different-from-
vu...](https://github.com/vitejs/vite#how-is-this-different-from-vue-cli-or-
other-bundler-based-solutions)

~~~
mcherm
Thank you.

------
IshKebab
I was hoping for better Typescript support for typing properties, since that
is where 90% of our type errors occur. But it seems like you still have to
specify the types manually. The example from the manual:

    
    
      const Component = defineComponent({
        props: {
          name: String,
          success: { type: String },
          callback: {
            type: Function as PropType<() => void>
          },
          message: {
            type: Object as PropType<ComplexMessage>,
            required: true,
            validator(message: ComplexMessage) {
              return !!message.title
            }
          }
        }
      })
    

Contrast this with React where this would be something like this (I think;
I've never used React):

    
    
      interface Props {
        name: string;
        success: string;
        callback: () => void;
        message: ComplexMessage;
      }
    
      export default class Component extends React.Component<Props> {
        ...
    

Quite disappointing. Maybe not that surprising given Evan said he only started
using Typescript very recently, and many beginner Javascript developers don't
realise that they should really be using Typescript (fortunately Evan isn't
one of them). I would recommend still avoiding Vue for this reason alone.

~~~
EvanYou
It's not that we can't implement it like that, the real challenge is in
minimizing breakage from v2. We decided it's better to not completely alter
how props are declared because that would be too much breakage.

Instead, there's the compiler-based approach with `<script setup lang="ts">`:
[https://docs.google.com/presentation/d/1VjBM6ae-
fuawK1TltYLX...](https://docs.google.com/presentation/d/1VjBM6ae-
fuawK1TltYLXtcXGaxJw1y8ncT6wnbjaBGo/edit#slide=id.g86a2c92822_0_168) (runtime
props definitions auto-generated from TS interface)

~~~
IshKebab
But if the prop definitions are generated at runtime that means Typescript
can't check them at compile time surely? Better than Vue 2 I guess but still
not as good as React.

Fair enough on not wanting to break things, but I still feel like it is Vue's
second biggest flaw and worth breaking to fix.

------
nikkwong
The announcement talk was nice to watch, however, it was technically void of
any of the implementation details.

It's interesting to me that they did not consider the approach of pushing more
work to the compiler and less to the runtime in the manner popularized by
Svelte. I wonder what the trade-off between their current rendering approach
and the Svelte-based approach are?

~~~
swyx
> they did not consider the approach

they certainly did, lol. the tradeoff is the same it's been; they want all of
vue available in a script tag.

~~~
nikkwong
Guess I missed that. That makes sense, it's an interesting trade-off though. I
suspect that including Vue via a script tag is not how the majority of users
implement Vue; and therefore clinging to the virtual DOM may be a net-negative
for most use cases. Personally, I am using Vue for a data-intensive app where
performance really really matters. Although, I understand how broadening
access to the framework increases availability and adoption; and for most use
cases these performance considerations don't have any real world implications.

It is interesting though looking across benchmarks though and seeing non
virtual DOM frameworks crushing their counterparts in terms of speed. I wonder
if we'll see more growth in that space in the future.

~~~
korm
Which benchmarks? In the js-framework-benchmark Svelte is slower than Inferno
or Ivi and only slightly faster than Preact or Vue.
[https://krausest.github.io/js-framework-
benchmark/2020/table...](https://krausest.github.io/js-framework-
benchmark/2020/table_chrome_85.0.4183.83.html)

You may be aware but it's also important to note that everyone is trying to
cheat these benchmarks so they don't mean much. The implementations aren't
data driven and don't look much like how we'd write real world code. See the
discussions here including the linked issues and PRs
[https://github.com/krausest/js-framework-
benchmark/issues/77...](https://github.com/krausest/js-framework-
benchmark/issues/772)

------
bewareandaware
I don't really understand the composition API. Doesn't passing values by
reference which can be modified anywhere downward the tree make your app
difficult to reason and debug it?

~~~
gavinray
I have a fairly large/complex SaaS platform built with Vue 3 composition API.
Can maybe shed some light.

A while ago I wrote the same component in Vue 2 and Vue 3 as an example of one
versus the other:

[https://codesandbox.io/s/bold-shamir-
uqm0b?file=/src/compone...](https://codesandbox.io/s/bold-shamir-
uqm0b?file=/src/components/Vue2.vue)

[https://codesandbox.io/s/bold-shamir-
uqm0b?file=/src/compone...](https://codesandbox.io/s/bold-shamir-
uqm0b?file=/src/components/Vue3)

If you meant more from a conceptual standpoint -- the usage patterns with Vue
3 is pretty nearly identical for most people. You just replace "data()"
property with some "reactive()" state value in setup (or "ref()" for single
values).

You CAN write things like generic hooks/"useXXX()" helpers, but you likely
won't wind up with a ton of those.

Also, about the reference passing: it doesn't actually really work like that.
If you pass a "ref()" or "reactive()" value as a prop to a child component,
and you mutate it there, it doesn't propagate to the parent.

Vue will throw this warning:

    
    
        [Vue warn]: Avoid mutating a prop directly since the value will be overwritten whenever the parent component re-renders. Instead, use a data or computed property based on the prop's value. Prop being mutated: "someRef"

------
Exuma
I just started vue 3 and its incredible compared to my experience with react.
Way to go Vue team!!!

~~~
azangru
> and its incredible compared to my experience with react

Could you expand on this a little more? What is it specifically that makes it
incredible compared to React, in your opinion?

~~~
Exuma
I like that vue manages dependencies so you dont worry about pure components
anymore, but I believe that was fixed recently in react? The biggest thing is
I despise writing JSX. To me it just feels absolutely miserable. The upside is
that you have incredible fine grained control over the dynamic rendering of
components, but so far even in my complex app there's been no need to write a
render function yet (similar equivalent in vue to get that same level of
control as react).

Also, I really like the data binding which vue took from angular. That was
always by far my favorite part of angular, rather than having the binding be
written in JS which feels too mechanic to me. I dont feel like I'm writing
HTML / front end code, I feel like I'm writing a hybrid mecha mutant of JS +
HTML + weird syntax.

------
winrid
Ha, I literally just built my first Vue 2.0 project yesterday. I'm already
behind! :)

(just a Chrome extension) [https://github.com/FastComments/fastcomments-
debug/blob/mast...](https://github.com/FastComments/fastcomments-
debug/blob/master/chrome/src/popup/App.vue)

------
TekMol
I still don't see a reason why one would use Vue or React.

I agree that templating of data is something you should use a library for. But
there are great templating libraries. Handlebars for example.

Can someone give a short example of code that would be more elegant using Vue
then just a simple template engine?

~~~
cjohnson318
One example is building an application like minesweeper. Would you really want
to tackle that with jQuery and templating engine? I'd rather break everything
into components, have them talk to each other through a state manger like vuex
or redux, and only phone home to my API for important things, like the final
game score.

~~~
TekMol
I would neither need jQuery nor a templating engine to write Minesweeper.

~~~
j-krieger
It's great you applied your vanilla JS skills to his totally metaphorical
example.

I still don't get why it's okay for every other programming language to use
the STL or huge dependencies, but doing so with javascript is frowned upon for
some people. You wouldn't write a JSON parser yourself in CPP, you'd install
something from conan or use the STL or boost for that. Why is it so bad to do
the same with js?

~~~
TekMol
The browser _does_ supply a huge number of APIs.

To set one of the Minesweeper tiles to bomb, you could do:

tiles[x][y].className='bomb';

And you are done. The rendering will nicely take place according to what you
defined in the CSS.

~~~
Exuma
What are you talking about? You're just talking about simple class
manipulation which has nothing to do with actual reactivity, especially 2-way
data binding.

How would you support that with your "templating engines" you keep mentioning,
which to me doesn't mean anything at all, in my understanding of what a
templating engine is like handlebars.

~~~
TekMol
As I said, I would not use a template engine to write Minesweeper.

~~~
ric2b
So when I click a tile you have some code on the onclick handler to go update
the counter at the top? Sounds messy if there are multiple things you need to
update when some data changes.

------
ausjke
Good to see this out. I want to pick a good frontend scheme for future
projects but I don't really need most of the fancy SPAs and the complexity
coming with it.

Invested a few weeks on Vue a few months back, then the concern about 'React
has 80% market share and you can find React developer much more easily in the
west" never went away.

Maybe Mithril is the way out? I just need a really light-weight client-side-
ajax MVC for some embedded product webUI, in fact jquery+BT might do the job
well but again, jQuery is not modern any more.

Not a frontend guy, picking a direction there has always been challenging.

~~~
madoublet
I think what is not mentioned with any of the big SPA frameworks is the amount
of time you invest in the churn between versions. After dealing with this in
Angular for a number of years, I ended up going with stock JavaScript for my
recent projects and could not be happier. Performance is much better. I have a
better understanding of what goes into the product. And, I am not constantly
dealing with a new version and breaking changes every 3-6 months.

~~~
ng12
That's really an Angular problem; React and Vue have had very few breaking
changes over the years.

~~~
swyx
indeed. React 16 celebrates its 3rd birthday next week.
([https://reactjs.org/blog/2017/09/26/react-v16.0.html](https://reactjs.org/blog/2017/09/26/react-v16.0.html))

------
TravelPiglet
Can I use it by including it with a script-tag?

Vue 2 was kind of possible to get up and running with a script-tag to get
components in a pre-existing app.

~~~
Exuma
Yes its possible

------
therealmarv
anybody know the status of Nuxt and vue 3 support?

~~~
gavinray
It's meant to be released sometime within the coming weeks from contributor
comments IIRC.

It works well with the Composition API plugin for Vue 2 though. They have a
dedicated package for this.

With the Nuxt VCA + Nuxt TS plugin, the experience is solid IMO.

------
jiofih
> allows end users to shave off up to half of the runtime size via tree-
> shaking

Doesn’t webpack support _actual_ tree-shaking (not just modules) or is that
still a Rollup-only feature? There should be little difference in size in
importing packages vs files if tree-shaking is on.

~~~
j-krieger
Webpack doesn't support actual, statically checked tree shaking for now. There
is a parameter called ''sideEffects'' you can employ in your package.json,
which if switched to off gives hints to the compiler that your code is side-
effect free and can thus be eliminated if not used.

------
zwieback
good timing. I'm about to start learning vue.js so I'll start with this. We'll
see how long it takes to "unlearn" 40 years of traditional programming and
jump into the world of web apps.

------
revskill
I don't know if React could allow set children's data via parent, like

$childRef.setData({ data })

When i see this code in a Vue codebase, my mind got hurt.

I still prefer React due to its consistent reasoning about data flow in the
app.

~~~
onion2k
That sounds like the equivalent to React's forward refs.
[https://reactjs.org/docs/forwarding-
refs.html](https://reactjs.org/docs/forwarding-refs.html)

~~~
acemarke
No, that's very different, in two ways.

First, `$childRef.setData()` appears to be the conceptual equivalent in React
of `childClassComponentInstance.setState({someField})`. While that's
technically possible, it's _extremely_ non-idiomatic in React and completely
discouraged.

Second, "forwarding refs" is a feature specifically designed to allow a
component to apply a ref to something _inside_ of itself. For example, the
React-Redux `connect` API uses ref forwarding to allow `<ConnectedComponent
ref={instanceRef}>` to hand back the inner wrapped component, not the outer
wrapper component from the library. It doesn't have anything to do with
calling a state setting function on a component in and of itself.

------
mariushn
Why is IE11 support still important now? I can't find exact stats on it, but
it seems <2%. Surely projects which still want to support IE11 could still
stick for a while with Vue2.

~~~
reaperducer
IE11 is still heavily used in some industries, such as healthcare. Browser
statistics services usually don't pick up on a lot of IE11 use because it's on
internal networks.

I wish I could ignore IE11, but the reality is that I can't.

~~~
dbbk
The point is that Vue 2 can continue to be used though. There's no need to
upgrade.

------
brylie
I've been confused by some of Evan's presentations about performance gains and
other statistics. For example, the release notes say

> updates (up to 133% faster)

How can something be > 100% faster?

~~~
wenc
If you take 100% faster to mean 2x faster (takes 1/2 the orig time), 200%
faster to mean 3x faster (takes 1/3 the orig time)...

Then 133% faster means 2.33x faster (takes 1 / 2.33 = 0.42 the orig time).

~~~
brylie
Thanks for clarifying :-)

------
badhabit
i learned vue2 3-4 years ago.

should i learn vue3 or svelte instead?

~~~
k__
Depends on what you want.

I researched tech required in job offers and React was first, running circles
around Angular and Vue. Nobody spoke of Svelte

~~~
j-krieger
Where I live, VueJs isn't even mentioned in any job postings. Large companies
still work with older Angular projects, new projects are more often than not
done in whatever fits the need.

------
jaequery
is reactive() just a mere wrapper around ref() ?

~~~
gavinray
Kind of -- reactive() lets you declare multiple values at once, and you can
read the property directly.

ref() is for single values, and to get at the actual VALUE, you need to use
"myRef.value"

    
    
       const state = reactive({ msg: "hello", count: 1 })
       state.msg // "hello"
       
       const msg = ref("hello")
       msg.value // "hello"
    

Though when you use ref()'s in templates, it will bind to .value for you.

~~~
mthoms
I find myself using `const state = reactive({...})` exclusively now. It's just
way simpler (read:less mental overhead). But, I've only been using the
composition API for a short while now.

Do experienced Vue devs actually use both regularly?

~~~
gavinray
Personally, I rarely use refs. I think they have more use when creating
general-purpose libraries for Vue.

You can also just call "toRefs()" on a "reactive()" object though.

Refs are also useful if you want to destructure a reactive object without
breaking the reactivity, scroll down just below this:

[https://composition-api.vuejs.org/api.html#torefs](https://composition-
api.vuejs.org/api.html#torefs)

------
jaequery
if this means no more Vuex, i'm all for that. that extra abstraction layer
never proved useful to me.

~~~
deergomoo
Out of curiosity, how do you handle data needed by tons of components at
different tree depths (info about the current user for example)?

I don’t always reach for Vuex, but when an app reaches a certain size it sure
beats passing every bit of common data down through the entire tree, as I find
you quickly hit a point where you’re passing data to components solely so it
can pass it to _it’s_ children.

~~~
zmmmmm
It's funny I still have never really understood the case for Vuex. So far I
have built decent complexity apps just by having a global reactive object that
all components link to directly in their Vue data and I have yet to hit a
problem. I see huge writeups and design patterns all suggesting I really need
to use a state management library and I'm waiting for the day the penny drops
and I realise what a mistake I've made but so far everything just keeps
rocking along .... what am I missing?

(I get that there are some nice features like time travel debugging etc but
none of them seem outweigh the giant additional complexity of routing every
single state change through 1-2 extra layers.)

------
NanoWar
Nice, but does it have material?

~~~
uncle_iroh
[https://vuetifyjs.com/en/](https://vuetifyjs.com/en/)

~~~
NanoWar
I dont think this is available for vue 3. Sadly.

------
tor291674
No Nuxt 3 yet.

------
awinter-py
hooray <Suspense>

