
Vue 3 Beta - dyslexit
https://github.com/vuejs/vue-next/releases/tag/v3.0.0-beta.1
======
dang
There was a big thread a few months ago about these features:
[https://news.ycombinator.com/item?id=21391381](https://news.ycombinator.com/item?id=21391381).
Is there significant new information [1] since then? If not, this is
substantially the same story and we should wait for the actual release [2],
since there will certainly be another big thread then.

[1]
[https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...](https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=by%3Adang%20%22significant%20new%20information%22&sort=byDate&type=comment)

[2]
[https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20incremental&sort=byDate&type=comment)

------
ehsankia
Useful link with more info about what's in Vue 3

[https://madewithvuejs.com/blog/vue-3-roundup](https://madewithvuejs.com/blog/vue-3-roundup)

~~~
ccktlmazeltov
mods you know what to do

~~~
dang
How is this topic different from
[https://news.ycombinator.com/item?id=21391381](https://news.ycombinator.com/item?id=21391381)?

------
thrwn_frthr_awy
For someone with little experience with the modern front-end development, what
are the reasons to choose Vue over React or vice-versa? Are they both just
different flavors of the same patterns or is there a philosophical difference
in the two?

~~~
neya
They're pretty similar, but Vue enforces structure and good patterns early on
in the development cycle. React gives you more freedom.

I've been a consultant using both for over 3 years now, full time and I can
tell you I just use Vue these days. Everything is more readable, well-
organized when the project is finished. You could do the same with React too,
but it puts the mental burden on you.

I think performance-wise as well Vue is faster (it used to be). Not that it
matters a lot. But, if you are a company, it's easier to find React developers
than Vue developers.

Also, in big company environments, teams using React always end up in messy
code that's not maintainable because of the freedom the framework gives as
opposed to teams using VueJS.

So you need to pick the one that fits your use-case.

~~~
kilburn
> Also, in big company environments, teams using React always end up in messy
> code that's not maintainable because of the freedom the framework gives as
> opposed to teams using VueJS.

This is debatable...

> But, if you are a company, it's easier to find React developers than Vue
> developers.

... and this is probably one of the reasons why you've found more "messy"
projects in React than in Vue.

In other words: people who know what they like (and hence probably do a good
job with it) pick either Vue or React. Teams that don't know pick React
because it is more widespread, easier to hire for, etc.

------
kohtatsu
Recently did some framework shipping and wanted to plug Svelte despite not
having deployed it yet.

The approach of using a compiler instead of a framework makes a lot of sense
and I personally believe it's the best way forward.

I recommend watching the talk here;
[https://svelte.dev/blog/svelte-3-rethinking-
reactivity](https://svelte.dev/blog/svelte-3-rethinking-reactivity)

~~~
noway421
Apparently scheduling/skipping renders is hard with this approach, since
render function gets compiled away and becomes hardcoded DOM calls in the
result bundle. React with Suspense takes a different approach here and allows
to suspend renders, skip slow renders (I think) till they're ready, prioritise
keyboard input, etc.

It's essentially a similar tradeoff as in AOT vs JIT. Even though AOT brings
the compilation step forward, JIT would have much more runtime context for
better performance.

~~~
pier25
Yeah, but in truth you might never need Suspense when using Svelte.

Reacts needs Suspense because it's quite slow and bloated in comparison.

See this video Rich Harris made when comparing a visualization use case:

[https://twitter.com/Rich_Harris/status/1200807516529147904](https://twitter.com/Rich_Harris/status/1200807516529147904)

------
mikece
How significant is the adoption of TypeScript? Angular was built with it;
React now recommends it too. Is this really the ratification of TypeScript as
THE front-end language?

~~~
james-mcelwain
It's important to remember that there are still a lot of front-end folks who
aren't interested in application engineering, but still might find these
frameworks useful. For those kinds of people, static typing is a harder sell.

For anyone else, yeah, they should probably be using TypeScript in 2020.

~~~
ct520
I adopted typescript shortly after it’s release and went through growing pains
in the first couple years. I don’t use it often now. And it ALWAYS comes back
to bite me in the butt when doing any decent sized project. If I had to guess
time spent fixing things that would have been caught out weights the cons of
using typescript

~~~
tnorthcutt
Forgive me, but I’m having trouble parsing this. Are you saying you recommend
using Typescript, or not?

If yes, why do you not use it often now?

~~~
sk0g
Sounds like they think time spent fighting the language outweighs any pros TS
might have, and thus aren't recommending it.

Edit: read it wrong, nevermind.

~~~
mceachen
I read the exact opposite: that they regret not using typescript for non-
trivial projects because tsc would have prevented dumb mistakes due to a lack
of types.

~~~
ct520
Correct. Small project turns into a bigger project, I think I can get through
some complicated piece and BAM. I'm fighting silly typing issues and writing
tests for stuff I would never have to do if I used typescript. While majority
of my stuff is not that complicated, it seems there is always something.

I also wear a bunch of hats. So retaining all the new knowledge gets a bit
hard. Sometimes its easier for me to fall back to patterns I used over the
past 20 years of full stack development. If I had the time I would use
typescript everywhere.

------
habosa
The link is to a GitHub release page with no release notes. Can someone point
me to an authoritative 3 vs 2 comparison?

~~~
aembleton
[https://madewithvuejs.com/blog/vue-3-roundup](https://madewithvuejs.com/blog/vue-3-roundup)

------
Townley
Anyone have details on what it means that Vur 3 can “more easily target
native?” Is there something about Vue that’s been keeping Vue-powered
Nativescript, Ionic, or Quazar from having feature parity with React Native?

~~~
spartanatreyu
I have a feeling it's about the renderer being compartmentalised and the
potential for a native renderer to be used with vue 3 instead.

------
montroser
The new Composition API definitely looks interesting. But it's also kind of a
shame that there are now two very different ways to write the same
functionality, both blessed by the framework.

~~~
neovive
I think the original plan was to eventually phase out the Options API, but the
community pushed back during the first RFC phase resulting in the dual API
solution.

Although the benefits of the Composition API are clear-cut, the Options API is
beloved by the community for its ease of use and clarity. For me personally,
it will be hard to switch since I'm not a heavy user of mixins and I don't
venture too far beyond simple components. However, I still need to learn the
Composition API in more detail so I can make a more informed decision. Evan
and the Vue team worked very hard on v3 and I trust them to make the right
decisions.

~~~
keithnz
I liked the options API...

what I found is the composition API is actually nicer to deal with not even
considering mixins. Because things are grouped together you don't end up
moving around your files so much so it ends up being quicker.

------
third_I
Easter egg for us:

> _“Build a Hacker News Client with the Vue 3 Function-based component API,
> Vuex and vue-hooks by Coding Garden with CJ on Youtube (video)”_ [1]

No idea if that video is good but 146:0 liked it.

Edit: comment mentions that “Building of Hacker News Client starts at 33:18”

[1]: [https://youtu.be/g9bSmxnx-O0?t=318](https://youtu.be/g9bSmxnx-O0?t=318)
(starts at 5:18)

------
IgorPartola
Is the Composition API going to be the only way to do things in some future
version of Vue? I see why you’d want the elegance of it but also it seems to
trade having to know which properties _this_ has for having to strictly order
property and method declarations. It’s like we went from declarative to
procedural components and I am not sure I like it.

------
bratao
I´m interested in benchmarks, but could not find any. During the development
they promised some serious optimizations.

~~~
leeoniya
yes, it should be a lot faster: [https://github.com/krausest/js-framework-
benchmark/pull/697](https://github.com/krausest/js-framework-
benchmark/pull/697)

~~~
pier25
You can see the results here:

[https://krausest.github.io/js-framework-
benchmark/current.ht...](https://krausest.github.io/js-framework-
benchmark/current.html)

Yeah it's significantly faster and smaller than Vue 2.

------
csytan
For folks interested in the new Composition API, the RFC is a good read:
[https://vue-composition-api-rfc.netlify.app/](https://vue-composition-api-
rfc.netlify.app/)

~~~
keithnz
I'd also suggest
[https://www.youtube.com/watch?v=V-xK3sbc7xI&t=2319s](https://www.youtube.com/watch?v=V-xK3sbc7xI&t=2319s)

------
buremba
I really wish that they make the transition from 2.0 as seamless as possible.

------
natch
This repo needs a readme that says what Vue is.

