I wrote this article back in 2017. A lot has changed since then. If anyone has any questions I'd be happy to answer them. We now use Vue in our data science startup meltano.com.
What would you change about or add to the article now?
How we do Vue: one year later (2017)
21–30 of 159 posts
Re: How we do Vue: one year later (2017)
#22I love Vue and use it wherever I can. I used to feel iffy about the angular-y syntax and how CSS JS and HTML all often live in the same file, but I've come to love the way that coupling embraces the component architecture: "This file has one (1) self-contained component that does this one thing". That plus the built-in routing, global state management, and scoped CSS/SCSS made me never want to go back to React.
The one thing that keeps React in my toolkit: React-Native development with Expo is truly an excellent experience. Getting everything going without having to fire up visual studio or Xcode is a dream. I tried using NativeScript with Vue and it just wasn't the seamless "3 NPM commands and you're done"
Re: How we do Vue: one year later (2017)
#23I write Vue every day, in a large application. Only small bits use VueX. Of all the frameworks I've used, it's brilliant because it hardly takes any thinking away from the business logic, so I'm not bogged down, it stays OUT of my way, and it's rock solid. I HIGHLY recommend it, and this is from someone doing web since 1997.
Curious how do you deal with state management in large application if you are only using small bits of vuex. I am writing this vue application where one component has become so huge that I would like to break it into smaller components but then passing data around in props is a nightmare. So I then need to look into something like vuex. So how do you get away from that in a large app ?
Re: How we do Vue: one year later (2017)
#24I love Vue and use it wherever I can. I used to feel iffy about the angular-y syntax and how CSS JS and HTML all often live in the same file, but I've come to love the way that coupling embraces the component architecture: "This file has one (1) self-contained component that does this one thing". That plus the built-in routing, global state management, and scoped CSS/SCSS made me never want to go back to React. The o…
Check out quasar-framework
Re: How we do Vue: one year later (2017)
#25The revolving door of front-end frameworks is somewhat irritating; spending a nontrivial amount of time in Angular (1), then React, and now Vue. I wonder what the next one will be
Re: How we do Vue: one year later (2017)
#26I write Vue every day, in a large application. Only small bits use VueX. Of all the frameworks I've used, it's brilliant because it hardly takes any thinking away from the business logic, so I'm not bogged down, it stays OUT of my way, and it's rock solid. I HIGHLY recommend it, and this is from someone doing web since 1997.
Curious how do you deal with state management in large application if you are only using small bits of vuex. I am writing this vue application where one component has become so huge that I would like to break it into smaller components but then passing data around in props is a nightmare. So I then need to look into something like vuex. So how do you get away from that in a large app ?
It depends a lot on what you're hoping to do. There's a happy medium for a large app between "every component manages their own state/props and those of their children" and "every component is a stateless vessel for VueX data".
I think if you're at the point where "passing data around in props is a nightmare" that's the pain point that VueX is meant to resolve, and it should feed into the solution. But following the principle of "components should manage their state without VueX if it's easy/convenient for them to do so" is a good way to avoid the global state becoming too unwieldy.
Re: How we do Vue: one year later (2017)
#27I (and an extended team) have built multiple large-scale Vue.js apps, including a full rewrite of a solar power plant modeling tool (First Solar) from ES5/Angular to ES6/Vue. I am continually reassured of our bet on Vue.js over React. I'm happy to answer questions from my experience!
Re: How we do Vue: one year later (2017)
#28Earlier quoted context omitted.
Have you done any work with Vue and Typescript? We're just starting out with Vue. But my understanding was that TypeScript is a first class citizen in the new version of Vue.
TS isn't a first-class citizen in 2.x, and you'll need to go through a couple of awkward maneuvers to prevent Vue from negating many of the benefits of TS, but it can absolutely be done. This sample project sums it up nicely: https://github.com/Armour/vue-typescript-admin-template
You're right. Thanks for the link that's helpful.
Looks like 3.x plans to be built on typescript but I'm not sure if this article is still relevant, I very recently started paying serious attention to Vue.js so I'm playing a game of drink from a fire-hose. https://hub.packtpub.com/vue-js-3-0-is-ditching-javascript-f...
Re: How we do Vue: one year later (2017)
#29The revolving door of front-end frameworks is somewhat irritating; spending a nontrivial amount of time in Angular (1), then React, and now Vue. I wonder what the next one will be
You say "revolving" as if users have been forced to move from one to the other, but all three are current and legitimate choices, no?
Re: How we do Vue: one year later (2017)
#30I write Vue every day, in a large application. Only small bits use VueX. Of all the frameworks I've used, it's brilliant because it hardly takes any thinking away from the business logic, so I'm not bogged down, it stays OUT of my way, and it's rock solid. I HIGHLY recommend it, and this is from someone doing web since 1997.
Vue's templating engine, honestly, seems somewhat poorly thought-out.
The usual way of writing it errs on the side of HTML over JS, using quote marks awkwardly to enclose a statement rather than JSX's more sensible curly brackets. It makes it harder to visually parse, and it's sometimes annoying to not be able to use one type of quote marks unescaped within the statement.
Overall, this is one of many ways in which Vue (like Angular) seems like HTML with functionality tacked on, as opposed to React, which is closer to idiomatic JS. I've used both extensively and I don't think I can recommend Vue over React anymore -- unless you're, say, prototyping and looking to build an app entirely on the client, with no build step, where Vue really shines. Or unless you're doing something HTML-centric, like converting a static site.