The potential problem with mutability is when the same piece of state could be mutated by different parts of your code over a period of time - this would make things difficult to reason about for sure. However, when you enforce a state management pattern such as Vuex (with strict mode on) on your shared state, the system essentially protects you from those scenarios by enforcing mutations to be synchronous and structured in a way that reflects the intention of the code. This achieves a similar end result of the immutable style Redux uses, both in terms of scalability and testability, while retaining the familiar state assigning syntax.

The reason Vuex sticks with a mutable style is largely tied to how Vue's reactivity system works. Dependency tracking works most efficiently when state is mutated instead of replaced by entirely new values. By using a mutable style, Vuex retains Vue's performance characteristics (accurate component update boundaries with minimal over-rendering).

An advantage the Redux has though, is that state snapshots are cheaper than Vuex's due to immutable + structure sharing by design.

There are also some nice characteristics about Redux reducers being pure functions, but (in my opinion) they don't manifest as being significantly advantageous in the majority of applications.

Using something like Immutable.js brings yet another layer of indirection and in some cases extra conversion cost between immutable wrappers and raw js values, so it's a tradeoff even for React users, and in my opinion not a good fit for Vue apps.

Thanks for your feedback! We are currently working on a Cookbook that will feature recommended libraries and code examples for several use cases. In the mean time, you can ask on the forum.

In our case we need to do that. We have complete control over 3rd party code, and we rewrite stuff that misbehaves.

If that's the case, you are free and certainly able to fork Vue and remove the code that keeps it from mounting to body, or even better, submit a well-tested PR on github, along with a guide on how to deal with the problems of 3rd party-code competing for body.

We however have to focus our limited resources on supporting the needs of the larger community. As mounting to body can create problems that, as you explained, have to be worked around in 3rd-party code, we don't feel like it's a good idea to implement it as it will certainly introduce subtle bugs for many of our users that have to rely on 3rd party code they can't control.

As a sidenote, a little less agressive tone would help the conversation. And dan is awesome :)

Why we need access to body? First thing, it is programmatic access to setting and unsetting event handlers. It was extremely convenient to do it from the markup on a hash-routed website with a lot of views, especially if you want to map keyboard input for each route/view.

Another indispensable use case was to handle setting properties and hints for different screen readers. Some screen readers or accessibility tools effectively have their own mark-up formats, and dom addons, so effectively you have to develop a website for a certain browser set, AND, a specific screen reader.

Being able to programmatically set classes, lang, dir, and metadata properties (SEO meta, hints for ecommerce search engines) with router mounted on body was quite convenient too.

Finally, having document.body DOM object being rewritten from Vue's DOM also worked well with routable sites where a view/route has a code that does something to the body DOM object that is specific to that route AND/OR a reactive data in it. I'd say, this is the most hard thing to implement when the upstream code from Vue and 3rd party Vue modules has no awareness of such possibility.

Although i don't recommend overwriting the body, you can do something like this. https://jsfiddle.net/1u1h4e1k/1/

You could also get the innerHTML of the body to replace the body as is.

With Vue 2.5, which is aimed for end September to early October. We will also provide full documentation around the unit testing subject.

We are currently in the final code review and working on the guide to go with it. We plan on releasing it with Vue 2.5, which we currently think will be released in the beginning of october.

Vue will not 'move' to Typescript, but the 2.5 release (in the beginning of October) will improve Typescript support a lot.

We are bringing updates for TS in Vue 2.5, this will make it even better and easier for you to use TypeScript:

https://github.com/vuejs/vue/pull/6391

Thkx for answer... We didnt want to move NG2 cause of TS, so it's a good news that VueJS is not going to impose it :)

Custom tag names in the templates are treated as components. If the corresponding component is not found, Vue will warn you. It would be difficult to get around this IMHO.

Thanks, but I meant why Vue does not use that custom tag name in build process, is it because of better support in old browsers? or something similar. Any thought on my second question ?

I think you are talking about implementations of the web components standard, and libraries like polymer that use it.

Currently web components are an emerging standard and we don't feel that the case is settled enough to commit to it. Also, there's still open questions about how certain features of Vue could be implemented in web components as well as we have them in Vue itself.

But with vue-custom-element, you can transform Vue components into web components, so it's possible if you really want to.

I'll answer as if this question for myself (I hope the question is not just for Evan, otherwise I'll look like an idiot 😂) I don't have a regular workspace as I just move to different desktops when I need to code at work. The only constant is my 13" laptop. I use Spacemacs (Emacs + Vim) as my editor and from time to time Vim in the console These days, all we need is a Browser 😁. But, I do use slack and discord a lot. About native applications, I really like 1Password and Alfred

I use VSCode alot of the time

My workplace looks like a house, because I'm a (mostly remote) consultant. 😄 I use VS Code personally, but whatever makes you productive is great!

Thorsten is a machine. Every time I've tried to meet him in real life, something comes up, so I'm not even 100% sure he's human. I can confirm he's 100% German though. 😛

I'm open to a skype session to prove my human-ness if that's necessary, chis ;)

Good point Thorsten, sure will love to give back, will keep on problems I can help and skype still not trustable can be anything playing on webcam stream ;)

Sounds great! 🙂 A good place to start might be this discussion making plans for Vue CLI 3.0. Or on the webpack template, you could open an issue to discuss a specific feature/enhancement.

That's pretty cool to hear! I hope, you can help us improve the existing The best way is to either open small PR for every improvement that you have or open an issue listing the improvements that you want to make so we can discuss it

Thanks for the interest to contribute back! We are in fact planning an upgrade for vue-cli and we'd love your input here: https://github.com/vuejs/vue-cli/issues/589

I have similar suspicions, though I was unable to confirm them so far.

Another theory of mine is that egoist really is a group of people sharing the same personality, so who knows?

But to be serious, his output and creativity really is nothing short of amazing and he is a great source of inspiration to me.

Don't blow it please, now I have to tune the algorithm

Evan, while you are at it, please add a NSFW filter for anime tweets - I live in constant fear of my boss seeing underpants on my work screen.

Hm, we haven't found a lot of problems with devtools even in big apps, but there are of course some scenarios where performance can become a problem, mostly with very large datasets or high frequency commits to the store, e.g. from a socket.

If that breaks the devtools for you, chances are it will also be problematic for your app's general performance, at least on slower devices. so it might be worthwhile to cache incoming socket messages in an array and do bulk commits with a throttled function.

Open a thread on the forum and we can discuss this further.

That also counts for the second questions, which I don't think I can answer here with the information provided.

I think currently the OSS community is maturing across the board, there are many great devs out there that have done a fantastic job at promoting the value of OSS.

It can however be difficult, and lots of our time is unpaid and completely voluntary. So the main thing i can say is be nice, there is nothing more frustrating than being had a go at.

Building a friendly community and being friendly in that community, is key in my opinion.

Dan Abramov of React did an excellent job explaining why you shouldn't render/mount to body: medium.com/@dan_abramov/two-weird-tricks-that-fix…

Facebook may have its (good) reasons for that, even more so being a big company that may want to protect itself from others (as patent fights in courts are very costly).

I believe Vue's ecosystem is broad enough for every enthusiastic developer to contribute their part. Depends on how familiar you are with Vue, you can choose to contribute to the core Vue.js framework itself as a builder, or the Vuejs.org website as a user, among others.

Somewhat related: How to Contribute to Open Source, an excellent guide by GitHub themselves https://opensource.guide/how-to-contribute/.

The best way to contribute to any project is to look at issues and check for bugs. Some of them are simple. Sometimes projects have a special label for issues that are good as a first-time contribution. They're usually easier than other bugs and they may be comments with some pointers Also, a very good way to contribute to a project is by helping with the docs. It may sound meaningless but docs are super important and you really learn much by helping out in docs. I know Chris would love some help at vuejs/vuejs.org 😄

We quite often receive ideas about additions to the template language that make some things a bit easier, save some keystrokes, or add a bit of nice "magic".

Most of the time, we decline those requests because we want to keep the template-specific syntax (which people have to learn and memorize) small, and rely on Javascript expressions wherever possible.

This keeps API surface small and keeps the template compiler efficient and easier to maintain.

I would say right now, very small syntax sugar feature requests are the most rejected ones.

Seems no one would like to touch this topic. :(

Evan already answered similar questions. Take a look at:

• hashnode.com/ama/with-vuejs-team-cj7itlrki03ae62w…
• hashnode.com/ama/with-vuejs-team-cj7itlrki03ae62w…

Thank you, Guillaume. I will take a look.

Except that filters are still there ;) https://vuejs.org/v2/guide/filters.html

We do actually support filters in Vue 2. We added them back for v-bind and moustache interpolations. If you want to read the long discussions we have about this, you should be able to find the issue on Github quite easily by searching filters 2.0

At the moment, we're very careful about adding new features, we take into account the amount of code needed to make it work because it means a bigger lib and also more code to maintain. We also think about how it affects existing features. For example, we try to avoid adding multiple ways of achieving the exact same simple thing because it may be confusing for newcomers. So we try to keep Vue easy to use but powerful by providing warnings whenever possible (that are stripped off in production mode) and by keeping the API surface small. Although it may be a bit too large for v2 at the moment

Ream is a small framework similar to nuxt, but much less opinionated, and it also can generate static sites like nuxt. It's maintained by the fabulous @egoist, on of our core constributors and one of the most creative and productive contributors to the Vue ecosystem out there.

But for a static site, sometimes other tools, that don't rely on Vue SSR, as a good or even better fit. Our Website is done with Hexo, for example

If you don't need your site to have Vue components, you can use other tools like Hexo, Middleman, Hugo. If you want to use Vue component, I think Nuxt is the best solution out there to build a static site. You can, of course, build the generator yourself, it would be a nice way to learn SSR (https://ssr.vuejs.org)

We don't like to say that we are competing. Every framework/library has it's use case. However, we do like to say we always strive to improve, and learn from the surrounding ecosystems.

There's no plans to "compete". We have friendly relations with maintainers and contributors of many of the other popular framework, and we strongly believe that we have just as much to learn from them as they can hopefully learn from us.

It's not a game we want to "win" - we just want to provide a useful tool for people to work with and enjoy, and we also believe that the most important thing to consider is "the right tool for the right job" - and there are certainly jobs that other frameworks are just as well, or better suited to do that Vue.

I'd suggest starting with the tests. While Vue's test coverage is 100%, I'm sure there's room for improvement there. Reading through the test cases is also an excellent way to learn about Vue's internals and APIs.

Make sure to read the Contributing Guide, especially the section on project structure. It's also necessary to familiarize yourself with the development tools used (Flow, rollup, webpack, jasmine, karma...)

I also have plans for an in-depth guide on how to read and understand Vue's source code, but that will take some time to finish. :)

You can start looking at the test suite and try improving it. It's a great way to learn more about the API and the internals!