New Features in Vue 3(vueschool.io)
vueschool.io
New Features in Vue 3
https://vueschool.io/articles/vuejs-tutorials/exciting-new-features-in-vue-3/
110 comments
I'm a complete React fanboy and fully engaged in the React ecosystem, but I'd like to speak up in Vue's defense here.
Yes, there's some obvious copying going on here, but this is not a bad thing! There's been a lot of cross-pollination and inspiration between the major frameworks and ecosystems.
While I haven't deeply inspected the exact details of the new Vue APIs, my understanding based on discussions is that the Vue team has heavily adapted the hooks APIs for a more Vue-idiomatic approach. This includes things like removing the need for the call order limitation, only calling them once on setup, making use of Vue's reactivity, and so on.
Those changes fit well into Vue's stated focus on ease of use and handling a lot of behavior automatically.
This gives the Vue community a chance to benefit from some of the same concepts and improvements that the React team has described for hooks, while staying with their same toolset.
I'm entirely happy with React and have no plans to switch, but there's plenty of reasons for folks to choose Vue (and similarly, each of the other frameworks). I gave a list of some reasons why you might pick each of them a while back on Reddit [0].
[0] https://www.reddit.com/r/javascript/comments/avsuei/react_vs...
Yes, there's some obvious copying going on here, but this is not a bad thing! There's been a lot of cross-pollination and inspiration between the major frameworks and ecosystems.
While I haven't deeply inspected the exact details of the new Vue APIs, my understanding based on discussions is that the Vue team has heavily adapted the hooks APIs for a more Vue-idiomatic approach. This includes things like removing the need for the call order limitation, only calling them once on setup, making use of Vue's reactivity, and so on.
Those changes fit well into Vue's stated focus on ease of use and handling a lot of behavior automatically.
This gives the Vue community a chance to benefit from some of the same concepts and improvements that the React team has described for hooks, while staying with their same toolset.
I'm entirely happy with React and have no plans to switch, but there's plenty of reasons for folks to choose Vue (and similarly, each of the other frameworks). I gave a list of some reasons why you might pick each of them a while back on Reddit [0].
[0] https://www.reddit.com/r/javascript/comments/avsuei/react_vs...
Copying is a harsh word IMO. Vue has been liberal and open in quoting prior art, particularly from the React ecosystem. For example vuex[0] docs, actually quotes Dan Abramov regarding flux implementations for state management.
[0] - https://vuex.vuejs.org/
[0] - https://vuex.vuejs.org/
Programming and open source is a massive ecosystem of making use of prior art and incorporating diverse ideas to make alternative, better, or more robust abstractions. That's the whole beauty of it. Very few things are entirely new.
More on the relationship between hooks and the proposed Composition API: https://vue-composition-api-rfc.netlify.com/#comparison-with...
> a wonderful job incorporating actual CS concepts like algebraic effects into their framework.
What does "actual CS concepts" event mean? This is the first time in my life that I've heard about algebraic effects.
If I am understanding your comments, the implication seems to be react is implementing concepts that elevate the tool while vue goes around in circles to make an alternative syntax.
I don't even agree that the react team has done a good job with implementing a clear concept for their framework. Things like Elm have done a much better job of that. Granted that's a lot easier to do when they don't have to force themselves to deal with js directly.
But even then, why is react implementing hooks not bad, but vue implementing them is? There's a reason why react made the switch, and some of those advantages also apply in vue. These changes aren't just made to follow trends.
What does "actual CS concepts" event mean? This is the first time in my life that I've heard about algebraic effects.
If I am understanding your comments, the implication seems to be react is implementing concepts that elevate the tool while vue goes around in circles to make an alternative syntax.
I don't even agree that the react team has done a good job with implementing a clear concept for their framework. Things like Elm have done a much better job of that. Granted that's a lot easier to do when they don't have to force themselves to deal with js directly.
But even then, why is react implementing hooks not bad, but vue implementing them is? There's a reason why react made the switch, and some of those advantages also apply in vue. These changes aren't just made to follow trends.
There's been an unfortunate trend in the JS world where a lot of frameworks are created, but without any real meaningful sense of progress, resulting in a sense of going around in cycles in various "reskins" with different syntax and conventions, all round some kind of core MVC idea.
When I say "actual CS concepts" I mean things that have been broken down into it's core using a suitable mathematical model. This is ultimately a much more suitable way bo build tools used by engineers.
My personal concerns is that Vue to me is mostly just a reskin with new syntax on things that are already in React. Hooks become the "composition api". Redux becomes VueX. Is this necessary?
Could VueX just have been an alternative to Redux, like MobX is?
Could we just have implemented a Webpack-loader to put styles and react components together?
Some people don't like that React uses `className` instead of class. Is `v-bind:class` and various `@` notations really so much better we can justify a whole new ecosystem?
So roughly - Vue provides fragmentation in the frontend ecosystem. I like competition - but what does it really offer that justifies it? I don't get it, and now what they have been working on is just catching up to React.
When I say "actual CS concepts" I mean things that have been broken down into it's core using a suitable mathematical model. This is ultimately a much more suitable way bo build tools used by engineers.
My personal concerns is that Vue to me is mostly just a reskin with new syntax on things that are already in React. Hooks become the "composition api". Redux becomes VueX. Is this necessary?
Could VueX just have been an alternative to Redux, like MobX is?
Could we just have implemented a Webpack-loader to put styles and react components together?
Some people don't like that React uses `className` instead of class. Is `v-bind:class` and various `@` notations really so much better we can justify a whole new ecosystem?
So roughly - Vue provides fragmentation in the frontend ecosystem. I like competition - but what does it really offer that justifies it? I don't get it, and now what they have been working on is just catching up to React.
The hook that got me started on Vue was being able to straight swap with a previous two way dom binding library (rivets.js) and continue from there, I've found Vue to be incredibly easy to pick up, and very productive now I'm up to speed.
Well, I started with Angular and couldn't make any sense of it. It had two versions with huge differences between them and React offered a more concise path for learning.
But I found JSX hard to read and there was no consensus on how to write CSS and some people were saying that it was ok to use inline styling. WTF? The web design community have been telling me the opposite for years!
Then I started working with Vue and everything fallen in place: no deprecated lifecycles, CSS into style tag and easy to read markup with no Array.map() returning HTML tags.
Fragmentation is bad, but is nice to have a balanced option between extremes.
But I found JSX hard to read and there was no consensus on how to write CSS and some people were saying that it was ok to use inline styling. WTF? The web design community have been telling me the opposite for years!
Then I started working with Vue and everything fallen in place: no deprecated lifecycles, CSS into style tag and easy to read markup with no Array.map() returning HTML tags.
Fragmentation is bad, but is nice to have a balanced option between extremes.
[deleted]
Preferred syntax should be enough, but here's a couple more differences:
- Vue has a set of core libraries (Vuex, vue-router, etc) maintained by the same org.
- Single file components with scoped styling out of the box.
- Vue integration as a standalone runtime is a little easier than React (unsure about this one).
You can read more about the differences here:
https://vuejs.org/v2/guide/comparison.html#React
I couldn't find any official comparison documentation from the React docs, though.
- Vue has a set of core libraries (Vuex, vue-router, etc) maintained by the same org.
- Single file components with scoped styling out of the box.
- Vue integration as a standalone runtime is a little easier than React (unsure about this one).
You can read more about the differences here:
https://vuejs.org/v2/guide/comparison.html#React
I couldn't find any official comparison documentation from the React docs, though.
Wouldn't mind some other opinions on this but having used Mobx a lot in the past and starting to look at Vuex for current employer it's not looking enticing in comparison.. Mobx will work with Vuejs and I'm reading about a lot of people who have switched from vuex and been very happy. Considering just jumping in with Mobx and the bindings..
My and many others dev environments lean heavily on Vetur and it.. Is plagued with various issues in various releases. JSX/TSX JustWork™ while SPCs are okay sometimes but other times are found wanting..
My and many others dev environments lean heavily on Vetur and it.. Is plagued with various issues in various releases. JSX/TSX JustWork™ while SPCs are okay sometimes but other times are found wanting..
> Single file components
Honestly I think this is a step backwards. How many components my "component" is built out of should be an implementation detail.
Honestly I think this is a step backwards. How many components my "component" is built out of should be an implementation detail.
You're misinterpreting what an SFC is, it's just something like the following:
<template>
<!-- A mustache-like template -->
</template>
<script>
// JS, TS, or whatever
</script>
<style scoped>
/* CSS, LESS, SCSS or whatever */
</style>
That's not what I'm saying. What if I have a child component I don't want to put in a separate file? What if I want a child component defined as a closure inside my parent component? What if I want one file that exports many components? React makes no judgements here -- it's completely up to me to decide what's best for my application.
I don't think anything would stop you from creating multiple components in a file using 'Vue.Component' and a template string.
I've never remotely wanted anything similar to this in Vue, but I have seen what you're talking about used in React, mostly for component wrappers to encapsulate logic. It's not something I like using or seeing but that could easily be swayed by my preference for Vue.
See how it's done in the guide. It wouldn't be as natural as react allows but should suffice for tiny, contained sub components.
https://vuejs.org/v2/guide/index.html#Composing-with-Compone...
I've never remotely wanted anything similar to this in Vue, but I have seen what you're talking about used in React, mostly for component wrappers to encapsulate logic. It's not something I like using or seeing but that could easily be swayed by my preference for Vue.
See how it's done in the guide. It wouldn't be as natural as react allows but should suffice for tiny, contained sub components.
https://vuejs.org/v2/guide/index.html#Composing-with-Compone...
> I've never remotely wanted anything similar to this in Vue,
This was true of me as well until actually playing more with React. In practice, being able to very quickly extract a child component by just copying a chunk of code to a different spot in the same file is a very nice workflow benefit I now sorely miss when using Vue. In Vue my components tend to be larger and more complex than they are in React because I feel like some small extraction I want to make doesn't "deserve" it's own dedicated file, whereas in React I just quickly make a new function that returns some JSX and I'm done.
This was true of me as well until actually playing more with React. In practice, being able to very quickly extract a child component by just copying a chunk of code to a different spot in the same file is a very nice workflow benefit I now sorely miss when using Vue. In Vue my components tend to be larger and more complex than they are in React because I feel like some small extraction I want to make doesn't "deserve" it's own dedicated file, whereas in React I just quickly make a new function that returns some JSX and I'm done.
> 'Vue.Component' and a template string.
But the template string is just a string, right? Can you get the same IDE integration while avoiding SFCs?
But the template string is just a string, right? Can you get the same IDE integration while avoiding SFCs?
At that point it should probably be its own SFC. But You can also override the render function, and even use JSX.
https://vuejs.org/v2/guide/render-function.html#JSX
https://vuejs.org/v2/guide/render-function.html#JSX
You don't have to use SFCs (I don't in Vue 2 or Vue 3). However, you would be able to nest components in an SFC so long as you don't expect the <template> tag to work in the interior components (I can't imagine how that would even look and work).
The only thing that SFCs do is create a render function for you (as well as some CSS scoping magic). You can do that all yourself and that is all documented and supported behavior.
You have completely the wrong idea here and, honestly, this is all in the documentation.
> React makes no judgements here
Vue typically has fewer opinions than React (and FAR less than Angular) in my experience.
The only thing that SFCs do is create a render function for you (as well as some CSS scoping magic). You can do that all yourself and that is all documented and supported behavior.
You have completely the wrong idea here and, honestly, this is all in the documentation.
> React makes no judgements here
Vue typically has fewer opinions than React (and FAR less than Angular) in my experience.
I'm explaining why I don't like SFCs because the above poster referenced them as a "pro" for Vue over React. Whether or not you _have_ to use them in Vue is immaterial.
You can do this within Vue if you like - you just increment the complexity of your exisiting component, rather than creating a new child
It isn't? You don't have to define them in a single file.
I prefer having the template, styles, and code together, but it isn't required.
I prefer having the template, styles, and code together, but it isn't required.
It largely is an implementation detail. The official guide starts you off without them. You ostensibly could develop an entire application without touching SFC or using the vue cli. But they're such a well implemented pattern that you'll find almost no one in the wild avoiding them, which is pretty telling.
A bit tangential - I've been messing around with vuejs and Django recently (I'm not a web developer in the slightest) and I haven't found a decent way to get webpack integrated. So I can't use SFC or cli and I wonder how people do this in the real world. Do people even use vue with Django?
They are generally deployed separately. Django is used to build a rest API and webpack / Vue are deployed on their own to consume the API. You can put something like nginx in front to route API requests to Django and everything else to an s3 bucket for your single page app.
Any tips on where to look or what to read to implement something like this? I put in an hour or two experimenting with how I could do it and there seem to be a lot of moving parts I’m not familiar with.
I don't know Django specifically and not sure exactly what you want to do but yes you can integrate Vue, webpack & all in anything.
In fact that's what I've encountered in most companies, and what I usually do for my side projects. Basically you output a <app>.js and <app>.css and integrate those in your app layouts / templates.
That's a problem with all these CLI and all those tutorial targeting SPA with a node backend. But IIRC vue-cli as options to help you achieve that, but the docs are not always the clearest for this.
In fact that's what I've encountered in most companies, and what I usually do for my side projects. Basically you output a <app>.js and <app>.css and integrate those in your app layouts / templates.
That's a problem with all these CLI and all those tutorial targeting SPA with a node backend. But IIRC vue-cli as options to help you achieve that, but the docs are not always the clearest for this.
Nothing exotic really. The problem has been how to figure out the process for writing the frontend with npm/webpack, building it and getting Django to serve js files on different pages. I simply couldn’t get it to work. I’ve resorted to just skipping the npm part and writing js scripts in Django's static directories without any libraries or other js tools except for those I could add to an html template with a script tag (which is quite limiting).
I'm going to try separating the frontend and serving it with nginx instead, and only use Django to provide an API for the DB. Maybe I’ll be able to figure that out. My biggest issue is that there are no decent guides for any of this, documentation is allaround terrible and even if there is some guide, it doesn’t work.
I'm going to try separating the frontend and serving it with nginx instead, and only use Django to provide an API for the DB. Maybe I’ll be able to figure that out. My biggest issue is that there are no decent guides for any of this, documentation is allaround terrible and even if there is some guide, it doesn’t work.
I've been hacking together a Webpack setup so I can include small Vue apps in a Django app instead of making it an SPA. Will Vue cli help me with that?
Correct me if I'm wrong but I imagine that's more for the tooling (e.g. syntax highlighting for my template and styles) than an actual preference for SFCs.
Shrug. Maybe? I think Vue is popular enough that if people actually disliked SFCs once they started using Vue they you would see blog posts about how to avoid them, complaining that's why they're leaving Vue, or tooling that makes it easier to bypass them. I don't really see this so my assumption is devs generally like them once they start using them. I could certainly be proved wrong.
Have you used both? This is a comment I usually see from people who have used only one, but not the other.
Let me give you some background about myself - I'm a full time consultant, I write both frontend and backend code for a living. I have worked for almost 27 companies in the last 2 years as a consultant. I have used both.
Vue may copy react, but their implementation and opinionated code structure (Eg. Single file components, Vue-Router, Vuex, etc.) is so much better than the complete freedom that React gives you. Almost all of them who used React had terrible code quality and really bad code organization. In contrast, the Vue code base I've worked with all had some level of uniformity enough for an external consultant to come in and understand what was going in. The worst code I've ever seen till date was on React from an analytics firm. I lasted 15 seconds after which I closed the tab and re-negotiated the contract to do only backend for that firm.
I'm not saying React is bad, end of the day, they're all just tools, but a vanilla TODO Vue application with its syntax is much much better to work with a vanilla TODO react app. Especially for large codebases, this is so true when you work with stuff to manage state like Flux/Vuex.
I also observed that companies using React usually also tend to do more re-writes of their codebases as it becomes unmaintainable over time without an opinionated way to do things like with Vue. Companies with Vue also seem to be more profitable and less reliant on VC money. You can feel free to verify these stats by heading over to LinkedIn/Angel.co and checkout the companies who hire for Vue/React.
So, to answer your question - Does Vue truly offer anything over React that's not in the realm of preferred syntax?
Definitely (as I explained above). I personally would never touch React for a prototype or a project that needs to go to market with less bugs.
Let me give you some background about myself - I'm a full time consultant, I write both frontend and backend code for a living. I have worked for almost 27 companies in the last 2 years as a consultant. I have used both.
Vue may copy react, but their implementation and opinionated code structure (Eg. Single file components, Vue-Router, Vuex, etc.) is so much better than the complete freedom that React gives you. Almost all of them who used React had terrible code quality and really bad code organization. In contrast, the Vue code base I've worked with all had some level of uniformity enough for an external consultant to come in and understand what was going in. The worst code I've ever seen till date was on React from an analytics firm. I lasted 15 seconds after which I closed the tab and re-negotiated the contract to do only backend for that firm.
I'm not saying React is bad, end of the day, they're all just tools, but a vanilla TODO Vue application with its syntax is much much better to work with a vanilla TODO react app. Especially for large codebases, this is so true when you work with stuff to manage state like Flux/Vuex.
I also observed that companies using React usually also tend to do more re-writes of their codebases as it becomes unmaintainable over time without an opinionated way to do things like with Vue. Companies with Vue also seem to be more profitable and less reliant on VC money. You can feel free to verify these stats by heading over to LinkedIn/Angel.co and checkout the companies who hire for Vue/React.
So, to answer your question - Does Vue truly offer anything over React that's not in the realm of preferred syntax?
Definitely (as I explained above). I personally would never touch React for a prototype or a project that needs to go to market with less bugs.
> a vanilla TODO Vue application with its syntax is much much better to work with a vanilla TODO react app
These would be almost identical in structure and design. You're drastically overstating the difference between React and Vue.
These would be almost identical in structure and design. You're drastically overstating the difference between React and Vue.
Picking your brain. Somehow React+Redux feels the stuff of horror stories. Which of React, React+Redux, Vue, Vue+Vuex will lead to the least disaster for a sloppy team?
Approximating Suspense to algebraic effects is a pet peeve of mine. Algebraic effects are more akin to DI or at best to using a generator than the throw-and-retry-everything hack that Suspense does. And to boot, that's not even necessarily the right abstraction (e.g. AFAIK multiple nested suspense things are still an open issue).
I do agree that Vue seems to be reactive in its choice of features, in the sense that it tries to be everything to everyone.
The underlying problem IMHO is that these frameworks are unwilling to create major breaking changes (since that would hamper marketability) so it's easier to just shove things into the unused edges of the semantics space until they becomes a hodge podge of a million ways of doing the same thing.
I feel like Angular is the one framework that sorta "gets it" now. It went all the way to CS lala-land w/ 1.x and rewrote from the ground up for v2 taking several lessons from its v1 and from elsewhere.
I do agree that Vue seems to be reactive in its choice of features, in the sense that it tries to be everything to everyone.
The underlying problem IMHO is that these frameworks are unwilling to create major breaking changes (since that would hamper marketability) so it's easier to just shove things into the unused edges of the semantics space until they becomes a hodge podge of a million ways of doing the same thing.
I feel like Angular is the one framework that sorta "gets it" now. It went all the way to CS lala-land w/ 1.x and rewrote from the ground up for v2 taking several lessons from its v1 and from elsewhere.
>The underlying problem IMHO is that these frameworks are unwilling to create major breaking changes (since that would hamper marketability) so it's easier to just shove things into the unused edges of the semantics space until they becomes a hodge podge of a million ways of doing the same thing.
Sounds like you want Mithril, but keep in mind that backward compatibility and marketability are, in fact, useful features.
Sounds like you want Mithril, but keep in mind that backward compatibility and marketability are, in fact, useful features.
> backward compatibility and marketability are, in fact, useful features
They are (and FWIW, the Stroustrup quote[1] is quite applicable here). I'm merely pointing out that feature creep leads to bloat/complexity which lead to people to complain, and that feature creep also leads to marketability (which is a reason why mainstream language spec documents typically have hundreds of pages). Personally I think this pattern is a problem, but I don't know if anyone has managed to figure out a solution.
[1] https://www.goodreads.com/quotes/226225-there-are-only-two-k...
They are (and FWIW, the Stroustrup quote[1] is quite applicable here). I'm merely pointing out that feature creep leads to bloat/complexity which lead to people to complain, and that feature creep also leads to marketability (which is a reason why mainstream language spec documents typically have hundreds of pages). Personally I think this pattern is a problem, but I don't know if anyone has managed to figure out a solution.
[1] https://www.goodreads.com/quotes/226225-there-are-only-two-k...
Ha! The HN feature of emphasizing comments and de-emphasizing their authors worked too well. I did not notice I was replying to the original author of Mithril. Hi Leo.
If "long copy sells" is the reason why feature creep leads to marketability, then maybe an abundance of examples would help.
If "long copy sells" is the reason why feature creep leads to marketability, then maybe an abundance of examples would help.
Picking on your brain and hindsight ;) , and as someone who did little ES5 and DOM/browser API programming in the past, what would you recommend today for a fast track to a SPA for a solo project? (The learning process is not an issue). The interactivity is not very high but the UX can benefit from a SPA, is an invoicing system.
JS Framework, CSS methodology(UI framework?), etc... or any other perspective you want to share.
JS Framework, CSS methodology(UI framework?), etc... or any other perspective you want to share.
"The React core team has done a wonderful job incorporating actual CS concepts like algebraic effects into their framework"
Is that a good thing?
Is that a good thing?
TBH, React feels like what you get when a bunch of very smart devs decide to "incorporate actual CS concepts like algebraic effects" into showing people ads.
Arguing that we should pick tools based on semantics without considering syntax is like arguing people should pick spouses based on genetics and not personality.
Arguing that we should pick tools based on semantics without considering syntax is like arguing people should pick spouses based on genetics and not personality.
The thing that I find most amusing about modern front end is the over-emphasis developers put on the rendering engine.
Presentation is only a small portion of an application. A view rendering engine is required to do a couple of things, accept and render data.
The semantics of how it accepts data enables good software engineering practices like dependency injection and dependency inversion.
The semantics of how it renders data enable ergonomic usage of the renderer (templating, JSX).
Modern web developers tend to write "React" or "Vue" applications - not "Type/JavaScript applications that render with React"
Global objects, singletons fetched from module-powered service locators, unlimited power global stores and enough boilerplate to make the most hardened Java developer confess their sins to Oracle.
Looks like Vue 3 is fine but continues the trend of doing it all.
Presentation is only a small portion of an application. A view rendering engine is required to do a couple of things, accept and render data.
The semantics of how it accepts data enables good software engineering practices like dependency injection and dependency inversion.
The semantics of how it renders data enable ergonomic usage of the renderer (templating, JSX).
Modern web developers tend to write "React" or "Vue" applications - not "Type/JavaScript applications that render with React"
Global objects, singletons fetched from module-powered service locators, unlimited power global stores and enough boilerplate to make the most hardened Java developer confess their sins to Oracle.
Looks like Vue 3 is fine but continues the trend of doing it all.
This!
But I find that a combination of Typescript, MobX and React brings me very close to a good place.
> The Vue implementation seems to ultimately lack this core understanding, and comes off almost a bit cargo-cultish in comparison. React has hooks, so we must have something similar.
Aren't hooks only needed because React and Vue still use a virtual DOM?
Aren't hooks only needed because React and Vue still use a virtual DOM?
I was hoping for less (or non-at-all) "stringly typing".
Then I saw this: <button @click="increment">
And this
There must be a way to use the actual symbol for this instead of a string?
Then I saw this: <button @click="increment">
And this
function increment() {
count.value++
}
There must be a way to use the actual symbol for this instead of a string?
> I was hoping for less (or non-at-all) "stringly typing".
It's the curse of the template. Once you have them you inevitably start encoding more of your logic in magic-voodoo template directives.
It's the curse of the template. Once you have them you inevitably start encoding more of your logic in magic-voodoo template directives.
The devtools (Jetbrains Webstorm for instance) automatically detect that `increment` refers to the method. So it actually works quite well in practice. And you can use @click="increment(any, args, here)" if you want. The syntax @click="increment" is just syntactic sugar for @click="increment($event)", I think.
It's cool if tooling helps with this. Thats important.
I'm mixed on vue because of the string bindings. I really like to know where my variables are coming from and really hate when two dependent uses but not actually the same thing...
That said, I'm happy to re-evaluate my stance... so what does it mean to be "the same thing"? I suppose in the past, I would say that the compiler thinks the things are the same, and it would be easy to change either:
1. If it is a value, I can set/change it in a single spot
2. If it's a token, it is easy to detect and change everywhere, and tooling will help my avoid misses.
That said, in React, if you were to mess up a 'token', the runtime would be very upset and it would be hard to have something like `onClick={incremant}` (note the a). Tools would make it super easy to spot.
What does vue do if you miss-type your bindings?
I'm mixed on vue because of the string bindings. I really like to know where my variables are coming from and really hate when two dependent uses but not actually the same thing...
That said, I'm happy to re-evaluate my stance... so what does it mean to be "the same thing"? I suppose in the past, I would say that the compiler thinks the things are the same, and it would be easy to change either:
1. If it is a value, I can set/change it in a single spot
2. If it's a token, it is easy to detect and change everywhere, and tooling will help my avoid misses.
That said, in React, if you were to mess up a 'token', the runtime would be very upset and it would be hard to have something like `onClick={incremant}` (note the a). Tools would make it super easy to spot.
What does vue do if you miss-type your bindings?
> That said, in React, if you were to mess up a 'token', the runtime would be very upset
The same is of course true for Vue. At runtime, it will spit an error if it doesn't know that token (variable, function, whatever it is).
My feeling is what you don't like are really the quotation marks because it looks weird. I had a similar feeling when I started with vue. However, it is really a matter of taste if you prefer the Vue @click="foo" or syntax.
The same is of course true for Vue. At runtime, it will spit an error if it doesn't know that token (variable, function, whatever it is).
My feeling is what you don't like are really the quotation marks because it looks weird. I had a similar feeling when I started with vue. However, it is really a matter of taste if you prefer the Vue @click="foo" or syntax.
So, when the jsx is compiled for react is really just part of an object: `{ onClick: foo }` which is actually using the token.
Believe me, I agree to an extend its a matter of taste, but I too like that my underlying understanding of whats happening under the hood can be followed by a raw debugger without following string based mappings.
In react I can set a debugger endpoint right before the return of render and see what all my local variables are... is anything like this possible in vue?
Believe me, I agree to an extend its a matter of taste, but I too like that my underlying understanding of whats happening under the hood can be followed by a raw debugger without following string based mappings.
In react I can set a debugger endpoint right before the return of render and see what all my local variables are... is anything like this possible in vue?
I agree with you on the preference part. I share the same preference as the GP. I've played a bit with Vue in the past, at the same time I was testing React. I've enjoyed Vue but the strings and template were a grim reminder of the Angular not-so-fun-times and passing members around per-reference and not "per string" made more sense in the general JavaScript way of programming, and so I ended up sticking with React.
Even with tooling support, those strings still make me wanting to look away...
Even with tooling support, those strings still make me wanting to look away...
throw an error saying "incremt is referenced during render..."
I personally think this is a non-argument to begin with, but the new API coupled with the fact that Vue supports the render function and JSX would give you what you want.
I personally think this is a non-argument to begin with, but the new API coupled with the fact that Vue supports the render function and JSX would give you what you want.
I think what he means is why not use ++ in the click handler. We don't need a function to increment something.
Standard HTML,
Standard HTML,
No, I think he's referring to the fact that the function increment is called by interpreting the string "increment".
you can do exactly that, they just wanted to showcase the methods option.
often you would switch true to false doing:
`@click="isSomething = !isSomething"`
`@click="isSomething = !isSomething"`
Exactly this. Template directives support a lot of JS functionality (while not encouraging it, like JSX does). That said, except in rare, extremely simple cases I still prefer wrapping that logic in a computed property or method, as it will inevitably grow more complex later.
Still makes it harder to refactor, use code analysis/indexing tools and so on.
Since the way you build a vuejs application encourages breaking your code into small, mostly self contained, focused components this is rarely a real problem in my experience.
Tooling also seems to deal with it just fine.
Tooling also seems to deal with it just fine.
You can use render functions instead of templates if you really want that.
It doesn't bother me though. Tooling (ESLint or TypeScript) will catch typos, missing methods, etc for you.
It doesn't bother me though. Tooling (ESLint or TypeScript) will catch typos, missing methods, etc for you.
TSX is supported by Vue and, unlike templates, that is not opaque to the compiler. I recently switched the code in a side project of mine to TSX and it was worth the change.
Do you have any pointers on setting up TypeScript properly for the jsx render function while preserving intellisense? "Supported" is a bit tenuous based on the manual setup and shim creation required to get it all working nicely..
This is my setup:
- vue, @vue/composition-api
- Rollup
- Babel: @babel/preset-typescript, @babel/preset-env, @vue/babel-preset-app, babel-preset-vca-jsx
- Just pass `extensions: ['.js', '.jsx', '.ts', '.tsx']` to the Rollup babel plugin.
Make sure you are using createComponent inside a TSX file, and you'll get every feature that TS has to offer (as it is all native TS). Intellisense and static types are the only reason I dropped SFCs.
I'm not sure how this would work with Webpack, I've been enjoying Rollup more as things have just worked with no thought involved so far. I'm sure it can be done, though.
- vue, @vue/composition-api
- Rollup
- Babel: @babel/preset-typescript, @babel/preset-env, @vue/babel-preset-app, babel-preset-vca-jsx
- Just pass `extensions: ['.js', '.jsx', '.ts', '.tsx']` to the Rollup babel plugin.
Make sure you are using createComponent inside a TSX file, and you'll get every feature that TS has to offer (as it is all native TS). Intellisense and static types are the only reason I dropped SFCs.
I'm not sure how this would work with Webpack, I've been enjoying Rollup more as things have just worked with no thought involved so far. I'm sure it can be done, though.
What's your Vue+Rollup configuration?
But that feels a bit like saying you can use React without JSX. Sure, you can, but it appears that the templates are a major selling point for Vue to many people. That's the part that's most baffling. (Well, not really baffling, as it's a pretty subjective matter. But not for me, at least :)
In vue you can do <button @click="increment()"> and it treats it the same. I tend to put the (), especially since I am almost always passing in some sort of object inside a loop.
Isn’t that still a string?
Would you be happier with the following?
<button @click=increment>
That is legal (or at least it is supposed to be, I've not tested it), but is not really different. This part of Vue parsing is dictated by the whatwg html specification, and the html spec says that <html lang=en> and <html lang="en"> are the same thing.
<button @click=increment>
That is legal (or at least it is supposed to be, I've not tested it), but is not really different. This part of Vue parsing is dictated by the whatwg html specification, and the html spec says that <html lang=en> and <html lang="en"> are the same thing.
Getting rid of a giant ‘this’ and taking a more functional approach was 100% the right direction for Vue to go.
I am also glad to see the new way to define event handlers. The v 2 way of defining a “methods” prototype forces me to constantly reference “this” (which will only exist later after the component has “really” been created), which I would prefer to avoid.
At least in AngularJS I can capture “this” as a closure variable at the start of the component setup “decorator” function, then alias other functions delegated as the component “methods” (event handlers) without worrying about object instance references for “apply” and such.
Now, I can so something similar in Vue components: get the data up front in the event handlers definitions, and delegate to any functions I want using closures or partially applied arguments.
Hard to understate the importance of the new event handler setup API.
At least in AngularJS I can capture “this” as a closure variable at the start of the component setup “decorator” function, then alias other functions delegated as the component “methods” (event handlers) without worrying about object instance references for “apply” and such.
Now, I can so something similar in Vue components: get the data up front in the event handlers definitions, and delegate to any functions I want using closures or partially applied arguments.
Hard to understate the importance of the new event handler setup API.
Or you can skip the attempts to provide pseudo-reactivity on top of JS and clumsy shoehorning of GUI apps into finite state machines. Just use Svelte instead.
https://svelte.dev
Transpilation and static analysis are the ways to go.
https://svelte.dev
Transpilation and static analysis are the ways to go.
I actually tried out Vue after I had a production app made using svelte 3 and was amazed how verbose Vue is in comparison. Not to mention Svelte's smaller bundle sizes due to absent run-time library.
The fact render functions are made on build time does not mean Svelte has no runtime. Svelte has nice things going for it but you guys are just writing bullshit in order to criticize Vue.
Not close to fully runtime-less sure, but about as close as you can get. It's the same way C isn't runtime-less compared to assembly because it has crt.0 but compared to Java it effectively is.
> Not close to fully runtime-less sure, but about as close as you can get.
Have you looked at transpiled Svelte code? It's 5-10x bigger than the source code because an entire runtime library is injected and your code is rewritten to use that library at compile time.
Have you looked at transpiled Svelte code? It's 5-10x bigger than the source code because an entire runtime library is injected and your code is rewritten to use that library at compile time.
I kinda agree but you should explain why your last statement is true.
In a recent presentation Evan You mentioned Svelte and basically said that their approach is better and if it weren't for backwards compatibility he'd have taken a lot more of their ideas for Vue 3
How does Svelte help with static analysis? Genuinely curious here.
I've had my eye on this issue[1] for a while. I'm excited about the idea behind Svelte, but without static typing support, there's no way I could feel comfortable using it on a real project.
[1]: https://github.com/sveltejs/svelte/issues/1639
I've had my eye on this issue[1] for a while. I'm excited about the idea behind Svelte, but without static typing support, there's no way I could feel comfortable using it on a real project.
[1]: https://github.com/sveltejs/svelte/issues/1639
Static analysis as in tracking variable mutation propagation on the compiler level. You don't need types for that.
GUI programs are inherently stateful and the functional model used by React and others boils down to shoving everything into a giant finite state machine. You explicitly specify all possible states when you code so the state of your GUI is explicit instead of implicit. In traditional GUI terms, immediate-mode versus retained-mode (immediate in the sense of DOM updates, the reference here is how often and how much do you mutate the DOM and not frames per second because the DOM is also stateful which is one of the reasons why web programming require so many hacks). Now this isn't easy in practice because of obvious reasons - the state space explodes as the number of variables increases and trying to having a single store to keep everything in sync can be difficult and annoying. Sure your code will be somewhat more bug-free in the end but you have to spend a lot of effort and end up with verbose code. Svelte on the other hand make variables reactive on the compiler level. So you get both the Excel-style reactive feeling out of the box and at the same time optimized runtime-less code that only mutates when it has to (current solutions all require a library runtime to keep track of things, diff DOMs etc.). In other words, like traditional hand written code but with the compiler preventing bugs due undefined state/variables getting out of sync issues.
My explanation is probably inaccurate/simplified in some aspects so please feel free to elaborate upon it.
GUI programs are inherently stateful and the functional model used by React and others boils down to shoving everything into a giant finite state machine. You explicitly specify all possible states when you code so the state of your GUI is explicit instead of implicit. In traditional GUI terms, immediate-mode versus retained-mode (immediate in the sense of DOM updates, the reference here is how often and how much do you mutate the DOM and not frames per second because the DOM is also stateful which is one of the reasons why web programming require so many hacks). Now this isn't easy in practice because of obvious reasons - the state space explodes as the number of variables increases and trying to having a single store to keep everything in sync can be difficult and annoying. Sure your code will be somewhat more bug-free in the end but you have to spend a lot of effort and end up with verbose code. Svelte on the other hand make variables reactive on the compiler level. So you get both the Excel-style reactive feeling out of the box and at the same time optimized runtime-less code that only mutates when it has to (current solutions all require a library runtime to keep track of things, diff DOMs etc.). In other words, like traditional hand written code but with the compiler preventing bugs due undefined state/variables getting out of sync issues.
My explanation is probably inaccurate/simplified in some aspects so please feel free to elaborate upon it.
This was a great read, thanks.
I've used svelte for one site that ended up being a good fit. Ended up using Sapper to build out the static site and was pretty impressed with the load times
I've used svelte for one site that ended up being a good fit. Ended up using Sapper to build out the static site and was pretty impressed with the load times
After building some larger Vue apps, I am starting to see the issues with the older system.
But I worry this will turn into React at some point. Can anyone assuage my concerns on this?
But I worry this will turn into React at some point. Can anyone assuage my concerns on this?
I feel like angular, react and Vue converge on. Similar set of principles.
Essentially, they learn from each other, but they will never be quite the same
Essentially, they learn from each other, but they will never be quite the same
I agree, I'm a react dev and I think Vue, and others, are great.
All of them are approaching the same problem from different directions and paths. If each discovers something new and useful, the others can decide if it would be a good fit for them.
It's all wins all around, so I don't understand the disparagement.
All of them are approaching the same problem from different directions and paths. If each discovers something new and useful, the others can decide if it would be a good fit for them.
It's all wins all around, so I don't understand the disparagement.
Because there are some things that are pure genius to me that Vue does that React and others do not do, and I don't want to lose that.
But, my long term view is that Svelte (or Svelte like) library will win out in the long term. Getting code back to basics is a great theme/trend. It's what made me like Vue to start with.
But, my long term view is that Svelte (or Svelte like) library will win out in the long term. Getting code back to basics is a great theme/trend. It's what made me like Vue to start with.
Can you give some examples of those "pure genius"s?
NOTE: Those that will roast me for not spending yet enough time trying to get other libraries to work outside of Vue, feel free to offer me your production budget to spend on that.
Cost to start. The first time I tried Vue (after trying a bunch of other libraries) I had something working in minutes. React required I learn many other things before even getting a "hello world" to function. Straight html/js connection. JSX is a nightmare.
Integration with existing systems. I work with hundreds of thousands of lines of code in a very messy old system. I was able to gut pieces of jQuery and nearly drop in replace with Vue.
Template focused development. I don't care how super duper awesome the "render" function is. I don't care how fast or performant. I am need to build a tool that I use for a couple of years and then throw away. (long story short, having a build pipeline is a detriment in many apps that I work on because their lifespan is so short)
I may be an amateur, but that is where Vue is genius. I don't have time to learn 20 new entire systems, 10 new build platforms, Node.js (and all that entails) just to get a reactive app to replace some super old jQuery junk.
I am now more capable than before, but after managing so much code for so many years, I want things _less_ complicated, not more. Nearly 100% of the code I wrote 20 years ago is gone now, replaced, rebuilt and redesigned. All the Vue I will build today will be gone in a few years, that is almost a certainty. So I have no budget for messing around.
The list can go on, but I am sure I will get harrassed with this about how React can run live and doesn't need compilation, ha. I tried it, what a mess it was. Learning the quirks of JS is bad enough, learning the quirks of doing 'JS exactly like React/Vue' wants you to? Ugh, that just sucks so bad I want to pull my hair out. The less a library I have to deal with the better. The more pure and simple code is the better. /rant.
Cost to start. The first time I tried Vue (after trying a bunch of other libraries) I had something working in minutes. React required I learn many other things before even getting a "hello world" to function. Straight html/js connection. JSX is a nightmare.
Integration with existing systems. I work with hundreds of thousands of lines of code in a very messy old system. I was able to gut pieces of jQuery and nearly drop in replace with Vue.
Template focused development. I don't care how super duper awesome the "render" function is. I don't care how fast or performant. I am need to build a tool that I use for a couple of years and then throw away. (long story short, having a build pipeline is a detriment in many apps that I work on because their lifespan is so short)
I may be an amateur, but that is where Vue is genius. I don't have time to learn 20 new entire systems, 10 new build platforms, Node.js (and all that entails) just to get a reactive app to replace some super old jQuery junk.
I am now more capable than before, but after managing so much code for so many years, I want things _less_ complicated, not more. Nearly 100% of the code I wrote 20 years ago is gone now, replaced, rebuilt and redesigned. All the Vue I will build today will be gone in a few years, that is almost a certainty. So I have no budget for messing around.
The list can go on, but I am sure I will get harrassed with this about how React can run live and doesn't need compilation, ha. I tried it, what a mess it was. Learning the quirks of JS is bad enough, learning the quirks of doing 'JS exactly like React/Vue' wants you to? Ugh, that just sucks so bad I want to pull my hair out. The less a library I have to deal with the better. The more pure and simple code is the better. /rant.
I've been following the development of vue 3 for a while now and the reaction in the js community for this new version from both vue fans and detractors has been absolutely awful.
Some of the blame rests on the vue team because they did a poor job of explaining the changes. But I think an even bigger issue is that the js community is all over the place in terms of skill level, application of vue and understanding the changes.
The new composition api is basically a way to write reusable code. Mixins also exist, but you can't call code in between other mixins. It also allowed for better typescript support since it's basically regular code and was easier to implement than the class based syntax that they originally planned. It basically killed two birds with one stone.
These changes aren't really big or earth-shattering. They are still an improvement though, and fits well with a project that's making incremental improvements while also being very stable.
Some of the blame rests on the vue team because they did a poor job of explaining the changes. But I think an even bigger issue is that the js community is all over the place in terms of skill level, application of vue and understanding the changes.
The new composition api is basically a way to write reusable code. Mixins also exist, but you can't call code in between other mixins. It also allowed for better typescript support since it's basically regular code and was easier to implement than the class based syntax that they originally planned. It basically killed two birds with one stone.
These changes aren't really big or earth-shattering. They are still an improvement though, and fits well with a project that's making incremental improvements while also being very stable.
Questions for devs who used vue in the past on production apps, what about Svelte? I find it easier, cleaner and practical.
React for 2/3 years, Vue for 1 year building large SASS apps. I use Svelte for my personal site and really enjoyed it, but dismissed it as a contender for my companies latest application. It's community is still too young, there's not enough established, battle-tested libraries for common tasks like routing. It reminds me of React in the early days, I felt overwhelmed with choice and a constant feeling the 3rd party library you are about to go all in with will be shortly replaced with a better, community backed alternative.
I'd love to re-visit that in a couple of years time when it's popularity and community has risen and is more established. Just as React did.
I'd love to re-visit that in a couple of years time when it's popularity and community has risen and is more established. Just as React did.
Mature communities are absolutely essential for any serious production development. It's doesn't matter if Svelte is technically superior in ways until it's been battle tested and has wide support.
Otherwise you'll be spending far too much time on things that other people have long ago solved in other frameworks.
Otherwise you'll be spending far too much time on things that other people have long ago solved in other frameworks.
I really want to use svelte, but I don't know when it'll be production ready. From what I can tell, it's aiming to do a lot more than be a simple js framework. For now, and probably the foreseeable future, vue is good enough. Tbh, the scope for svelte is so large I really wouldn't trust it unless it got really really popular.
While Svelte is being developed by a great programmer, it's too new, doesn't have all of it's Typescript stuff figured out, and last I checked the unit testing story was still a bit shaky. I'm guessing that in a year or less it'll get those three things figured out.
This is a weirdly negative comment section.
I think once you're invested into an ecosystem you become naturally disincentivized to see another one supercede it.
Honestly I think these discussions are just pretty low quality. I find that people are pretty good at mis-attributing their success and failures to their tech stacks, especially in a field where there's a lot of novices like front-end development.
[deleted]
I've seen a lot of negativity towards Vue from React users pretty much since it started gaining actual usage by big companies. Never by the core React team, just the users of it. To a lesser degree, I've seen some Vue users express haughtiness because they see Vue as much less complicated.
I liked vue guide, but now that I'm making an application, I'm dubious about the component thing for application state trees. After seeing some clojurescript talks it seemed quite a lot cleaner. I now wonder how different is react..
I was not that sold on the first draft but I'm now excited for Vue3's improvements and the TS support.
This is a bit disappointing if it's really all that is new. You get... a bunch of stuff from React that's mostly already available through libraries?
Better than a poke in the eye with a sharp stick, aka compatibility break.
Personally, I find it fantastic that the core API and feature set are this stable across an entire rewrite of the framework's internals (moving to `Proxy` for change tracking, etc). Vue has every feature I need already.
because these are the things everyone comes in contact with and uses. there are indeed new features (in Vue 2 even) that have to do with dynamic Vue directives in the template and other three or fours features that unless you are writing an insanely reusable component or a Vue plugin, you would settle for a more orthodox and long way of doing things approach.
I'm most excited about the reduction in bundle size and the ability to tree-shake the source.
It's not, this is just a few standout features that the website found compelling. I'm more excited about the massive performance improvement and typescript support.
This is a major rewrite, so there are a lot of cool changes like much better performance, better ts support, separating the underlying parts of vue to do things like have better control of making things reactive, then the api change that everyone has been panicking about, use of proxies (the implications of which I can't remember now), etc.
technical beside, I'm worried about the hit-by-a-bus factor, even though Evan is no longer the sole developer, he remains to be the crucial single point of failure. for that alone I chose React, yes it's harder to start there, but the job market and a large company devoting to it made me sleep better.
The Vue implementation seems to ultimately lack this core understanding, and comes off almost a bit cargo-cultish in comparison. React has hooks, so we must have something similar.
I don't mean this as singularly bad, I'm certain Vue can be productive and that this can be a productive feature for Vue devs - but when will we as an industry manage to evaluate software by semantics rather than the syntax we prefer? Does Vue truly offer anything over React that's not in the realm of preferred syntax?