
Vue v3.0.0-RC.1 - calibas
https://github.com/vuejs/vue-next/releases/tag/v3.0.0-rc.1
======
pritambarhate
For those who use Vue regularly, are there any breaking changes in Vue3? How
easy it is to upgrade from Vue2 to Vue3? Can one just upgrade the version in
package.json and start using vue3 for new components?

~~~
tqkxzugoaupvwqr
Vue 3 introduces breaking changes, e.g. filters and event bus ($emit, $on,
$off) are removed as far as I know. The Vue documentation team will release a
migration guide when Vue 3 is released.

~~~
hactually
Wait... How did they remove emit? Didn't they just make it an instance level
export, like props?

~~~
culturedsystems
It doesn't look like $emit is removed, just the functions to bind event
handlers on a component ($on, $off, $once): [https://github.com/vuejs/docs-
next/pull/167/files](https://github.com/vuejs/docs-next/pull/167/files)

~~~
IgorPartola
Why would they do that? Having an event bus can be incredibly useful.

~~~
mmis1000
And also incredibly messy, often result in non maintainable code.

For one shot small project, this is fine.

For a big complex project, If you see they already use this. You are mostly
already screwed.

~~~
IgorPartola
So the way I’ve been using it is pretty much for toaster notifications and
asynchronous updates that are sent from the server to the client. Any
component can subscribe to async updates on the shared bus and it will know
when a particular object has been updated and can choose what to do with it.
We don’t use the global store for all the objects because we deal with a lot
of large page-specific state. Toaster notifications are also really nice this
way: a lowly modal can send a top page “an error happened” notification
without having to do the plumbing for this through every page and component. I
don’t see any of that as an anti pattern.

~~~
mmis1000
And FB suffered from this due to undebuggable double notification bug because
it could be really hard to debug when any component can send any event to
other without any restriction.

They eventually moved to flux pattern due to this.

That said. It is possible to avoid such situation with strong lint rule. Like
you did here. But you can avoid it completely with ~~JUST DON'T~~ .

Why should a framework encourage people to do bad things?

~~~
IgorPartola
Um, no. That’s the whole thing is that the components don’t have to know how
it is implemented. They do _this.$bus.showError(‘Oops’)_. The bus
implementation under the hood sends a message to the top level App component
which in turn has the toaster notification implementation. I don’t need a
linter to make this work.

~~~
mmis1000
You do need a guide to prevent people from sending random unrelated message to
random handler hide deep inside some random component and emit again to other
random component.

It `is` fine to use it and only use on notification purpose, but there is no
way to enforce everyone to do so.

More of time it `will` be used in a terrible way that I just described
(something like .emit('login') and trigger some random function causing xhr
and emit notification everywhere).

You can't really assume everyone will use them nicely instead of resulting in
spaghetti code. It is not the case most of time.

The experience I learned from I start coding is. `Anything designed to be easy
to mess up will eventually mess up`

~~~
IgorPartola
Maybe this is what happens when you’ve been coding for years and years but the
thing is I was using this particular foot gun and it was working well. I don’t
need a framework developer to babysit me and prevent me from misusing a
feature. I know when it is a foot gun and I can treat it as such. It sounds
like the Vue devs simply removed this feature that was in some ways useful and
didn’t replace it with anything better. They removed it because it enabled
people to do something they didn’t like, which yes as a maintainer of a
popular framework is kind of your responsibility to be help people figure out.
But this is like if C removed the ability to dereference pointers because it’s
dangerous to do. Of course it’s dangerous, that’s why it’s so powerful. If you
can’t use it responsibly, that’s on you, not on the framework developers.

Basically, it’s not like they added a formalized way to create notification
buses. They simply removed a useful and widely used feature because they
didn’t like how people were using it. This is exactly the kind of shit that
killed Angular and honestly makes me reevaluate the trust I’ve placed in Vue.
Improvements are always welcome. Wholesale removing useful features without
providing an alternative, not so much.

~~~
mmis1000
Well, unlike angular, the event bus thing isn't integrated into vue self in
any way (and it don't need to). It didn't prevent you from use it if you must
need to either.

Moreover, You can polyfill it simply in one line. And it actually exist long
before the vue ever exist.

const { EventEmitter } = require('events').

It always make me wonder why was vue ever want to pack this into itself given
it did not use it as all.

------
mcjiggerlog
It looks like Vue 3's single file components share quite a lot in common with
Svelte.

As someone who has mostly only worked with React over the past few years - can
anyone shed any insight on how they compare? Advantages/disadvantages?

From a cursory look it looks like Svelte's greenfield approach has led to
cleaner code, though it might just be my React experience speaking.

~~~
kevmo314
Vue (and React) aren't compilers like Svelte.

The real advantage of using a compiler is that more complicated state changes
can be instrumented without hacky introspection, which is probably why Svelte
feels cleaner.

The big tradeoff is that it forces the use of the Svelte compiler. Which
doesn't sound all that bad until you want to use something like TypeScript and
realize that it's maybe a bit odd that a framework now has a tight grip over
what language/tooling is used.

It seems like Svelte just recently finished their TS support, but I tried
Svelte and while I liked the concept, the overreaching felt like at that rate
I'd rather use ReasonML or something because Svelte JS is technically not JS,
just looks a lot like it.

------
georgecalm
Yesterday’s thread on the RC release:
[https://news.ycombinator.com/item?id=23875541](https://news.ycombinator.com/item?id=23875541)

------
jedisct1
Is there a way to use Nuxt with Vue 3?

~~~
Semaphor
> We have started several branches (webpack5, next, vue3) and so far Webpack
> SSR support for Vue3 landed but not a precise timeline for beta testing at
> the moment. As many internals including vue-app and builder is to be
> rewritten from scratch to align with vue3. (of course with less breaking
> changes as much as possible)

\--
[https://github.com/nuxt/nuxt.js/issues/5708](https://github.com/nuxt/nuxt.js/issues/5708)

