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.
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.
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.
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.
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).
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.
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?
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.
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.
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.
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.
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.
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.
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
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.
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
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:
> ... 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.
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
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.
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.
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.
[+] [-] superasn|7 years ago|reply
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
I hate this misconception and wish it would just go away.
[+] [-] eksemplar|7 years ago|reply
But maybe I just sucked at vue.
[+] [-] jetti|7 years ago|reply
[+] [-] pvorb|7 years ago|reply
[+] [-] yuchi|7 years ago|reply
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
[+] [-] aaaaaaaaaab|7 years ago|reply
Lol. Writing JS libs is not research.
[+] [-] tinyvm|7 years ago|reply
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.
[+] [-] atentaten|7 years ago|reply
[+] [-] TekMol|7 years ago|reply
So you do...
...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
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
[+] [-] deskamess|7 years ago|reply
[+] [-] beaconstudios|7 years ago|reply
[+] [-] petilon|7 years ago|reply
[+] [-] pier25|7 years ago|reply
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
[+] [-] pier25|7 years ago|reply
- 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
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
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
[+] [-] diminish|7 years ago|reply
[+] [-] BtM909|7 years ago|reply
[+] [-] armaxt|7 years ago|reply
[+] [-] pier25|7 years ago|reply
But you can indeed create small inline components in .vue files.
There are different approaches: https://codewithhugo.com/writing-multiple-vue-components-in-...
[+] [-] jgrpf|7 years ago|reply
[+] [-] deltron3030|7 years ago|reply
No problem: https://www.youtube.com/watch?v=l3GHggI3_z8
As you can see, the're quite a few nested components in a single .vue file.
[+] [-] pdkl95|7 years ago|reply
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
[+] [-] douglaswlance|7 years ago|reply
[+] [-] resource0x|7 years ago|reply
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
[+] [-] Normal_gaussian|7 years ago|reply
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
[+] [-] Zooper|7 years ago|reply
[+] [-] acemarke|7 years ago|reply
[+] [-] crooked-v|7 years ago|reply
[+] [-] joshschreuder|7 years ago|reply
[+] [-] baybal2|7 years ago|reply
[+] [-] rightnow|7 years ago|reply
[deleted]
[+] [-] welanes|7 years ago|reply
[+] [-] orf|7 years ago|reply
No matter how awesome you think whatever framework is, this is a terrible, terrible experience.
[+] [-] usaphp|7 years ago|reply
[+] [-] lobo_tuerto|7 years ago|reply