top | item 18474745

Vue 3.0 Updates [slides]

292 points| mxstbr | 7 years ago |docs.google.com | reply

123 comments

order
[+] superasn|7 years ago|reply
I think the best part about Vuejs is that how simple it is and everything just works!

A vue component is still as simple as {template: 'hi'}. You don't need webpack or any transliteration for it to work. Just drop the script tag like the good old jQuery and it's working! No wonder it was so easy to switch to it.

Transition from vue1 to vue2 was really simple. I'm sure the same will be true for v3.

[+] whyevenbother|7 years ago|reply
Maybe it's the constant React vs Vue articles that make me suspicious, but if you are referring to React when mentioning webpack / transliteration, i'd like to mention that you don't need them for React neither. It can be resumed to a simple script tag as well.

I hate this misconception and wish it would just go away.

[+] eksemplar|7 years ago|reply
Having started with vue, and now playing with react, I’ve found myself often thinking “this is so much simpler”.

But maybe I just sucked at vue.

[+] jetti|7 years ago|reply
I ended up taking over a Vue 1.x codebase and tried to update it to vue2. We used single file components and it was a nightmare trying to upgrade. I spent a good two weeks trying to upgrade and eventually just stopped because it was just taking too long. There were a lot of breaking changes from 2.0 to 1.0, especially with the way events were handled. Now, I will admit that the person who wrote the vue 1.x version did not write idiomatic vue and that caused some problems in updating. A lot of the components we used were also not updated to vue 2.0 and, of course, they were using deprecated features. That meant I had to search for something similar to replicate the existing functionality.
[+] pvorb|7 years ago|reply
People who found a way to overcomplicate their toolchain for React will also find a way to do the same for vuejs.
[+] yuchi|7 years ago|reply
I'm very happy to see React and Vue influence each other. They definitely are the highest quality frameworks out there and having two different research teams only improves the overall quality of the ecosystem.

I'm a React fan, yet I really applaud all the nice stuff which is coming in Vue 3. Well done.

[+] keerthiko|7 years ago|reply
Similarly, I'm a Vue fan, and them having to keep up with and learn from React's moves keeps it solid. I am very happy with recent updates to Vue and their framework is a pleasure to develop with (the tradeoff being a certain level of power that React provides that Vue cannot obtain, but it's plenty).
[+] aaaaaaaaaab|7 years ago|reply
>research teams

Lol. Writing JS libs is not research.

[+] tinyvm|7 years ago|reply
3.0 is a huge milestone for vue.

Currently the architecture forces you to import the Vue object entirely , has Vue under the hood isn't really modular...

With 3.0 Vue has taken the typescript way and is using packages , similar to angular , it looks absolutely awesome to work with now.

I really hope class based components will be supported natively without compiling or transpiling.

Working "out of the box" has always been part of Vue philosophy , I really hope this continue.

This is really a big release , but it's still sad to see the 3.0-alpha branch is not visible on GitHub , i really would have loved to have a look at it.

[+] TekMol|7 years ago|reply
My feeling is that most people who use Vue or React only need a template engine. Typical use case: You have an array of objects and a template how each object should look like.

So you do...

    <div id=users>
     <a v-for="user in users" :href="'user/'+user.id">
      {{ user.name }}
     </a>
    </div>

    <script>
     let userList = new Vue({
      el  : '#users',
      data: { users: users }
     })
    </script>
...to make Vue render the list of objects.

This is the only thing I ever use these frameworks for. Everything else I think I can implement in a better, leaner way myself. So I wonder if I should switch to a template engine instead.

What is the next most basic/common usecase for Vue?

[+] gbuk2013|7 years ago|reply
One should use what is necessary and no more. If server side templates work for you - great.

My rule of thumb: if I need to do more then a trivial amount of DOM manipulation then I will use a framework, because otherwise I will end up writing my own anyway (which I can easily do) which wastes development time.

For projects with several developers a framework can help maintain common coding style and reduce ramp up time for new hires.

Also, good frameworks come with nice tooling that make for more productive development. For example, Vue + Vuex and the Vue browser plugin are great for inspecting the state and observing state transitions.

An example of my use case: I have a non-SPA app that receives various data via Websocket and the view is immediately updated. Several components take this same data and render it in different ways. Vue is excellent for this. I still use templating on the server side for the basic page structure.

[+] dpau|7 years ago|reply
If you're just rendering HTML, you might as well do it on the server with your choice of language/framework. The power of Vue and other Javascript frameworks is in their reactivity and the ability to create extremely powerful interfaces.
[+] deskamess|7 years ago|reply
Not sure if your use case includes automatic rendering (new/delete/mods) when the underlying data changes. If it can be done automagically (via unique id in the data) that is a big win (aka, code I do not have to write). Things like shadow DOM et al, are not something I want to implement or maintain.
[+] beaconstudios|7 years ago|reply
as a React developer, SPAs in general are overused. Most LOB apps could (and should) still be written in a backend templated language. SPAs should be reserved for applications (or even individual components) with advanced interactive features, ie a proper web app.
[+] pier25|7 years ago|reply
Some people maybe, but I doubt it's "most" people.

The point of using Vue is data-binding with reactive models and components.

For your use case I agree Vue is overkill. A templating engine should be enough.

[+] aikah|7 years ago|reply
You could use string tags. The only thing that is really needed is a DOM diff library to make UI updates bearable. The rest can be completely handled with a basic MVC architecture.
[+] pier25|7 years ago|reply
Vue 3 is a massive new update:

- TypeScript

- Double the performance

- Half the size and memory consumption

- New reactive system that supports classes a la MobX

- Class based components

I've been using Vue for a couple of years and I'm very excited about this new release.

[+] spectaclepiece|7 years ago|reply
It appears that there are similarities in Vue 3.0 with Aurelia, at least on the surface. Things like class based components, proxy-based observer mechanism* and the move towards typescript all remind me of Aurelia.

Been using Vue 2.0 for personal projects and Aurelia for a big work project over the past year and I have to say I am very happy with both. Personally I prefer the single file components in Vue but the class based style of writing them in Aurelia. Seeing these two things converge in Vue 3.0 together with the performance improvements looks very promising.

*Not sure that under the hood Vue 3.0 works the same way as Aurelia but the mentioned points in the slides lists array index / length mutation and later the observable function are familiar from Aurelia.

[+] bpicolo|7 years ago|reply
The Typescript support is by far the thing I'm most interested in. Lack of useful Typescript support is, for me, the only downside of Vue right now, and it's a big enough downside for me to use React instead of Vue in a lot of cases.

Do you reckon we'll ever see Typescript support in the non-jsx templates? I do really like vue templates for e.g. if-conditionals. I really don't like using ternary operators for template logic. And then the alternative being to hoist things out of the single JSX template breaks make code less linear to read which kinda sucks

[+] bsaul|7 years ago|reply
to me the biggest downside was how vuex and typescript didn’t work well together by default. You had to rely to adding a few plumbing functions, and that felt really like dirty patching.
[+] diminish|7 years ago|reply
Vue has a strong leader - and that is promising.
[+] BtM909|7 years ago|reply
Does someone have the talk (if there's one) which used this deck as well?
[+] armaxt|7 years ago|reply
How about the ability to create multiple components in the same .vue file? for instance I need to define a sub-component that will be used only inside my component, this is easy in React but with Vue I have to create another file to define this sub-component, this makes the project management becomes harder as the project grows
[+] jgrpf|7 years ago|reply
This is totally possible. You can create a sub component, register and use it in the same file as the parent component. Though not really recommended you can even do this:

  ...
  components: {
    "inline": {
      template: `
        <h1>My inline subcomponent</h1>
      `
    }
  }
  ...
[+] pdkl95|7 years ago|reply
> ... implementation re-written from the ground up

Rewriting a big project from scratch is often used as something to brag about: "Look at all the hard work we accomplished!". Except in software what matters is correctness and efficiency, not the age or the code or the size fo the rewrite. Rewriting "from the ground up" is throwing away years of bugfixes[1].

Maybe this new version is fine; I'm only suggesting that big re-implementations should be seen as an unknown risks, and that "carefully refactored problematic areas of the code" is something worth bragging about on a slide.

[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

[+] bpicolo|7 years ago|reply
When your project is such a size that a single person can keep it all more or less in their head (in this case, Evan), clean slate rewrites end up being fairly efficient. It's a much different case than 20->200->2000 devs scale applications. It's vastly more easy to develop something from scratch if you'd put a lot of thought into it over time
[+] douglaswlance|7 years ago|reply
Vue itself is less than 10,000 lines. It's not a huge project.
[+] resource0x|7 years ago|reply
> Rewriting a big project from scratch is often used as something to brag about

Not necessarily. Sometimes it means "our old code was such a mess no one could make any sense of it" :)

[+] agumonkey|7 years ago|reply
Happy to see this project move forward, but I get surprised when I read 100% speed improvement, since it was already super fast. I wonder how they manage.
[+] Normal_gaussian|7 years ago|reply
Slide 20 "flow -> typescript" is under making it more maintainable - does anyone have any thoughts on this?

I use flow because I am interested in soundness, have had a few issues with it, but nothing has suggested to me that typescript is more maintainable.

[+] rawrmaan|7 years ago|reply
TS is more popular and has a bigger ecosystem. It could enable more contribution to the project.
[+] crooked-v|7 years ago|reply
I'm happy to see another framework moving to Typescript.
[+] joshschreuder|7 years ago|reply
In case there are any newcomers, it's probably worth noting that just the core framework is written in Typescript, and compiled to normal JS - you are not forced to use Typescript in your own Vue code unless you want to.
[+] baybal2|7 years ago|reply
Any news on native support for fragments?
[+] welanes|7 years ago|reply
.
[+] orf|7 years ago|reply
FYI it takes 5.16 seconds to download the 5 megabytes of vendor JavaScript needed to view your landing page from a cold cache (and 2 for your app itself), not to mention the 6 seemingly needless Firebase API calls or the fact you're running the development version of the Firebase SDK.

No matter how awesome you think whatever framework is, this is a terrible, terrible experience.

[+] usaphp|7 years ago|reply
Scrolling experience (I am on iPhone) on your site is absolutely horrible