Vue 3.2(blog.vuejs.org)
blog.vuejs.org
Vue 3.2
https://blog.vuejs.org/posts/vue-3.2.html
152 comments
I moved to Vue from ~3 years of React. I've now done ~2 years of VueJS while continuing to use React in some side projects.
To be quite honest, I'd probably stick with React if given the choice. My takeaway with Vue is it makes a number of choices for you out of the gate w.r.t to things like data store (Vuex) and routing (Vue-router) whereas with React you'd bolt these on yourself (i.e. mobx and found-router).
I also feel like Vue gives you many more opportunities to shoot yourself in the foot in weird and wonderful ways. For example, you can access the instance of a parent or child component without too much trouble whereas React does seem to go out of its way to prevent this.
React has a few quality of life improvements too, things like hooks (which may be in Vue now? Not sure) and being able to have components with multiple children at the root.
To be quite honest, I'd probably stick with React if given the choice. My takeaway with Vue is it makes a number of choices for you out of the gate w.r.t to things like data store (Vuex) and routing (Vue-router) whereas with React you'd bolt these on yourself (i.e. mobx and found-router).
I also feel like Vue gives you many more opportunities to shoot yourself in the foot in weird and wonderful ways. For example, you can access the instance of a parent or child component without too much trouble whereas React does seem to go out of its way to prevent this.
React has a few quality of life improvements too, things like hooks (which may be in Vue now? Not sure) and being able to have components with multiple children at the root.
If you've only worked with vue2, I'd give vue3 a look. I like the new composition API a lot.
> you can access the instance of a parent or child component without too much trouble
$children was removed in vue3 https://v3.vuejs.org/guide/migration/children.html
> things like hooks
Vue doesn't have react style hooks, but the composition API fills a similar niche.
> being able to have components with multiple children at the root.
Vue3 seems to support this: https://v3.vuejs.org/guide/migration/fragments.html
> you can access the instance of a parent or child component without too much trouble
$children was removed in vue3 https://v3.vuejs.org/guide/migration/children.html
> things like hooks
Vue doesn't have react style hooks, but the composition API fills a similar niche.
> being able to have components with multiple children at the root.
Vue3 seems to support this: https://v3.vuejs.org/guide/migration/fragments.html
I work about 80-90% with Vue 2 and 10-20% with React, so take this with salt.
But, with React, I rarely find myself wondering why the component isn’t re-rendering when something changes, whereas this happens frequently with Vue.
I also rarely find myself having to plan out how props will flow to state or when something needs to be a computed (or memoized) property. Things usually just kind of come together.
There are several reasons for this, but often times it comes down to either doing the wrong type of assignment that makes Vue lose its wrapper object around the property, or something to do with the way I use props as defaults for reactive state.
Which leads to another complaint - mixing props passed in to the component in the same space as the reactive state. This means the property needs a different name from the state property that it drives, it means having to mentally track which piece of data can be mutated because its state and which cannot because its a prop, and it often means wondering why your component isn’t re-rendering when your prop changes, only to finally realize you really need a computed prop or a prop watcher.
I don’t want to sound overly dramatic though. It doesn’t happen every day, it’s never prevented me from doing anything, and Vue (IMO) makes up for it in other ways like single file components with better styling options. It’s also possible I just haven’t used React enough.
But that said, in my experience, some of Vue’s magic that makes it simpler to get started with, is also what makes it trickier to work with as projects get larger.
Disclaimer: Vue 3 introduces hook like things that I haven’t tried, and perhaps make my complaints less valid.
But, with React, I rarely find myself wondering why the component isn’t re-rendering when something changes, whereas this happens frequently with Vue.
I also rarely find myself having to plan out how props will flow to state or when something needs to be a computed (or memoized) property. Things usually just kind of come together.
There are several reasons for this, but often times it comes down to either doing the wrong type of assignment that makes Vue lose its wrapper object around the property, or something to do with the way I use props as defaults for reactive state.
Which leads to another complaint - mixing props passed in to the component in the same space as the reactive state. This means the property needs a different name from the state property that it drives, it means having to mentally track which piece of data can be mutated because its state and which cannot because its a prop, and it often means wondering why your component isn’t re-rendering when your prop changes, only to finally realize you really need a computed prop or a prop watcher.
I don’t want to sound overly dramatic though. It doesn’t happen every day, it’s never prevented me from doing anything, and Vue (IMO) makes up for it in other ways like single file components with better styling options. It’s also possible I just haven’t used React enough.
But that said, in my experience, some of Vue’s magic that makes it simpler to get started with, is also what makes it trickier to work with as projects get larger.
Disclaimer: Vue 3 introduces hook like things that I haven’t tried, and perhaps make my complaints less valid.
I, similarly, work about 90% with Vue2 and 10% with React.
I have a different experience though. I generally find React pretty mysterious, with very confusingly named methods, and several generations of approaches that are completely different from each other. (React Hooks changes everything...)
I used to occasionally find situations in Vue where something wouldn't re-render, but that almost never happens anymore. The main culprits are when a component never gets mounted (because it's in a v-if), or expecting reactivity before it gets mounted.
I hate the clumsiness of React, the lack of "methods" and simple event handlers, the need to be overly verbose everywhere.
I almost never use Vuex, fwiw. I find both Redux and Vuex (which apes it) are an incredibly complicated solution to the problem, and wish there was something simpler.
I have a different experience though. I generally find React pretty mysterious, with very confusingly named methods, and several generations of approaches that are completely different from each other. (React Hooks changes everything...)
I used to occasionally find situations in Vue where something wouldn't re-render, but that almost never happens anymore. The main culprits are when a component never gets mounted (because it's in a v-if), or expecting reactivity before it gets mounted.
I hate the clumsiness of React, the lack of "methods" and simple event handlers, the need to be overly verbose everywhere.
I almost never use Vuex, fwiw. I find both Redux and Vuex (which apes it) are an incredibly complicated solution to the problem, and wish there was something simpler.
Redux/Vuex never. I have yet to find someone who likes them, they've merely learned to tolerate them.
Funnily enough the reasons you gave are the reasons I like vue and dislike React.
I like de facto solutions instead of half-baked libraries that might have slight incompatability issues.
I also like the freedom and flexibility that vue offers rather than the weird guardrails that come with react.
I like de facto solutions instead of half-baked libraries that might have slight incompatability issues.
I also like the freedom and flexibility that vue offers rather than the weird guardrails that come with react.
The CLI literally gives you the option to add vuex and vuerouter but it doesn’t force you to. You can use whatever you want or not use these options at all. You can access the instance of parent or child but it also recommends you to use props and emits so that you don’t shoot yourself in the foot.
All Javascript UI frameworks are the same. They provide a way to build UI and interactivity using components, and are powered by the same functional flow of data -> render components -> trigger event -> change data -> repeat...
Once you get past the fundamentals, it's just choosing the features that you like better. Vue uses HTML-based templates by default which I find better for 99% of scenarios, and can also be generated by a server-side framework which makes it easy to integrate into existing webapps without rebuilding as a complete SPA.
Reactivity is another thing that all frameworks and state management as evolved to, since it's just automating what you were manually doing anyway. Mobx and the like were early versions but the composition API in Vue 3 is probably the most polished version of this with automatic tracking that does what you expect and intuitive effects/watchers.
Vue also has official projects vs the 'unofficial' official ones for React, but that's a purely subjective preference at this point.
Once you get past the fundamentals, it's just choosing the features that you like better. Vue uses HTML-based templates by default which I find better for 99% of scenarios, and can also be generated by a server-side framework which makes it easy to integrate into existing webapps without rebuilding as a complete SPA.
Reactivity is another thing that all frameworks and state management as evolved to, since it's just automating what you were manually doing anyway. Mobx and the like were early versions but the composition API in Vue 3 is probably the most polished version of this with automatic tracking that does what you expect and intuitive effects/watchers.
Vue also has official projects vs the 'unofficial' official ones for React, but that's a purely subjective preference at this point.
Agreed. I think HTML is great and JSX is an abomination. I also don't need literally 69 ways to do CSS in my React components. So, I prefer Vue SFC.
> Anyone moved from React to Vue
I'm considering a move in the opposite direction for a few reasons:
1. React Native. I can build mobile apps using Vue via Ionic Framework / Cordova / Capacitor but that ecosystem is a nightmare (esp the Cordova/Capacitor split). React Native has more extensions available and the camera related ones are considerably more featureful.
2. Libraries/widgets. Vue has widget libraries available and (multi)select fields et al work great. But when you want something more advanced - a decent calendar picker for example - I always turn up a React library that does what I want, and the Vue one doesn't. [I suspect there's compatibility issues if you use too many React widgets - gras is always greener etc]
3. Expectation that you know React. I've had clients say "we use Vue, do you know it?" but I've had 10x more say "We use React, do you know it?".
I'm considering a move in the opposite direction for a few reasons:
1. React Native. I can build mobile apps using Vue via Ionic Framework / Cordova / Capacitor but that ecosystem is a nightmare (esp the Cordova/Capacitor split). React Native has more extensions available and the camera related ones are considerably more featureful.
2. Libraries/widgets. Vue has widget libraries available and (multi)select fields et al work great. But when you want something more advanced - a decent calendar picker for example - I always turn up a React library that does what I want, and the Vue one doesn't. [I suspect there's compatibility issues if you use too many React widgets - gras is always greener etc]
3. Expectation that you know React. I've had clients say "we use Vue, do you know it?" but I've had 10x more say "We use React, do you know it?".
1. Have you checked https://vue-native.io/ ?
Have you checked Vue-Native? It hasn’t been maintained since October 2020 and IIRC doesn’t work with the latest RN versions.
I don't use Vue-Native, but it seems to be undergoing regular, active development, with a release in July 2021.
If you do not use it why do you feel you should comment about it?
I don't use it, but based on my observations (i.e. looking at the Github repo), I can see that there have been several releases and continued significant development –not merely dependency updates– in the past few months.
I was merely offering an objective correction to the parent comment's statement:
> It hasn’t been maintained since October 2020
I was merely offering an objective correction to the parent comment's statement:
> It hasn’t been maintained since October 2020
I've used both extensively and what makes me lean towards Vue on new projects is the reactivity system. It seems that with React you always have to wrestle with it to not do too many re-renders, but Vue is more likely to update only the parts of the dom that need updating out of the box.
With composition API and Vue 3 bringing typescript support and hooks to me it's a no brainer to choose Vue.
One other thing is that I've seen people who are normally doing only backend pick up Vue in a day or 2, but React takes longer to grok. You're probably likely to find more people who have already learned React than Vue though, due to its popularity.
React also has a bigger community but I haven't felt that I was lacking when looking for Vue libraries.
With composition API and Vue 3 bringing typescript support and hooks to me it's a no brainer to choose Vue.
One other thing is that I've seen people who are normally doing only backend pick up Vue in a day or 2, but React takes longer to grok. You're probably likely to find more people who have already learned React than Vue though, due to its popularity.
React also has a bigger community but I haven't felt that I was lacking when looking for Vue libraries.
I feel the exact opposite about the reactivity.
React is: always right, sometimes slow
Vue is: always fast, mostly right
I prefer fixing performance bottlenecks later over having any doubt about the correctness of my view or debugging why this one property only sometimes becomes reactive. But I can see how others would feel differently.
React is: always right, sometimes slow
Vue is: always fast, mostly right
I prefer fixing performance bottlenecks later over having any doubt about the correctness of my view or debugging why this one property only sometimes becomes reactive. But I can see how others would feel differently.
In my experience those optimisations tend to never happen unless they make the app unusable, leading to tons of WebApps working like crap.Probably you work on a company that budgets a lot to eorgormsnce optimisation, etc or you just care a lot about it, bit in my experience most companies and most developers don't have the time or motivation for it. I'm tired of sluggish crap.
I agree. The reactivity system is definitely less verbose in Vue compare to React. And when you start working with things like Redux it gets very layered and complex very fast.
I switched some years ago and never looked back. What I really like about Vue is that I can use it with a build system or just add it with a script tag for a bit of progressive enhancement over a form. I think it is simpler and decreased my bug count. I'm mainly a backend developer though.
I primarily work with React but have done a number of Vue projects. It a great tool ä but I don‘t see any reason to switch, if you don‘t find react confusing.
What I don‘t like:
- jsx support is second class
- composition is wonky (better in3?)
- typescript is wonky (better in 3?)
- automatic reactivity is less predictable than the explicitness in React
- automatic reactivity on complex data structures is wonky
- no more than one component per file
- the "official" router is config based. I like the component composition of react-router
What I like
- way easier to learn for any previous web developer
- vuex. I think global state libs are overused but if you need one, it‘s nice and it‘s great that you don‘t have to glue it to the framework yourself
- significantly smaller and faster
- can realistically work without a bundler directly in any html page
What I don‘t like:
- jsx support is second class
- composition is wonky (better in3?)
- typescript is wonky (better in 3?)
- automatic reactivity is less predictable than the explicitness in React
- automatic reactivity on complex data structures is wonky
- no more than one component per file
- the "official" router is config based. I like the component composition of react-router
What I like
- way easier to learn for any previous web developer
- vuex. I think global state libs are overused but if you need one, it‘s nice and it‘s great that you don‘t have to glue it to the framework yourself
- significantly smaller and faster
- can realistically work without a bundler directly in any html page
I've largely worked with Vue 2 in recent years over React. Primarily moved just to try and reduce front end bloat, and stuck because I preferred some of the patterns—personally I found them easier to reason around than some of the popular React patterns.
I really liked The Vue class component pattern. Localized styles, logic, and markup, coherent state management built-in.
The tooling got more bloated in time, but it was still a breeze to work with.
I'm now trying to catch up with React again as industry tends to dictate—so far so good, but I liked the "pure"/Vue-flavoured HTML markup approach of Vue over JSX. It seemed to have all the benefits of JSX a la close-coupling in class components, but saves the wonky half-flavour of markup/logic—especially when it comes to working in TypeScript.
That said, maybe my tune will change after I spend more time in the React ecosystem again—especially trying to make more use of server-side rendering.
I really liked The Vue class component pattern. Localized styles, logic, and markup, coherent state management built-in.
The tooling got more bloated in time, but it was still a breeze to work with.
I'm now trying to catch up with React again as industry tends to dictate—so far so good, but I liked the "pure"/Vue-flavoured HTML markup approach of Vue over JSX. It seemed to have all the benefits of JSX a la close-coupling in class components, but saves the wonky half-flavour of markup/logic—especially when it comes to working in TypeScript.
That said, maybe my tune will change after I spend more time in the React ecosystem again—especially trying to make more use of server-side rendering.
I’m not a full-time front end developer, so take this with a grain of salt. I write JS frontends for my nights and weekends side projects. I chose Vue over React because it seemed easier to get up to speed.
When I was looking to change jobs earlier this year I spoke with a lot of recruiters and they all said companies were looking for React developers, there were zero mentions of Vue. I don’t really regret my choice of learning Vue but React would have definitely been a selling point on my resume.
Will this change in a few years? Who knows. It feels like it’s React vs everyone else and as more and more projects get built in React I suspect the difference will widen even more.
When I was looking to change jobs earlier this year I spoke with a lot of recruiters and they all said companies were looking for React developers, there were zero mentions of Vue. I don’t really regret my choice of learning Vue but React would have definitely been a selling point on my resume.
Will this change in a few years? Who knows. It feels like it’s React vs everyone else and as more and more projects get built in React I suspect the difference will widen even more.
We chose Vue at Parse.ly after spending quite a lot of time building real-world web products in pre-SPA simple Django + jQuery (2012-2015), then Angular 1.x (2015-2020), and then React (a 1 year experiment, 2018-2019).
We switched our main product to Vue last year, and we couldn't be happier. And, we advertise Vue in our job postings. And, we are hiring!
https://www.parse.ly/careers/frontend_engineer
We switched our main product to Vue last year, and we couldn't be happier. And, we advertise Vue in our job postings. And, we are hiring!
https://www.parse.ly/careers/frontend_engineer
I recently started working with Solid [1], it's like Svelte for React, and it's way faster than both of them. It has the same JSX syntax and very similar hooks to React. The only problem is that you will find yourself porting many React libraries since Solid is quite new and doesn't have as a big of a community.
[1]: https://www.solidjs.com/
[1]: https://www.solidjs.com/
And when you started porting libraries, why did you not start to wonder if that is the right way to go?
I’m in the process of making this move now because I know both well but I’m on a team of primarily backend engineers that want to be able to work on our front ends and Vue is much simpler to read and reason about in my experience. Fewer files, fewer new concepts, syntax closer to what you’d see with old school server rendered stuff. I don’t really care about 3rd party libs or React Native so it just makes sense.
Overall I just have a strong aesthetic preference for Vue too. It feels clean and I have a higher appreciation for the quality of my work when I use it. React apps I work on always feel like they’re not quite “there”, there’s so many different parts that it never feels fully coherent to me.
Overall I just have a strong aesthetic preference for Vue too. It feels clean and I have a higher appreciation for the quality of my work when I use it. React apps I work on always feel like they’re not quite “there”, there’s so many different parts that it never feels fully coherent to me.
We moved from Vue to React because it has much better static typing support. Properties are native Typescript values and templates are TSX which gives you proper Typescript type checking and also full IDE support (autocomplete, go to definition, etc.).
Also Vue's automatic reactivity system is fine for small websites but for large apps it turns into an impossible to follow spaghetti nightmare.
Also Vue's automatic reactivity system is fine for small websites but for large apps it turns into an impossible to follow spaghetti nightmare.
Was that vue2 or vue3? I believe vue3/composition API made some improvements in both of these areas.
For me JSX vs HTML templates depends of your organization and workflow. If you’re a solo dev or in a JS heavy team, I think JSX can make more sense. HTML templates on other hand give a lot of power to non dev. It works well for our agency with our web designers, they can handle all the logic in the HTML, so much that on some projects no additional JS developper is needed.
One difference being that vue templates appear to be hard to make type-safe i.e. hard to benefit from type-checking, whereas jsx is syntactic sugar for JS, and supported by typescript.
I'd rather have jsx, all else being equal.
I'd rather have jsx, all else being equal.
I have a small toy project (essentially CRUD for images + tags + descriptions) that has a React frontend, mostly old class-style components. Having rewritten this frontend using Vue 3, my impression is that Vue 3 with its Composition API is just a different flavor of React with function-style components and hooks.
I'm in my first few months with Vue after 5 years of react and so far I'm loving it for the most part. I'd say the things I like the most are 1) More of a framework than s library (official router, state, css-in-js, etc) and 2) automatic tracking of dependencies.
The worst part so far has been mostly related to the ecosystem. I find Next superior and better maintained than Nuxt, and the 2/3 transition situation looks like a really bad thing to me (sadly reminds me of the python 2/3 situation).
Also, it might have been caused by the specific teams I've been part of, but with react I always find there is a huge tendency to overengineer everything and make things a lot more complicated they should be in the name of purism or whatever reason. I consider myself as a more pragmatic person and Vue fits me a lot better overall.
The worst part so far has been mostly related to the ecosystem. I find Next superior and better maintained than Nuxt, and the 2/3 transition situation looks like a really bad thing to me (sadly reminds me of the python 2/3 situation).
Also, it might have been caused by the specific teams I've been part of, but with react I always find there is a huge tendency to overengineer everything and make things a lot more complicated they should be in the name of purism or whatever reason. I consider myself as a more pragmatic person and Vue fits me a lot better overall.
> (sadly reminds me of the python 2/3 situation)
It’s nowhere close to the python version debacle that I first came across back in 2012, which was already years old. Vue v3 is very new if not bleeding edge. And there are polyfills for new v3 features like the Composition API[0].
[0] https://github.com/vuejs/composition-api
It’s nowhere close to the python version debacle that I first came across back in 2012, which was already years old. Vue v3 is very new if not bleeding edge. And there are polyfills for new v3 features like the Composition API[0].
[0] https://github.com/vuejs/composition-api
What about security and upgrading?
I've heard there is some pain upgrading Vue, but there is definitely pain when upgrading React.
At the moment one of our previous React projects "npm install" gives 4000 security issues.
I've heard there is some pain upgrading Vue, but there is definitely pain when upgrading React.
At the moment one of our previous React projects "npm install" gives 4000 security issues.
Having used React for well over 5 years, I have no idea which upgrade pain you are referring to?
React might have stabilized in the meantime but a couple of years ago the upgrade pain definitely was there.
I moved a few years ago to Vue, and particularly with Vue3, I'm more than happy I switched.
> I think I do prefer working with JSX versus using html templates.
I thought I'd prefer JSX too, but I've come to much prefer Vue templates. Turns out that, while it's nice to have the "direct" control, I prefer seeing a full context that the template gives you, rather than having a lot of broken up parts, like JSX.
That said, it is slightly easier to refactor stuff in JSX.
> I think I do prefer working with JSX versus using html templates.
I thought I'd prefer JSX too, but I've come to much prefer Vue templates. Turns out that, while it's nice to have the "direct" control, I prefer seeing a full context that the template gives you, rather than having a lot of broken up parts, like JSX.
That said, it is slightly easier to refactor stuff in JSX.
I just started cobbling together a demo jquery app mess into a vue3 app yesterday, and lemme tell ya, the docs are great, and I even got from 0 to VueX in few hours today.
I'm impressed. Great work Vue team. I'm normally hesitant to adopt a new version of a library when learning and expected to get bitten by a few more things but so far seems mature, stable, and well done.
Edit: That said, I'm still personally not in love with the .vue file structure of mixing languages, but I get it.
I'm impressed. Great work Vue team. I'm normally hesitant to adopt a new version of a library when learning and expected to get bitten by a few more things but so far seems mature, stable, and well done.
Edit: That said, I'm still personally not in love with the .vue file structure of mixing languages, but I get it.
.Vue file is just a .HTML file.
The <script> and <style> tag default to Javascript and CSS languages in HTML but Vue's compiler allows you to use other languages like Typescript or Sass automatically (assuming you have the dependencies installed). You can also similarly have the code inline between the tags or point to a separate external file with the src="..." attribute.
The <script> and <style> tag default to Javascript and CSS languages in HTML but Vue's compiler allows you to use other languages like Typescript or Sass automatically (assuming you have the dependencies installed). You can also similarly have the code inline between the tags or point to a separate external file with the src="..." attribute.
I had much the same experience as you some 4 years ago. The exception was that I was heavily into Angular1 so Vue felt completely natural.
The one page vue file made a lot of sense to me off the bat, sort of implying that the component is a singular "encapsulated" entity, at least thats my own mental model. Turns out it was completely wrong but it worked.
The one page vue file made a lot of sense to me off the bat, sort of implying that the component is a singular "encapsulated" entity, at least thats my own mental model. Turns out it was completely wrong but it worked.
Isn't it basically encapsulated except the <style> ？
The style requires you a `scoped` to opt in isolation with element created by other component.
Which always make me wonder about why such default is selected.
The style requires you a `scoped` to opt in isolation with element created by other component.
Which always make me wonder about why such default is selected.
You can put the languages in separate files
https://v3.vuejs.org/api/sfc-spec.html#src-imports
https://v3.vuejs.org/api/sfc-spec.html#src-imports
I think my favourite thing about Vue 3 and the composition API is that VueX is essentially obsolete - you can manage your global state by calling real life functions.
This means instead of doing `dispatch("action")` you just call `action()`.
When using Typescript this is a godsend, as the action functions keep all of their type information.
This means instead of doing `dispatch("action")` you just call `action()`.
When using Typescript this is a godsend, as the action functions keep all of their type information.
I recently found Pinia[1] as replacement for vuex.
- full typing
- real life functions
- vue dev plugin support in store section
- mutations don't exist as separate idea
- also has api, so i wrote little plugin for state synchronization with local storage.
*Typography fix
1. https://pinia.esm.dev/
- full typing
- real life functions
- vue dev plugin support in store section
- mutations don't exist as separate idea
- also has api, so i wrote little plugin for state synchronization with local storage.
*Typography fix
1. https://pinia.esm.dev/
Wow. That's exactly what I thought Vuex would look like after after the Vue 3 release.
Definitely going to use it for my future project.
Definitely going to use it for my future project.
Just know what you're getting into, this is a new rather unknown framework with much fewer users and resources than Vue with VueX.
Read the docs, its from a Vue core team member and based on a future version of Vuex so you can easily migrate.
This is great. I feel the urge to delete all the brittle vuex crap from my vue3 ts projects right now.
Agreed. I do miss the devtool support of vuex though, but there is an RFC for a vuex 5 which will remedy that by fully embracing the composition API.
https://github.com/kiaking/rfcs/blob/vuex-5/active-rfcs/0000...
https://github.com/kiaking/rfcs/blob/vuex-5/active-rfcs/0000...
I'm the other way, as in the composition API has not clicked yet for me.
I read the doc and it makes sense but once in my project, I fail to see why I would use it, and yes I use vuex.
I probably need to make a Vue3 project from scratch without vuex to get it.
I read the doc and it makes sense but once in my project, I fail to see why I would use it, and yes I use vuex.
I probably need to make a Vue3 project from scratch without vuex to get it.
I really wonder if all developers that really like jsx + inline grapql aren't old school php4 developers that were writing php logic and sql queries in the view itself.
those were the days! I was really productive in that mode, although the quality of output was 1/10 at best. Buggy, insecure, etc. Don't even talk about maintainability! But, but! You got it done real fast and most of the time for some random website that doesnt handle money, who cares?
I got back to doing this for a brief moment a few years ago.
The effect was just brutally hideous, but it worked.
Makes one wonder if all this sophisticated tooling we're using currently is actually worth it.
The effect was just brutally hideous, but it worked.
Makes one wonder if all this sophisticated tooling we're using currently is actually worth it.
Beautiful code and abstractions dont mean nothing if you dont ship anything
> Buggy, insecure, etc. Don't even talk about maintainability!
> who cares?
Some people want their whole website to work for all visitors, so they care about bugs. Some people want their website to stay online and not to be misused by spammers and co, even for non-commercial sites, so they care about security. Some people want their website to evolve for years, so they care about maintainability.
Shipping junk code is delivering... Then a few years later, the owner wants to fix the bugs and add features, and they learn that no one wants to do it unless it's a full rewrite of the legacy code. They have to pay twice for the same features.
> who cares?
Some people want their whole website to work for all visitors, so they care about bugs. Some people want their website to stay online and not to be misused by spammers and co, even for non-commercial sites, so they care about security. Some people want their website to evolve for years, so they care about maintainability.
Shipping junk code is delivering... Then a few years later, the owner wants to fix the bugs and add features, and they learn that no one wants to do it unless it's a full rewrite of the legacy code. They have to pay twice for the same features.
Yes, but now they have earned four times the money and better understanding of the product for releasing a year earlier than the bug-free version. Twice the price could be cheaper than releasing a year later.
I may be exaggerating but, as always, engineering is all about trade-offs.
I may be exaggerating but, as always, engineering is all about trade-offs.
If there's few years of diff usually no matter the effort put in everyone will want to rewrite this, not only just because, but because tech ages so fast and everyone wants to work with just the latest.
JSX means you're actually programmatically generating your UI, rather than just injecting some stuff into a template and/or worse, bolting on logic by abusing the templating language. My mental model when using JSX is pretty much the opposite of that of the PHP 4 days of yore.
locality of behavior at its best :)
<script setup> is going to bring Vue closer to Svelte and solve the problems of long list of refs returned and .value's everywhere. When I checked an early draft last year I recall some limitations due to lack or inadequate support for non-setup component options, but from skimming https://v3.vuejs.org/api/sfc-script-setup.html I got the impression that most of the limitations have been ironed out. Really excited to try this out.
Edit: Actually it seems that a solution to .value's everywhere has been postponed and is currently discussed in https://github.com/vuejs/rfcs/discussions/369. The current iteration still requires unwrapping inside the script tag. The docs doesn't seem to make this clear since the examples are too simple...
Edit: Actually it seems that a solution to .value's everywhere has been postponed and is currently discussed in https://github.com/vuejs/rfcs/discussions/369. The current iteration still requires unwrapping inside the script tag. The docs doesn't seem to make this clear since the examples are too simple...
<script setup> looks awesome, makes components using the composition API look way more approachable IMO. I did a side project in svelte and really enjoyed the component layout, and have missed that when working in other frameworks.
I was really excited for Vue3 and constantly being told at the Austin VueConf that it will be backwards compatible. But reality was very very different.
There are a bunch of breaking changes to Vue 3 that will require code changes, and whilst the vue compat package is meant to alleviate some of that it was only released as of v3.1 and still does not handle all the breaking changes. Some of these breaking changes also seem like they could have been been a good addition and not a full breaking change. Consider the v-model changes, why change the underlying events? You could have it work both the old and new way and log a deprecation warning for the old way. Give engineers more time to fix the code as they see these issues with out breaking.
Probably the biggest pain point I have hit with moving to v3 is the state of vue-test-utils, it is still in RC. Honestly I would have loved to seen this released in lock step with Vue, I mean it really should if it is how you are meant to unit test your components.
That being said obviously a lot of my pain is coming from v2 to v3 I imagine being green field the experience would be fantastic. I still really love using Vue just the upgrade has left a bit of a sour taste in my mouth.
(edit formatting)
There are a bunch of breaking changes to Vue 3 that will require code changes, and whilst the vue compat package is meant to alleviate some of that it was only released as of v3.1 and still does not handle all the breaking changes. Some of these breaking changes also seem like they could have been been a good addition and not a full breaking change. Consider the v-model changes, why change the underlying events? You could have it work both the old and new way and log a deprecation warning for the old way. Give engineers more time to fix the code as they see these issues with out breaking.
Probably the biggest pain point I have hit with moving to v3 is the state of vue-test-utils, it is still in RC. Honestly I would have loved to seen this released in lock step with Vue, I mean it really should if it is how you are meant to unit test your components.
That being said obviously a lot of my pain is coming from v2 to v3 I imagine being green field the experience would be fantastic. I still really love using Vue just the upgrade has left a bit of a sour taste in my mouth.
(edit formatting)
Vue 3 has definitely been a terrible launch for such a large framework. Many of the official supporting libraries are out of sync, the devtools don't work and require a manual beta install, and other projects like nuxt.js seem to be in a perpetual delay. It's unfortunate as Vue was known for having a strong lead and consistent releases but it's too much of a mess right now.
Sadly remembers me a lot of python 2 to 3 transition. Some companies never upgraded, and never will (left one because of this, among other things). Some others facing such a big and difficult change took it s step forward and moved to slowly transition to other languages. Hope this isn't as bad, but looks too similar to me.
I'm really tired with React recently so I was looking at the competition and really liked Svelte. For those that know Vue, how does Svelte stack up with it?
Obviously the Vue ecosystem is much larger but other than that, personally, I much prefer Svelte.
I used Vue 2 as my main framework for some years, and still maintain a couple of projects with it.
I'm now focused on Svelte. The performance is better, the bundle sizes are much smaller, and most importantly you write a fraction of the code to achieve the same thing.
Svelte also has a reactive primitive (they call them stores) which allows you to model pretty much anything with reactivity similar to what you'd do with MobX but with a fraction of the cost. I believe Vue 3 also has this now but uses Proxy which is not supported in older browsers.
I used Vue 2 as my main framework for some years, and still maintain a couple of projects with it.
I'm now focused on Svelte. The performance is better, the bundle sizes are much smaller, and most importantly you write a fraction of the code to achieve the same thing.
Svelte also has a reactive primitive (they call them stores) which allows you to model pretty much anything with reactivity similar to what you'd do with MobX but with a fraction of the cost. I believe Vue 3 also has this now but uses Proxy which is not supported in older browsers.
I'm completely unqualified to offer anything. The last time I tried React was four years ago, I've never used Svelte, and I'm currently using Vue 2. Vue 3 supposedly fixed a lot of the most surprising/annoying things about Vue 2.
But I'll say this. Thank goodness I don't consider myself a frontend dev.
The selling point of Vue was that it's supposed to be less of a learning curve compared to React. It's "closer" to regular HTML and JS. Except it's not really. You still should not mutate component "properties". If you ask anyone any question about anything, the answer is "use Vuex"- even if it has nothing to do with what you're trying to accomplish. There is definitely a learning curve around its reactivity model (this has supposedly improved with version 3). And I found some stuff just awkward, e.g., Vue components have lifecycle hooks that "support" async/Promises, but the lifecycle doesn't await the Promises, so I had some initialization that had race conditions and I didn't realize why/how.
I don't know if that's good or not, honestly. I just know that Vue2 has certainly not made me enjoy frontend work any more than I did before (which wasn't much).
But I'll say this. Thank goodness I don't consider myself a frontend dev.
The selling point of Vue was that it's supposed to be less of a learning curve compared to React. It's "closer" to regular HTML and JS. Except it's not really. You still should not mutate component "properties". If you ask anyone any question about anything, the answer is "use Vuex"- even if it has nothing to do with what you're trying to accomplish. There is definitely a learning curve around its reactivity model (this has supposedly improved with version 3). And I found some stuff just awkward, e.g., Vue components have lifecycle hooks that "support" async/Promises, but the lifecycle doesn't await the Promises, so I had some initialization that had race conditions and I didn't realize why/how.
I don't know if that's good or not, honestly. I just know that Vue2 has certainly not made me enjoy frontend work any more than I did before (which wasn't much).
The big gotcha for Vue2 was the performance when you wanted to display a list of like 10,000 things. I like to tinker with data and a lot of my day is spent on an sql prompt inside of emacs watching results sets of 1,000 rows or 50 columns just fly by so I can search them visually. Having to remember to "freeze" things for performance or create simpler "views" of the model I'm playing with is sometimes jarring.
This tripped me up recently too. Somehow I'd got it in my head that Vue (2) would selectively re-render sub-trees within a given component if no dependencies within the tree had changed. I had a table functioning as a datasheet (not even that big—about 20 columns by 100 rows) that was absolutely chugging and I couldn't work out why, because nothing within the table was changing very often. Extracted it to its own component and all the performance issues went away.
I love svelte. (I'm not a vue user). But my biggest gripe with it is that you can't create multiple components in a single file like how you can in react.
I remember seeing a FR for it in GitHub for it. But can't remember where they landed on it.
I remember seeing a FR for it in GitHub for it. But can't remember where they landed on it.
That sounds like a pretty minor gripe and really more of a matter of taste. I believe I read the creator of Svelte say he prefers it this way because it makes creating Web Components out of a svelte component more straight forward.
i wonder if there is an editor that lets your places multiple files like tiles in the same buffer/window so it feels like the same file to you as an editor?
I am sure emacs can be made to do this, but I wonder if vscode has a plugin for it...
I am sure emacs can be made to do this, but I wonder if vscode has a plugin for it...
We've been pretty happy with Vue 2.6 and haven't had the motivation to take the leap.
I did try it and even though it's advertised as somewhat backward compatible it did break lots of things, which was totally expected and it's a major release.
Also we couldn't figure out a lot of things, like how can I access the $children like before, why does everything show Object proxy in console, etc. Posting on SO and forums also didn't yeild much help since everyone is still discovering it too I guess.
So in the end we decided why fix something which ain't broken for now. Vue 2 still kicks ass performance wise and is really easy to use.
I did try it and even though it's advertised as somewhat backward compatible it did break lots of things, which was totally expected and it's a major release.
Also we couldn't figure out a lot of things, like how can I access the $children like before, why does everything show Object proxy in console, etc. Posting on SO and forums also didn't yeild much help since everyone is still discovering it too I guess.
So in the end we decided why fix something which ain't broken for now. Vue 2 still kicks ass performance wise and is really easy to use.
There's a migration build available which will allow you to migrate more gracefully, should you choose to change your mind. (It runs the Vue 3 runtime with Vue 2.6 + 3 APIs.)
I personally love Vue 2.6. I'm not a huge fan of the composable API.
In case you're not aware - the Composition API is entirely optional and will most likely remain that way. It brings more flexibility but also adds complexity and makes components less readable.
There is gonna be a Vue 2.7 that backports a lot of 3 functionality (particularly the Composition API, which is available in 2.x as a plugin currently but with caveats), so I don't think there's any pressure to upgrade even from the Vue team themselves.
I believe `npm install vue` even still gives you Vue 2.
I believe `npm install vue` even still gives you Vue 2.
When I am just yet another dev in the team, I use whatever the FE team decided upon, however on my own projects I use Web Components with lithtml.
The browser underlying stack is always going to be there regardless of what is fashionable to wrap around it.
The browser underlying stack is always going to be there regardless of what is fashionable to wrap around it.
That’s not necessarily a belief that holds true universally. Plenty of developers have found that React and JSX are two technologies that have beautifully matured outside of their initial home in the web browser ecosystem.
To use your phrasing, React and JSX are always going to be there regardless of what is fashionable for them to be wrapped around.
To use your phrasing, React and JSX are always going to be there regardless of what is fashionable for them to be wrapped around.
If you mean React Native, many of those devs are now adopting Flutter fashion, at least from the iOS and Android corners of the Internet I happen to move around.
Cordova => React Native => Flutter => who knows
Cordova => React Native => Flutter => who knows
Flutter looks very exciting, iff your team is willing to switch away from JavaScript. I’ve always been excited about Dart as a better JavaScript.
I was looking into using v3 it seems like most libraries only work for v2
Did you try to migrate with Vue 3.1 and it's compatibility layer?
It helped me a lot.
It helped me a lot.
I quit my tech job in 2020 to learn new technologies and build my own startup - I made a HUGE bet on Vue and kinda regret it.
In the first half of 2021, I dove deep into Vue, Vuex, Nuxt.js (basically Next.js), Gridsome (basically Gatsby.js), and even coded a startup idea using Vue + Electron + FFmpeg[0] before moving to React. Three main reasons for this switch:
- Community Support: React has better support for lots of JS libraries. For example, I made a markdown editor which required the use of CodeMirror and the React NPM library for that was updated 1 year ago while the Vue library was updated 3 years ago. There's a lot of international support for Vue and some of the NPM libraries (like the CodeMirror one) are partially (or fully) documented in Chinese so this is a drawback as well.
- Typescript: Vue 3 is built from the bottom up with TypeScript but it was only released in September 2020. Most of the community thinks Vue 3 is better than Vue 2 in TS support, but still not as good as React. Additionally, since TS support has only recently been offered, libraries (like Nuxt.js) have not been updated with TS support.
- Job Market: React is the clear winner whether you are building a startup (and looking to hire developers), or want to join a company (at least in the US).
I think Vue has lots of potential to improve in all three areas but it's just not there right now. You can see my full thoughts on YouTube[1].
[0] https://www.reddit.com/r/webdev/comments/ohbl6i/i_made_a_des...
[1] https://www.youtube.com/watch?v=009-6j5ewDM
In the first half of 2021, I dove deep into Vue, Vuex, Nuxt.js (basically Next.js), Gridsome (basically Gatsby.js), and even coded a startup idea using Vue + Electron + FFmpeg[0] before moving to React. Three main reasons for this switch:
- Community Support: React has better support for lots of JS libraries. For example, I made a markdown editor which required the use of CodeMirror and the React NPM library for that was updated 1 year ago while the Vue library was updated 3 years ago. There's a lot of international support for Vue and some of the NPM libraries (like the CodeMirror one) are partially (or fully) documented in Chinese so this is a drawback as well.
- Typescript: Vue 3 is built from the bottom up with TypeScript but it was only released in September 2020. Most of the community thinks Vue 3 is better than Vue 2 in TS support, but still not as good as React. Additionally, since TS support has only recently been offered, libraries (like Nuxt.js) have not been updated with TS support.
- Job Market: React is the clear winner whether you are building a startup (and looking to hire developers), or want to join a company (at least in the US).
I think Vue has lots of potential to improve in all three areas but it's just not there right now. You can see my full thoughts on YouTube[1].
[0] https://www.reddit.com/r/webdev/comments/ohbl6i/i_made_a_des...
[1] https://www.youtube.com/watch?v=009-6j5ewDM
I've been working in TypeScript with Vue 2, and Nuxt.js for over 2 and a half years now. They might not be built in TypeScript, but they support them very well.
I've also never met a library that couldn't be integrated into Vue easily, whether through an official solution, a 3rd-party library or analogue, or simply integrating it yourself. I will give you that there are certainly more libraries catering to React specifically.
I've also never met a library that couldn't be integrated into Vue easily, whether through an official solution, a 3rd-party library or analogue, or simply integrating it yourself. I will give you that there are certainly more libraries catering to React specifically.
How much training does a React developer need to become productive with Vue? Same language. Same domain.
I like vue, but the last time I used it with typescript it was pretty clunky.
React has much better typescript support, as it type checks all props, even complex objects.
React has much better typescript support, as it type checks all props, even complex objects.
The typescript support has immensely improved in vue3. The entire vue3 codebase is even written in typescript.
I tried vue3 and all the associated stuff like vuex and the router last month. Vuex especially has extremely poor support even if it is written in TS. I believe the next version will have better support for TS. Just writing vue wasn't much of an issue but there's not enough support for it in the templates. I believe there's VSCode extensions that help
Vuex with proper TS support would be really key as the domain model is often in the store. Now that the Vuex release has been behind Vue3 for a while is there any alternative to Vuex?
https://github.com/posva/pinia. Vue community feedback is very positive (I haven't personal experience yet)
Which version of Vue do you mean by “the last time”?
The combination of Vue composition API and setup scripts is really awesome. It reduces a lot of boilerplate for many common scenarios.
If you are also using GraphQL, I recommend taking a look at the new composition API support in Vue Apollo [1] as well. This post [2] summarizes how this integration looks like in practice for a typescript project.
[1] https://v4.apollo.vuejs.org/guide-composable/
[2] https://lorefnon.me/2021/08/08/Vue-composition-api-and-type-...
If you are also using GraphQL, I recommend taking a look at the new composition API support in Vue Apollo [1] as well. This post [2] summarizes how this integration looks like in practice for a typescript project.
[1] https://v4.apollo.vuejs.org/guide-composable/
[2] https://lorefnon.me/2021/08/08/Vue-composition-api-and-type-...
The js-framework-benchmark used here is really hard to run. I'm not a javascript programmer, I'm always baffled that any of the command listed in the README page always end up in error. I even re-install a new version nodejs but can't make the benchmark run.
Feel free to post any issues to the github repo and I'll try to help. Building is indeed not trivial, since there are so many languages and tools and thus builiding is currently only fully supported on linux (rather a docker linux build). With a few exceptions building on windows and OSX works.
A simple workaround is to delete the folders of those implementations that cause errors.
Which errors?
Can anyone comment on how best to use Vue 3 with TypeScript to avoid as many runtime errors as possible? I know you can use JSX/TSX with Vue but it doesn't seem a focus.
I've worked on projects that use Vue 2 HTML templates + TypeScript before and a big chunk of the bugs are clustered around where TypeScript is interacting with the HTML templates.
I've worked on projects that use Vue 2 HTML templates + TypeScript before and a big chunk of the bugs are clustered around where TypeScript is interacting with the HTML templates.
The Vue community is not against JSX. I know many Vue devs that use it and it works great. Have you encountered any problems with vue+jsx/tsx?
That's good to know. Do you know of any open source Vue + JSX + TypeScript projects I can browse for examples? Or good docs on using Vue with JSX? The official docs still look brief about this with the focus being on HTML templates?
Are there any problems with Vue + JSX + TypeScript when you want to use Vue UI component libraries that use Vue + HTML? Will you be giving up any static type checking here?
Are there any problems with Vue + JSX + TypeScript when you want to use Vue UI component libraries that use Vue + HTML? Will you be giving up any static type checking here?
The best example I ever saw, and a great UI framework/component library on top of it, it's NaiveUI - www.naiveui.com . The code is all in JSX + Typescript, I didn't find a single component with html templates.
use vue-tsc package + Volar VSCode plugin to get type checking in templates. works great!
Awesome! Excited for the web component stuff.
I’ve been waiting for <style> binds for a while now. I’m happy to see they finally added it.
In Vue 2, you'd just write this as:
<span :style="{ color }"> Color is: {{ color }}</span>
Simpler than this new syntax, for this particular example.
<span :style="{ color }"> Color is: {{ color }}</span>
Simpler than this new syntax, for this particular example.
What's advantage of VueJS over Svelte ?
Larger community and higher adoption rate among companies. If you run into a weird issue you’re more likely to find someone who’s had the same issue and solved it. There are plenty of established best practices and patterns to follow. Good learning materials and documentation. More supporting packages and libraries - usually people build for both React and Vue, it’s rarer to see Svelte.
I've used both professionally (and React as well).
I can't stand Vue (but haven't tried newer versions).
The reason is that Vue is miserable to debug in the browser. It is really clever to use proxies for values but then you have to make an extra click to see the actual value and it really slows you down. Recreating the state of the app inside your head can't be done quickly because you have to manually evaluate everything you need to do that.
Vue also uses it's own DSL that generates a bunch of code under the hood, which confuses the browser.
These things could have changed in recent versions of Vue but I had such a poor experience that I would never go back.
I had to respond to this comment because the reason you have fewer libraries for Svelte is that Svelte is just JavaScript. It is trivial to use any JavaScript library because it requires no integration wrapper to convert that library to Svelte. Just use it as you would without Svelte. It's a much better experience than Vue or React can ever give you.
I can't stand Vue (but haven't tried newer versions).
The reason is that Vue is miserable to debug in the browser. It is really clever to use proxies for values but then you have to make an extra click to see the actual value and it really slows you down. Recreating the state of the app inside your head can't be done quickly because you have to manually evaluate everything you need to do that.
Vue also uses it's own DSL that generates a bunch of code under the hood, which confuses the browser.
These things could have changed in recent versions of Vue but I had such a poor experience that I would never go back.
I had to respond to this comment because the reason you have fewer libraries for Svelte is that Svelte is just JavaScript. It is trivial to use any JavaScript library because it requires no integration wrapper to convert that library to Svelte. Just use it as you would without Svelte. It's a much better experience than Vue or React can ever give you.
> The reason is that Vue is miserable to debug in the browser. It is really clever to use proxies for values but then you have to make an extra click to see the actual value and it really slows you down. Recreating the state of the app inside your head can't be done quickly because you have to manually evaluate everything you need to do that.
With https://chrome.google.com/webstore/detail/vuejs-devtools/nhd... ???
With https://chrome.google.com/webstore/detail/vuejs-devtools/nhd... ???
I don't have a similar extension installed for Svelte and can do everything you described without an extension.
Does this work on Firefox, I recently switched to that?
The React extension was/is great, I assume this one for Vue is as well. But, it wasn't there when I was doing Vue and the out of box experience of Vue was not good because of it.
Does this work on Firefox, I recently switched to that?
The React extension was/is great, I assume this one for Vue is as well. But, it wasn't there when I was doing Vue and the out of box experience of Vue was not good because of it.
I would highly recommend the Vue browser extension. It makes the state/component hierarchy entirely transparent.
I wish people would stop saying things like "is just JavaScript". All these frameworks do fancy things with JavaScript, and they're all just as much JavaScript as each other. Also they _all_ use DSLs; Vue, react, and svelte.
I wish people would stop saying things like "is just JavaScript". All these frameworks do fancy things with JavaScript, and they're all just as much JavaScript as each other. Also they _all_ use DSLs; Vue, react, and svelte.
I really like Svelte and, as you point out, less community adoption doesn't really impact developer UX and productivity. Though, I have found that debugging is a bit painful, as the compiled JS code doesn't really map so well to the source, but debugging seems to be a problem with virtual DOM frameworks too
> Svelte is just JavaScript
I would argue very much against that: Svelte looks like Javascript, but behaves completely different. I don't think it's a bad thing, and quite enjoy it, but I don't think it's valid to call a language that happens to be valid JS syntactically actually JS.
> It is trivial to use any JavaScript library because it requires no integration wrapper to convert that library to Svelte. Just use it as you would without Svelte.
What do you mean by this? Of course you can use a standard JS library with any other framework! What makes Svelte different here?
I would argue very much against that: Svelte looks like Javascript, but behaves completely different. I don't think it's a bad thing, and quite enjoy it, but I don't think it's valid to call a language that happens to be valid JS syntactically actually JS.
> It is trivial to use any JavaScript library because it requires no integration wrapper to convert that library to Svelte. Just use it as you would without Svelte.
What do you mean by this? Of course you can use a standard JS library with any other framework! What makes Svelte different here?
"Svelte looks like Javascript, but behaves completely different"
No. This is complete and absolute FUD that you are spouting. Svelte adds a thin feature or two on top of vanilla Javascript. The rest is just JS exactly like you know it.
No. This is complete and absolute FUD that you are spouting. Svelte adds a thin feature or two on top of vanilla Javascript. The rest is just JS exactly like you know it.
This.
You can see what Svelte creates inside the tutorial. It's very simple JavaScript.
With React or Vue, you are pulling a bunch of stuff written in a DSL into their massive runtime. Try keeping all that complexity for that runtime in your head.
You can see what Svelte creates inside the tutorial. It's very simple JavaScript.
With React or Vue, you are pulling a bunch of stuff written in a DSL into their massive runtime. Try keeping all that complexity for that runtime in your head.
> "Svelte is just JavaScript"
All JS frameworks are just Javascript. What else would they be? The templates however are all specific DSLs, whether it's JSX, HTML with directives, or Svelte's own syntax. In the end these template just get compiled into a JS render function that takes in data and returns an HTML structure.
All JS frameworks are just Javascript. What else would they be? The templates however are all specific DSLs, whether it's JSX, HTML with directives, or Svelte's own syntax. In the end these template just get compiled into a JS render function that takes in data and returns an HTML structure.
No.
JSX is not JavaScript. React builds an entire system hidden from you that isn't the way JavaScript runs.
What abstraction are you thinking in? With Svelte I'm thinking in JavaScript. With Vue and React I'm thinking in hooks-land or whatever, and trying to understand a completely different virtual machine. There are some really brilliant ideas they have come up with, but the whole cloth experience isn't for me.
Vue is worse. Create an item inside the data attribute. Somehow that becomes available to computed functions. Somehow you can have that data attribute rely on parent attributes. None of that is the way JavaScript works without Vue on top. I'm so glad I don't have to remember those rules anymore.
You are correct they just compile into render functions. But the one Svelte produces is readable and the ones produced by Vue and React are a lot less so.
JSX is not JavaScript. React builds an entire system hidden from you that isn't the way JavaScript runs.
What abstraction are you thinking in? With Svelte I'm thinking in JavaScript. With Vue and React I'm thinking in hooks-land or whatever, and trying to understand a completely different virtual machine. There are some really brilliant ideas they have come up with, but the whole cloth experience isn't for me.
Vue is worse. Create an item inside the data attribute. Somehow that becomes available to computed functions. Somehow you can have that data attribute rely on parent attributes. None of that is the way JavaScript works without Vue on top. I'm so glad I don't have to remember those rules anymore.
You are correct they just compile into render functions. But the one Svelte produces is readable and the ones produced by Vue and React are a lot less so.
Yes, templates are different. That's why I said that they're "specific DSLs ... compiled into a JS render function"
Anyway there is no other abstraction. Hooks and composition APIs aren't magic, they're functions that you can write yourself. It's basic property change notifications but wrapped up in various levels of automation. Vue's object API can definitely seem messy but the new composition APIs in Vue 3 is standard JS syntax. Maybe it would be helpful to see the code yourself: https://github.com/vuejs/vue-next/tree/master/packages/react...
Anyway there is no other abstraction. Hooks and composition APIs aren't magic, they're functions that you can write yourself. It's basic property change notifications but wrapped up in various levels of automation. Vue's object API can definitely seem messy but the new composition APIs in Vue 3 is standard JS syntax. Maybe it would be helpful to see the code yourself: https://github.com/vuejs/vue-next/tree/master/packages/react...
I had heard things were improving. Thanks for sending providing a place where I can learn more.
(This is a complaint about React, but...) I really find hooks/effects to be pretty magical. Keeping track of how many times a hook/effect runs is really difficult for me. It looks so simple at first, but there is a lot going under the hood to figure out how often they run.
(This is a complaint about React, but...) I really find hooks/effects to be pretty magical. Keeping track of how many times a hook/effect runs is really difficult for me. It looks so simple at first, but there is a lot going under the hood to figure out how often they run.
You can use vue without npm, it has a build you can just drop in a script tag like you would with jquery.
Vue can also use the html as the component template like angulajs 1 used to allow. This makes it great for progressive enhancement and plays nice with server side based template frameworks.
Bottom line, vue scales up, but also scales down. You don't need to go full spa, you can hack a quick demo or make a one file tutorial and it's a bliss.
Also, maybe I missed it, but I don't think svelte has the concept of cached properties.
Vue can also use the html as the component template like angulajs 1 used to allow. This makes it great for progressive enhancement and plays nice with server side based template frameworks.
Bottom line, vue scales up, but also scales down. You don't need to go full spa, you can hack a quick demo or make a one file tutorial and it's a bliss.
Also, maybe I missed it, but I don't think svelte has the concept of cached properties.
> You can use vue without npm, it has a build you can just drop in a script tag like you would with jquery.
This is actually the biggest selling point IMO. I used Svelte instead of Vue purely for speed, but the benchmarks suggest Vue has made real progress here. Though, I'm not sure that in real applications a virtual DOM solution could ever be quicker than compiled code to update state. But in terms of developer UX, I think Vue has the easiest entry point, and it seems to have decent performance to boot
This is actually the biggest selling point IMO. I used Svelte instead of Vue purely for speed, but the benchmarks suggest Vue has made real progress here. Though, I'm not sure that in real applications a virtual DOM solution could ever be quicker than compiled code to update state. But in terms of developer UX, I think Vue has the easiest entry point, and it seems to have decent performance to boot
It's weird for this analysis to focus on the total size of the app. If a Svelte app has 100 components but a page only uses 10, then surely it's possible to only fetch these 10 components and defer the rest, right? This way the size of each page does not have to grow linearly with the size of the app. And the size of each page matters more than the total size of the app -- after all, we're on the web, not on mobile where users need to download the whole app before running it. Am I missing something here?
Considering the cut off point being very close to 10 (small components) - it all comes down to that Svelte, in practice, doesn't have any (significant) advantage bundle size wise.
rrally depends on your setup. When I used Vue Router it prefetched all the route components (so frst page load isn't affected but total bandwith is for the whole app), or if the app is a PWA, the whole app is downloaded in the background.
Apart from much larger community, Vue can be used without any compilation step. Import from CDN, define components through DOM and mount the app onto a specific div.
I know about real world projects that use Vue as a progressive enhancement on an existing PHP site. A weather card is, for example, being managed by Vue with it's reactivity engine.
I know about real world projects that use Vue as a progressive enhancement on an existing PHP site. A weather card is, for example, being managed by Vue with it's reactivity engine.
Riddle me this:
Developers, in general, despise XML. However, React which is the market leader and generally well-liked is littered with JSX/XML.
Developers, in general, despise XML. However, React which is the market leader and generally well-liked is littered with JSX/XML.
React developers don't deal with DTD or W3C Schema Definitions.
React developers aren't trying to make their documents into databases.
React developers aren't trying to turn their little blocks of markup into an ontology.
React developers aren't trying to make their documents into databases.
React developers aren't trying to turn their little blocks of markup into an ontology.
Solid js there
Can't understand if its sarcasm ablut their custom templating and other languages not being JS or genuine admiration haha
Or maybe a satirical reference to https://www.solidjs.com/
[deleted]
Anyone else have no idea SFCs were experimental? Whoops!
Whered you get that idea? They talk about FEATURES being experimental, not sfcs.
Whoops! Thanks. Pre coffee interpretation :)
Got a little chuckle when I realized their release names were based on anime. I love a good release naming scheme, adds a bit of fun, like Debian.
Vue is hands down the worst frontend framework I've had the displeasure of working with. The authors are trying to hard to write something "different" that in the end they've only managed to create a bunch of incidental complexity that you constantly have to deal with because of their design decisions. And then they keep trying to "fix" these problems by adding new features and more complexity.
Everything in Vue is more complicated. They went with this whole template language which is just a mess and has extremely poor tooling support. Everything is more complicated and harder to reason about. You literally need(ed) several files to write a single component which could be a couple of lines of JSX in React. Since the tooling support is so poor and it is so over-engineered, it is extremely difficult and bothersome to get it fully typed.
I'm just really glad that I don't have to work with it on a daily basis.
Everything in Vue is more complicated. They went with this whole template language which is just a mess and has extremely poor tooling support. Everything is more complicated and harder to reason about. You literally need(ed) several files to write a single component which could be a couple of lines of JSX in React. Since the tooling support is so poor and it is so over-engineered, it is extremely difficult and bothersome to get it fully typed.
I'm just really glad that I don't have to work with it on a daily basis.
I've had the exact opposite experience to this, completely and utterly the other way around with React being over engineered and complex, with Vue being the tidier and faster to deal with. I get that React is the industry 'standard', but having worked with both for a while now, Vue is to me hands down better.
Also with Vue, you have community driven direction, rather than FB. This is a big positive for me.
Also with Vue, you have community driven direction, rather than FB. This is a big positive for me.
> Also with Vue, you have community driven direction, rather than FB. This is a big positive for me.
That was one of the top selling features for me as well. Not to disparage the large amount of work and thought and care that's gone into work on React, but when the tooling lies primarily in the hands of one company I get those old-fashioned Oracle vibes.
That was one of the top selling features for me as well. Not to disparage the large amount of work and thought and care that's gone into work on React, but when the tooling lies primarily in the hands of one company I get those old-fashioned Oracle vibes.
What are you doing that causes you to need several files for a single component? I am working on a multi-page app using the TypeScript class decorators and .vue component files. I turned off most of the optional features (including babel), and it's just a single .vue file most most components. I configured the Webpack and TypeScript settings when I created the project and haven't had to do much since.
I've used Vue on several other projects and have enjoyed using it every time. I like that parts of the Vue framework are optional. Don't want the router or state management? Don't use it. The codebase is well organized, the output files are small and the app is performant.
I don't like all the dev dependencies you need to get going, but I have that same complaint about most other modern front-end frameworks.
I've used Vue on several other projects and have enjoyed using it every time. I like that parts of the Vue framework are optional. Don't want the router or state management? Don't use it. The codebase is well organized, the output files are small and the app is performant.
I don't like all the dev dependencies you need to get going, but I have that same complaint about most other modern front-end frameworks.
That's really interesting, I've worked with Vue since before 1.0, used it for various things (complex conventional SPAs, enhancing legacy server-rendered apps, even an IPTV GUI) and was always really satisfied.
Can you give a few examples of things that bug you?
Can you give a few examples of things that bug you?
That's interesting -- my experience has been 180° away. I agree that recent features have added complexity and made the barriers for newcomers a little higher, though.
At its core, however, everything just 'clicked', the templating works beautifully, and single-file-components are superb. I'll write React and Ember when necessary, but coming back to Vue is always a welcome relief.
I've lost count of the number of times I decided to start off writing what felt 'right' intuitively, and found things just worked first time. In that sense at least, there are echoes of Rails for me.
At its core, however, everything just 'clicked', the templating works beautifully, and single-file-components are superb. I'll write React and Ember when necessary, but coming back to Vue is always a welcome relief.
I've lost count of the number of times I decided to start off writing what felt 'right' intuitively, and found things just worked first time. In that sense at least, there are echoes of Rails for me.
I think you should swap Vue with React in this take, I'd agree with you 110% if you did that. React is the most over engineered tech I've ever worked with and if it weren't for excellent IDE support a la TS etc would be a nightmare to use on a daily basis. Also Vue 3 has great support for TS, 2 not so much. I can't see myself doing any project without Vue, it's literally plug and play and by far easier to grok and use than React.
templates are still stringly-typed, aren't they?
And that whole extra language just for templates is annoying, and unnecessary. I don't want a v-else-if="level ==== 6", because I'm going to make typos, and I want the ability to refactor code in the future without painstakingly reviewing every string in the codebase.
How good is the jsx integration in practice? It's there, but the vue docs recommend against it, without going into details of the motivation.
And that whole extra language just for templates is annoying, and unnecessary. I don't want a v-else-if="level ==== 6", because I'm going to make typos, and I want the ability to refactor code in the future without painstakingly reviewing every string in the codebase.
How good is the jsx integration in practice? It's there, but the vue docs recommend against it, without going into details of the motivation.
I agree with the template sentiment but it's really hard to defend the webs of ternary operator nests I've seen in jsx Vs v-*
You're free to use if's instead, if you prefer; that's more similar to v-if's.
I agree that ternaries aren't the prettiest of language idioms, but if clearly formatted (e.g. eslint defaults are fine), I think it's mostly a question of getting used to it. I mean, the tricky but also common && and || are almost certainly worse for this, I suppose?
I agree that ternaries aren't the prettiest of language idioms, but if clearly formatted (e.g. eslint defaults are fine), I think it's mostly a question of getting used to it. I mean, the tricky but also common && and || are almost certainly worse for this, I suppose?
I'm baffled by your comment like some of the others. If you swap Vue for React it'd make a lot more sense.
Also, I think I do prefer working with JSX versus using html templates. I prefer that close coupling of JS logic and JSX presentation.
The most appealing thing about Vue is that it seems to be more of a framework, maybe somewhere in the middle between base React/ReactDOM and Next.js.