28 ms·

How we do Vue: one year later (2017)

309 points by NicoJuicy 8y ago

stefan_ 8y ago
When you have to hassle the backend guys because querying <<100 comments is slow, is that the point where you stop and ask "what are we doing here".
- hombre_fatal 8y ago
  To be fair, they pointed out additional motivations to move to Vue like making the client-side UX more maintainable and improve client-side performance. Also, for all we know their server-side Rails+Haml stack took <50ms to query the database + render the comments, but they still wanted to factor that out of the initial page load to improve TTI.
- cabaalis 8y ago
  I thought the same thing. > Surely you could query the DOM for this. A better solution, in this case, is to let the backend developers mark the last user comment in the JSON they return. Backend developers have direct access to the database, which means they may be able to optimize the code. Then no client-side work has to be done at all, in this case. Look, I know what I am, I'm no fancy-pants silicon valley guru here. But what is described in this example is primarily a client-side function. So I think the wording for this is "a different solution" at minimum. Better? Meh. Will that new backend query ever serve any purpose other than facilitating this frontend feature? Perhaps instead of adhering to a "let's not query the DOM" at all costs, ask yourself what exactly you are complicating and for what gain.
heyheyhey 8y ago
Might wanna add a [2017] tag in the title.
- sctb 8y ago
  Updated. Thanks!
Kiro 8y ago
> Just use VueX That's the problem with large-scale Vue apps. Vue is awesome until you need to use VueX, after which it just becomes an inferior version of React + Redux.
- pietrovismara 8y ago
  Ever tried vuex-module-decorators? Add that to the recipe and using vuex with Typescript becomes really easy and a pleasure to write.
- chadbaud 8y ago
  Could you expound? I feel the exact opposite, and I'm genuinely curious why you feel that way.
- Tade0 8y ago
  Inferior? How exactly? I found Redux to be highly over-engineered in contrast to Vuex which is a lot like MobX - easy to use, yet powerful.
  - nerdwaller 8y ago
    This is my thought as well, adding that it feels like way less boilerplate due to the integration with the underlying framework
  - wp381640 8y ago
    > highly over-engineered Redux is a couple hundred lines of code. A good way to learn the pattern it to reimplement it yourself - which you could probably do in ~100LOC if you ignore the helper functions
    - enraged_camel 8y ago
      >>Redux is a couple hundred lines of code. That's not a refutation of the parent's statement.
    - Rapzid 8y ago
revskill 8y ago
I tried Vue 2 years ago and wrote a tiny wrapper around Select2 with Vue using jquery https://github.com/revskill10/vue-select2/blob/master/src/Select2.vue https://github.com/revskill10/vue-select2/blob/master/src/Se... It just works.
jakecodes 8y ago
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.
- bartq 8y ago
  what are worst parts of vue for you?
  - jakecodes 8y ago
    I can't think of any bad parts of Vue off the top of my head. I really do enjoy the whole library. Although I think slots is a harder concept for most to grasp then it needs to be.
- bargl 8y ago
  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.
  - jakecodes 8y ago
    I haven't done much with TypeScript. But I always hear great things.
  - m_fayer 8y ago
    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 https://github.com/Armour/vue-typescript-admin-template
    - bargl 8y ago
      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-for-typescript-what-else-is-new/ https://hub.packtpub.com/vue-js-3-0-is-ditching-javascript-f...
arendtio 8y ago
I used riot.js for a few years and was quite happy with it. Sadly it had a few misconceptions (e.g. the parent.parent.parent... problem) which could have been changed easily. But as the lead dev wasn't very cooperative I switched to the closest alternative: Vue. I don't have enough experience with Vue yet to judge it, but given how similar Vue and riot.js are I hope that it gives me the same productivity without those broken bits and hopefully a better community interaction.
- tribby 8y ago
  I also came to vue from riot, and now find myself much more productive with vue. stick with it. and check out nuxt for out of the box server-side rendering, another thing that was a bit tricky with riot.
keyle 8y ago
I 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.
- odorousrex 8y ago
  >I HIGHLY recommend it, and this is from someone doing web since 1997. I started in 97 as well, and cannot recommend Vue enough. I've done React, Angular 1 & 2, and I keep coming back to Vue. I always feel like with React/Angular I'm conforming to work how they want me to work. (Esp. Angular - React is more forgiving). Whereas Vue is just a complement to the way I already work. I can use as much or as little of it as I wish. A hearty endorsement indeed.
  - tashoecraft 8y ago
    So for personal projects or for small apps I think that’s great. But when I think about projects that need to live on well after I’m around, then they shouldn’t work the way I work, they should be in standard way that anyone can come into and know what’s going on. That jumping applications between teams feels simple. This is why I like angular quite a bit, it’s not whatever the dev decided to do. It doesn’t include a whole bunch of small libraries of questionable support.
    - wwweston 8y ago
      It's been a few years since I checked in with Angular because the projects I worked on were distinctively unpleasant, so what I'm about to say may not be current. But at the time, the wide variation in project structure (and available opinionated approaches) and libraries/tooling of questionable support were definitely part of the problem (though certainly not the full extent).
      - tashoecraft 8y ago
Townley 8y ago
I 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"
- digitaltrees 8y ago
  Check out quasar-framework
  - ceejayoz 8y ago
    Or Ionic, which now supports Vue (and others) and is IMO substantially more polished.
    - digitaltrees 8y ago
      quasar lets you build a responsive web app, and iOS and Android apps, where ionic focuses on mobile, not bad just different. Also, Ionic’s support for vue is really new and not as well documented.
- Kihashi 8y ago
  > I tried using NativeScript with Vue and it just wasn't the seamless "3 NPM commands and you're done" I had a similar experience. I will say, though, that the nativescript-vue plugin is now officially supported by Telerik rather than just a community plugin, so it should theoretically be getting easier to use.
asdffdsa 8y ago
The 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
- CharlesW 8y ago
  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?
  - perlgeek 8y ago
    angular.js is not a viable choice anymore (no clear statements of how long it's going to be supported), causing huge migration costs for everyone involved.
    - Bahamut 8y ago
      Angular 7 is though.
- parthdesai 8y ago
  React and Vue have 6.25 and 1.01 weekly downloads respectively. As of now, they are not even in the same league.
  - KaoruAoiShiho 8y ago
    Using NPM stats is just not correct. I believe React to be about 2.5x larger than Vue rather than 6x.
    - parthdesai 8y ago
      And why would that not be correct, and what are the sources of your number?
      - 8y ago
seancoleman 8y ago
I (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!
- nnq 8y ago
  Q1: Do you use Vue alone/minimal, or Vue+Vuex? Q2: Did you compare Vue vs React or Vue+Vuex vs React+Redux? What do you think of "React without Redux"? Q3: What advantages would Vue bring over react in your context? The way I see it, Vue could lower TCO for web apps by allowing more junior developers or web-developers/designer-developers to make smaller UI changes instead of needing more senior/expensive frontend-engineers or full-stack-engineers-withs-strong-js-skills that React seems to require? (I mean your project doesn't seem like the one that would benefit from making the codebase easier for junior devs to work in, but at the expense of it getting more complicated for senior devs as the overall logic is more complicated in Vue...)
Bizarro 8y ago
I started out in SPA development a little over 3 years ago. Before that I was very inexperienced with front-end development, and we used ASP.NET MVC with JQuery sprinkled around. I realized that this was going to be a spaghetti nightmare, so decided that I had to choose a real front-end framework. At that time, Angular 2 was in a alpha,pre-alpha state, React (JSX) seemed to weird, I didn't know anything about Vue, so I chose Aurelia. At that time Aurelia was going to be the next big thing, but I believe there was a series of technical missteps with Aurelia and I saw that it wasn't going to go anywhere, so changed direction to React. By the time I started with React, I had months of front-end development under my belt, so I felt more comfortable with it. It had/has a large community with plenty of resources, but I started running into problems with the whole a-la-carte nature of the React ecosystem. At first, I used a little Mobx for state management, but at that time I had what would be considered several mini-SPA as I was migrating away from server side MVC. After a while I decided to migrate to Redux since that seemed to be the canonical state management solution for React. Redux turned out to be a productivity nightmare. Redux has its own ecosystem of libraries - Redux Promise, Redux Saga, Redux Forms, etc..The whole complexity was turning me off. Not only that, but other 3rd party libraries like React Router was a big bummer. There is 15 viable styling solutions in the React ecosystem, and the ones I played around with me just didn't stick, but I could deal with the styling issue. But Redux was just killing me in terms of productivity. There were small abstraction libraries over Redux, but I didn't feel comfortable enough with their small communities to make the leap. Eventually, I moved to Mobx State Tree. I thought that would be the holy grail. I ran into known huge performance issues with Mobx State Tree. That along with some of the leadership issues I had with the project was the final straw for me. I made the tough decision to rewrite everything in Vue. And I can't be happier with that decision. Vue just seems to have been developed with the number one goal of being productive in mind. Vuex is mostly a joy to work with. I love the built-in SCSS, scoped, etc styling mechanism. The community is great. I'm happy with my decision. Recent React has made some good strides with Hooks and Context. I'll have to take a look at using React in another project down the road. And I do have an affinity towards JSX, even though right now I don't use it in Vue (which supports it). And I think things like supporting JSX and more than one way to do thing in the Vue world is its greatest strength. If you don't like the "stringy" of template directives, then you can use JSX, you can write classes or you can write object style components. I look forward to Vue 3.0 and being able to drop legacy browser support so we don't have to use vue.set and friends because of reactivity issues.
awinter-py 8y ago
Of the big 3 frameworks (vue angular react) vue feels to me the most like what HTML custom components should be I could see vue-like syntax and features supported natively in the browser in a utopian future; have never felt that way about react or the ancient version of angular I had to touch.
- valerij 8y ago
  i would too really welcome DOM2 modelled after Vue. current way of reimplementing the DOM stack with JS feels like putting a new engine into cars trunk and hacking the transmission around instead of replacing the old engine that's occupying the front.
ilovecaching 8y ago
As a React developer I have yet to hear a compelling reason to use Vue. Most of the time it seems like the Vue defender was just looking for the next hot thing and would have used literally anything else, didn’t understand that React is just a library and conflated it with the React ecosystem, or couldn’t wrap their head around FRP. From a business standpoint I can’t understand why you’d put anything on Vue unless their was a long list of extremely compelling reasons to not use the larger, battle tested React ecosystem.
- jaequery 8y ago
  2 things for me: 1) 2-way bindings. i used to hate the concept of it as it was a form of black magic and had hard to debug performance issues ala Angular. but in Vue, it is actually fast and straightforward, it's essentially a light boilerplate around getter/setter methods. it took me a while to convert to this way of thinking but once i did, i never looked back. 2) @click, @submit, @emit, :some_property. at first glance, those unconventional symbols/etc irked me and was turned off by it. but after 5 min reading their doc, it became really intuitive and extremely handy. its unlike Angular who have way too many things going on, with Vue its minimal.
  - ilovecaching 8y ago
    Yeah, I've heard this before. It really makes no sense why you'd want to use getters and setters when FPR is so exceedingly powerful and easy to reason about, which circles back to my point about people not understanding FPR and the benefits thereof.
    - zachwood 8y ago
      What is FPR you keep referring to?
      - ilovecaching 8y ago
        functional reactive programming
pknopf 8y ago
> A quick solution is to load comments via ajax Oof, I haven't heard that word in awhile.
michaelgof 8y ago
Let's be honest Vue is a temporary blimp in web frameworks like all the others. I've been doing mobile dev the last 2 years and React was the hot thing. Then a year before that it was Angular. These things change and Vue is temporary like the others
petr25102018 8y ago
My own "one year later" post about Vue for those interested: https://stribny.name/blog/2019/01/one-year-with-vue-js https://stribny.name/blog/2019/01/one-year-with-vue-js.
lmiller1990 8y ago
I have used both React and Vue in large, long lived apps. I personally found both to be excellent - React has better TS support as of now. When Vue 3 hits with its internal TS api and you can use TSX as a first class citizen, I’d say you could go with either and have a comparable experience. At the moment the lack of static type checking due to Vue’s .vue file is the main disadvantage, IMO.
seanwilson 8y ago
You can use JSX with Vue but you miss out on some of the template features. Two way binding is one I think but there's add-ons that write the boiler plate for that for you. Either way, it feels uncomfortable working with Vue in a less standard way in the event you run into problems. JSX + Vue + TypeScript is pretty nice. HTML templates + Vue + TypeScript is not so nice because you get lots of bugs coming from the untyped templates.
- toastal 8y ago
  Two-way binding isn't so much a 'feature' so much as it is the bug that caused the front-end framework churn to finally steady as frameworks migrated to a more predictable model of one-way binding.
  - seanwilson 8y ago
    Vue is much more limited in the way it uses two way bindings compared to Angular v1 which you're probably referring to i.e. between form input elements and data, not between components.
  - kangoo1707 8y ago
    Outside Angular, I have never heard about two way binding as a source of bug
Illniyar 8y ago
I've been working with Vue for a few months now, after several years with React, angular, JSP, rails and django (and of course jquery). I know a lot of people, especially in HN, are impressed by it but I found it very lacking. It makes things easy to write at first and with very little learning curve but trades that ease of use for stability, simplicity and maintainability. The main problems, to me, are: * too much global state - the Vue object is the new window,a global registry, you add custom elements,filters,directives,plugins and even just utility methods. You can of course opt not to use it, but since all the libraries use it and it's the canonical way, you'd be hard pressed to. * lack of controlled components - unlike react there are no controlled components. For example if you are trying to make an input that doesn't accept certain characters, in vue you'll need to handle keypress events to make sure the value doesn't change, while in react you can simply not update the rendered value. This can be worked around of course, but the fact that vue doesn't have a clear definition of it permeates throughout the ecosystem. * component definition syntax - the syntax for definition a component with it's data,props,methods,computed,hooks is a very inconvenient way of writing classes (which vue 3 is going to support natively finally) * template syntax - after doing JSX, going back to template syntax is not the greatest experience. It doesn't work as well with IDEs, you have to spin circles to do things that can be a one liner in javascript and it prevents doing any form of reuse and structure unless it's by splitting it to more components (I.E. no way to use just functions or internal methods). Of course vue prides itself for the fact that you can choose to do things a different way - use JSX instead of template Syntax, don't use the global vue registry, etc... But that's really in theory, it's like React can be used without JSX, it's technically true, but it's extremely hard not to and the ecosystem won't work well. As to VueX, for me it takes the verbosity, single global object and dependence on strings for differentiation from redux and leaves out the immutability and reducer syntax. It takes the publish/subscribe technique from ReactiveX or mobX but leaves out the ability to combine, manipulate, stream and the general reusability that those frameworks provide. It is almost a comical selection of the worst features of both without any of the benefits.
- mcv 8y ago
  I've also been using Vue for a couple of months now. Initial experience is fairly positive, but there are absolutely things I miss. I don't miss JSX that much, but I really miss the way Angular let me inject services wherever I need, and views get updated automatically. If I try anything like that in Vue, it doesn't work, I need to put everything in the Vuex store, which makes the store a single global variable that contains all my data and services. Fortunately you can cut up the store into multiple modules, but I still prefer the decentralised approach from Angular over the central store. I also regret the lack of classes and the lack of a more webcomponent-like approach. Component definitions work fine and are fairly flexible, but they look messy.
pbowyer 8y ago
I'm doing my first proper project with VueJS, enhancing a traditional web app with components. I picked Vue because a year ago when I first started experimenting it seemed much easier than React to enhance parts of existing pages with. That story has changed since, and the React docs are beter about how to use components within pages. I echo the issues with the attribute syntax. I found marshalling data from the server into components to be painful. I ended up with the following: <activity-form action="/admin/applications/edit/1001/ajax-activity" :staff-member="1" :staff-member-options="[{"value":"1","text":"First Person"},{"value":"2","text":"Second Personki"},{"value":"3","text":"Third Person"}]" :activity-type-options="[{"value":"note","text":"Note"},{"value":"reminder","text":"Reminder"}]" :is-super-administrator="true" @new-activity-log-entry="addActivityLogEntry" > </activity-form> For enhancing existing server-rendered apps, is there a better story for passing data into components?
- kangoo1707 8y ago
  If you mix server-side rendered apps with Vue, this is the most common way. Second method is to push the data to a window.__data.staffMemberOptions = "{{ foo }}" and use it in Vue.
  - pbowyer 8y ago
    Thanks, good to hear. Elsewhere I've added something similar, and populate the data this way: var vue = new Vue({ el: '#app', created: function () { for (var key in __app.dataForVue) { this[key] = __app.dataForVue[key]; } }, // ... };
    - mkopinsky 8y ago
      Or as another approach:  <div id="app" data-inventory="{{ inventory | json_encode }}" > </div> // main.js new Vue({ template: '<App :inventory="inventory"/>', components: {App}, data() { return { inventory: null } }, beforeMount: function () { this.inventory = JSON.parse(this.$el.attributes['data-inventory'].value); } }).$mount('#app');
robeerob 8y ago
A more recent account from the same author: https://www.vuemastery.com/conferences/vueconf-us-2018/how-we-do-vue-at-gitLab-jacob-schatz/ https://www.vuemastery.com/conferences/vueconf-us-2018/how-w...
- satyrnein 8y ago
  Autoplaying video with loud music, just a heads up. Gave me a jolt!
gumcreme 8y ago
There were many times in the beginning of working with React when I checked out Vue because I was stuck. I was reading threads like this one where people were worshipping Vue and why it might be the better choice than React. People brought up many good points but forget one important decision factor most of the time: While Vue has a big ecosystem, it's still a fraction of React's. And this is probably the most important thing about React: The ecosystem is so huge, that you have choice, strong competition between lib authors and at the end of the day often or usually superior products. You hate redux? Me too, but there are literally dozens of competitors or wrappers out there + React's own Context and Hooks which bring you quite far. You want a UI lib? There was guy on Reddit testing 40 UI kits for React. Animation? A dozen good ones plus one major one. E.g. I was looking for a page-transition lib for Vue for cross-fading page transitions (real cross-fading where pages blend into each other), I found nothing, just one which can do page-transitions but not real cross-fading (fade-out and then fade-in of the new page). Not that just that vast amount of libs makes life easier, there are so many people you can ask, React got the lingua franca of frontend. Another thing I like is the actual (small) API of React. It's low-level and if you are stuck, you know quickly what the problem is. React shines also re maintainability , if I enter my biggest and quite complex React app after months I still know where to go and how things work. Finally, the React team and how they manage issues is amazing. Their thoughts, their chosen architecture, their communication is far beyond many other maintainers on Github. You ask stupid questions in an issue, often Dan answers himself, always super friendly and helping out. Once you passed the first weeks, I realized what smart architecture React has, that it never stands in my way. Just the fact that I am always and 100% in JS makes things so much easier.
nnq 8y ago
Why would one choose Vue over React except for the goal of making the project "easier to jump into" for "more junior developers" and sort of accessible to "designer-developers" too? The way I see it Vue complicates the logic of the app (due to two-way-binding, observable state etc.), it does decrease some the boilerplate needed at the beginning, but makes getting started or doing simple UI tweaks accessible for juniors devs / designer-developers / "web-developers". (React is well known for the fact that once an app grows beyond a certain size only actual "javascript engineers" can touch it, it's no longer intelligible to "designer-developers", and it can have a codebase specific learning curve for every junior dev joining the team.) EDIT+: To clarify, the way I see it, React's advantage is its simplicity, the core conceptual logic of things is very simple/mentally-compact, you can "run around with the whole thing loaded up in your head" easily. Yes, it does require more in terms of "IQ/cleverness" and also some "sense of architecture" from developers in exchange for being able to wield this simplicity without "cutting yourself", but I'd say it's worth it. I'd say React is the "catana sword" of web frameworks in a way :)
- Vinnl 8y ago
  > Why would one choose Vue over React except for the goal of making the project "easier to jump into" for "more junior developers" and sort of accessible to "designer-developers" too? In my (admittedly inexperienced w.r.t. Vue) view, that is exactly the reason for Vue's popularity, and a perfectly fine one at that. What I've seen from GitLab's workflow is that their front-end developers are not of the "SPA type", for lack of a better term, but more of the "design a page using HTML+CSS and add some Javascript for interactivity" type (same lack of a proper term). And that's perfectly fine; I'd presume they work more closely with designers or take up some design work themselves, and would at least expect them to be proficient in areas like accessibility much like many in the industry are not. I think what's the better choice mostly depends on how one's organisation is structured. Though honestly, either would probably have worked just fine, and it's mostly a matter of nuance.
Halluxfboy009 8y ago
I suspect most of the issues u face exist in other frameworks too. The comparison with scala isnt too right. They are probably 2 ends of the spectrurm for moment i saw scala, i knew its crap. Vue however has a certain beauty in its design, which really isnt too different from react/angular2, but much better syntax. most probably u guys have too many inexperienced developers.
AngeloAnolin 8y ago
The main argument why I am using Vue (especially) on a lot of side projects is that I am able to deliver faster and better software products to my customers. For small businesses, they rarely care with which framework you utilized to deliver the software. What they care for is that they know they are getting value out of their financial investment and that it could really help with their operations. And the ease with which I am able to extend / scale / enhance the application within a very short notice is also one of the highest selling points of my choice. Majority of businesses equate time resources with $ and the faster they are able to utilize the software, the better their business becomes.

309 points by NicoJuicy 8y ago

When you have to hassle the backend guys because querying <<100 comments is slow, is that the point where you stop and ask "what are we doing here".

hombre_fatal 8y ago
To be fair, they pointed out additional motivations to move to Vue like making the client-side UX more maintainable and improve client-side performance. Also, for all we know their server-side Rails+Haml stack took <50ms to query the database + render the comments, but they still wanted to factor that out of the initial page load to improve TTI.
cabaalis 8y ago
I thought the same thing. > Surely you could query the DOM for this. A better solution, in this case, is to let the backend developers mark the last user comment in the JSON they return. Backend developers have direct access to the database, which means they may be able to optimize the code. Then no client-side work has to be done at all, in this case. Look, I know what I am, I'm no fancy-pants silicon valley guru here. But what is described in this example is primarily a client-side function. So I think the wording for this is "a different solution" at minimum. Better? Meh. Will that new backend query ever serve any purpose other than facilitating this frontend feature? Perhaps instead of adhering to a "let's not query the DOM" at all costs, ask yourself what exactly you are complicating and for what gain.

heyheyhey 8y ago

Might wanna add a [2017] tag in the title.

sctb 8y ago
Updated. Thanks!

Kiro 8y ago

> Just use VueX That's the problem with large-scale Vue apps. Vue is awesome until you need to use VueX, after which it just becomes an inferior version of React + Redux.

pietrovismara 8y ago
Ever tried vuex-module-decorators? Add that to the recipe and using vuex with Typescript becomes really easy and a pleasure to write.
chadbaud 8y ago
Could you expound? I feel the exact opposite, and I'm genuinely curious why you feel that way.
Tade0 8y ago
Inferior? How exactly? I found Redux to be highly over-engineered in contrast to Vuex which is a lot like MobX - easy to use, yet powerful.
- nerdwaller 8y ago
  This is my thought as well, adding that it feels like way less boilerplate due to the integration with the underlying framework
- wp381640 8y ago
  > highly over-engineered Redux is a couple hundred lines of code. A good way to learn the pattern it to reimplement it yourself - which you could probably do in ~100LOC if you ignore the helper functions
  - enraged_camel 8y ago
    >>Redux is a couple hundred lines of code. That's not a refutation of the parent's statement.
  - Rapzid 8y ago

revskill 8y ago

I tried Vue 2 years ago and wrote a tiny wrapper around Select2 with Vue using jquery https://github.com/revskill10/vue-select2/blob/master/src/Select2.vue https://github.com/revskill10/vue-select2/blob/master/src/Se... It just works.

jakecodes 8y ago

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.

bartq 8y ago
what are worst parts of vue for you?
- jakecodes 8y ago
  I can't think of any bad parts of Vue off the top of my head. I really do enjoy the whole library. Although I think slots is a harder concept for most to grasp then it needs to be.
bargl 8y ago
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.
- jakecodes 8y ago
  I haven't done much with TypeScript. But I always hear great things.
- m_fayer 8y ago
  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 https://github.com/Armour/vue-typescript-admin-template
  - bargl 8y ago
    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-for-typescript-what-else-is-new/ https://hub.packtpub.com/vue-js-3-0-is-ditching-javascript-f...

arendtio 8y ago

I used riot.js for a few years and was quite happy with it. Sadly it had a few misconceptions (e.g. the parent.parent.parent... problem) which could have been changed easily. But as the lead dev wasn't very cooperative I switched to the closest alternative: Vue. I don't have enough experience with Vue yet to judge it, but given how similar Vue and riot.js are I hope that it gives me the same productivity without those broken bits and hopefully a better community interaction.

tribby 8y ago
I also came to vue from riot, and now find myself much more productive with vue. stick with it. and check out nuxt for out of the box server-side rendering, another thing that was a bit tricky with riot.

keyle 8y ago

I 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.

odorousrex 8y ago
>I HIGHLY recommend it, and this is from someone doing web since 1997. I started in 97 as well, and cannot recommend Vue enough. I've done React, Angular 1 & 2, and I keep coming back to Vue. I always feel like with React/Angular I'm conforming to work how they want me to work. (Esp. Angular - React is more forgiving). Whereas Vue is just a complement to the way I already work. I can use as much or as little of it as I wish. A hearty endorsement indeed.
- tashoecraft 8y ago
  So for personal projects or for small apps I think that’s great. But when I think about projects that need to live on well after I’m around, then they shouldn’t work the way I work, they should be in standard way that anyone can come into and know what’s going on. That jumping applications between teams feels simple. This is why I like angular quite a bit, it’s not whatever the dev decided to do. It doesn’t include a whole bunch of small libraries of questionable support.
  - wwweston 8y ago
    It's been a few years since I checked in with Angular because the projects I worked on were distinctively unpleasant, so what I'm about to say may not be current. But at the time, the wide variation in project structure (and available opinionated approaches) and libraries/tooling of questionable support were definitely part of the problem (though certainly not the full extent).
    - tashoecraft 8y ago

Townley 8y ago

I 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"

digitaltrees 8y ago
Check out quasar-framework
- ceejayoz 8y ago
  Or Ionic, which now supports Vue (and others) and is IMO substantially more polished.
  - digitaltrees 8y ago
    quasar lets you build a responsive web app, and iOS and Android apps, where ionic focuses on mobile, not bad just different. Also, Ionic’s support for vue is really new and not as well documented.
Kihashi 8y ago
> I tried using NativeScript with Vue and it just wasn't the seamless "3 NPM commands and you're done" I had a similar experience. I will say, though, that the nativescript-vue plugin is now officially supported by Telerik rather than just a community plugin, so it should theoretically be getting easier to use.

asdffdsa 8y ago

The 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

CharlesW 8y ago
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?
- perlgeek 8y ago
  angular.js is not a viable choice anymore (no clear statements of how long it's going to be supported), causing huge migration costs for everyone involved.
  - Bahamut 8y ago
    Angular 7 is though.
parthdesai 8y ago
React and Vue have 6.25 and 1.01 weekly downloads respectively. As of now, they are not even in the same league.
- KaoruAoiShiho 8y ago
  Using NPM stats is just not correct. I believe React to be about 2.5x larger than Vue rather than 6x.
  - parthdesai 8y ago
    And why would that not be correct, and what are the sources of your number?
    - 8y ago

seancoleman 8y ago

I (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!

nnq 8y ago
Q1: Do you use Vue alone/minimal, or Vue+Vuex? Q2: Did you compare Vue vs React or Vue+Vuex vs React+Redux? What do you think of "React without Redux"? Q3: What advantages would Vue bring over react in your context? The way I see it, Vue could lower TCO for web apps by allowing more junior developers or web-developers/designer-developers to make smaller UI changes instead of needing more senior/expensive frontend-engineers or full-stack-engineers-withs-strong-js-skills that React seems to require? (I mean your project doesn't seem like the one that would benefit from making the codebase easier for junior devs to work in, but at the expense of it getting more complicated for senior devs as the overall logic is more complicated in Vue...)

Bizarro 8y ago

I started out in SPA development a little over 3 years ago. Before that I was very inexperienced with front-end development, and we used ASP.NET MVC with JQuery sprinkled around. I realized that this was going to be a spaghetti nightmare, so decided that I had to choose a real front-end framework. At that time, Angular 2 was in a alpha,pre-alpha state, React (JSX) seemed to weird, I didn't know anything about Vue, so I chose Aurelia. At that time Aurelia was going to be the next big thing, but I believe there was a series of technical missteps with Aurelia and I saw that it wasn't going to go anywhere, so changed direction to React. By the time I started with React, I had months of front-end development under my belt, so I felt more comfortable with it. It had/has a large community with plenty of resources, but I started running into problems with the whole a-la-carte nature of the React ecosystem. At first, I used a little Mobx for state management, but at that time I had what would be considered several mini-SPA as I was migrating away from server side MVC. After a while I decided to migrate to Redux since that seemed to be the canonical state management solution for React. Redux turned out to be a productivity nightmare. Redux has its own ecosystem of libraries - Redux Promise, Redux Saga, Redux Forms, etc..The whole complexity was turning me off. Not only that, but other 3rd party libraries like React Router was a big bummer. There is 15 viable styling solutions in the React ecosystem, and the ones I played around with me just didn't stick, but I could deal with the styling issue. But Redux was just killing me in terms of productivity. There were small abstraction libraries over Redux, but I didn't feel comfortable enough with their small communities to make the leap. Eventually, I moved to Mobx State Tree. I thought that would be the holy grail. I ran into known huge performance issues with Mobx State Tree. That along with some of the leadership issues I had with the project was the final straw for me. I made the tough decision to rewrite everything in Vue. And I can't be happier with that decision. Vue just seems to have been developed with the number one goal of being productive in mind. Vuex is mostly a joy to work with. I love the built-in SCSS, scoped, etc styling mechanism. The community is great. I'm happy with my decision. Recent React has made some good strides with Hooks and Context. I'll have to take a look at using React in another project down the road. And I do have an affinity towards JSX, even though right now I don't use it in Vue (which supports it). And I think things like supporting JSX and more than one way to do thing in the Vue world is its greatest strength. If you don't like the "stringy" of template directives, then you can use JSX, you can write classes or you can write object style components. I look forward to Vue 3.0 and being able to drop legacy browser support so we don't have to use vue.set and friends because of reactivity issues.

awinter-py 8y ago

Of the big 3 frameworks (vue angular react) vue feels to me the most like what HTML custom components should be I could see vue-like syntax and features supported natively in the browser in a utopian future; have never felt that way about react or the ancient version of angular I had to touch.

valerij 8y ago
i would too really welcome DOM2 modelled after Vue. current way of reimplementing the DOM stack with JS feels like putting a new engine into cars trunk and hacking the transmission around instead of replacing the old engine that's occupying the front.

ilovecaching 8y ago

As a React developer I have yet to hear a compelling reason to use Vue. Most of the time it seems like the Vue defender was just looking for the next hot thing and would have used literally anything else, didn’t understand that React is just a library and conflated it with the React ecosystem, or couldn’t wrap their head around FRP. From a business standpoint I can’t understand why you’d put anything on Vue unless their was a long list of extremely compelling reasons to not use the larger, battle tested React ecosystem.

jaequery 8y ago
2 things for me: 1) 2-way bindings. i used to hate the concept of it as it was a form of black magic and had hard to debug performance issues ala Angular. but in Vue, it is actually fast and straightforward, it's essentially a light boilerplate around getter/setter methods. it took me a while to convert to this way of thinking but once i did, i never looked back. 2) @click, @submit, @emit, :some_property. at first glance, those unconventional symbols/etc irked me and was turned off by it. but after 5 min reading their doc, it became really intuitive and extremely handy. its unlike Angular who have way too many things going on, with Vue its minimal.
- ilovecaching 8y ago
  Yeah, I've heard this before. It really makes no sense why you'd want to use getters and setters when FPR is so exceedingly powerful and easy to reason about, which circles back to my point about people not understanding FPR and the benefits thereof.
  - zachwood 8y ago
    What is FPR you keep referring to?
    - ilovecaching 8y ago
      functional reactive programming

pknopf 8y ago

> A quick solution is to load comments via ajax Oof, I haven't heard that word in awhile.

michaelgof 8y ago

Let's be honest Vue is a temporary blimp in web frameworks like all the others. I've been doing mobile dev the last 2 years and React was the hot thing. Then a year before that it was Angular. These things change and Vue is temporary like the others

petr25102018 8y ago

My own "one year later" post about Vue for those interested: https://stribny.name/blog/2019/01/one-year-with-vue-js https://stribny.name/blog/2019/01/one-year-with-vue-js.

lmiller1990 8y ago

I have used both React and Vue in large, long lived apps. I personally found both to be excellent - React has better TS support as of now. When Vue 3 hits with its internal TS api and you can use TSX as a first class citizen, I’d say you could go with either and have a comparable experience. At the moment the lack of static type checking due to Vue’s .vue file is the main disadvantage, IMO.

seanwilson 8y ago

You can use JSX with Vue but you miss out on some of the template features. Two way binding is one I think but there's add-ons that write the boiler plate for that for you. Either way, it feels uncomfortable working with Vue in a less standard way in the event you run into problems. JSX + Vue + TypeScript is pretty nice. HTML templates + Vue + TypeScript is not so nice because you get lots of bugs coming from the untyped templates.

toastal 8y ago
Two-way binding isn't so much a 'feature' so much as it is the bug that caused the front-end framework churn to finally steady as frameworks migrated to a more predictable model of one-way binding.
- seanwilson 8y ago
  Vue is much more limited in the way it uses two way bindings compared to Angular v1 which you're probably referring to i.e. between form input elements and data, not between components.
- kangoo1707 8y ago
  Outside Angular, I have never heard about two way binding as a source of bug

Illniyar 8y ago

I've been working with Vue for a few months now, after several years with React, angular, JSP, rails and django (and of course jquery). I know a lot of people, especially in HN, are impressed by it but I found it very lacking. It makes things easy to write at first and with very little learning curve but trades that ease of use for stability, simplicity and maintainability. The main problems, to me, are: * too much global state - the Vue object is the new window,a global registry, you add custom elements,filters,directives,plugins and even just utility methods. You can of course opt not to use it, but since all the libraries use it and it's the canonical way, you'd be hard pressed to. * lack of controlled components - unlike react there are no controlled components. For example if you are trying to make an input that doesn't accept certain characters, in vue you'll need to handle keypress events to make sure the value doesn't change, while in react you can simply not update the rendered value. This can be worked around of course, but the fact that vue doesn't have a clear definition of it permeates throughout the ecosystem. * component definition syntax - the syntax for definition a component with it's data,props,methods,computed,hooks is a very inconvenient way of writing classes (which vue 3 is going to support natively finally) * template syntax - after doing JSX, going back to template syntax is not the greatest experience. It doesn't work as well with IDEs, you have to spin circles to do things that can be a one liner in javascript and it prevents doing any form of reuse and structure unless it's by splitting it to more components (I.E. no way to use just functions or internal methods). Of course vue prides itself for the fact that you can choose to do things a different way - use JSX instead of template Syntax, don't use the global vue registry, etc... But that's really in theory, it's like React can be used without JSX, it's technically true, but it's extremely hard not to and the ecosystem won't work well. As to VueX, for me it takes the verbosity, single global object and dependence on strings for differentiation from redux and leaves out the immutability and reducer syntax. It takes the publish/subscribe technique from ReactiveX or mobX but leaves out the ability to combine, manipulate, stream and the general reusability that those frameworks provide. It is almost a comical selection of the worst features of both without any of the benefits.

mcv 8y ago
I've also been using Vue for a couple of months now. Initial experience is fairly positive, but there are absolutely things I miss. I don't miss JSX that much, but I really miss the way Angular let me inject services wherever I need, and views get updated automatically. If I try anything like that in Vue, it doesn't work, I need to put everything in the Vuex store, which makes the store a single global variable that contains all my data and services. Fortunately you can cut up the store into multiple modules, but I still prefer the decentralised approach from Angular over the central store. I also regret the lack of classes and the lack of a more webcomponent-like approach. Component definitions work fine and are fairly flexible, but they look messy.

pbowyer 8y ago

I'm doing my first proper project with VueJS, enhancing a traditional web app with components. I picked Vue because a year ago when I first started experimenting it seemed much easier than React to enhance parts of existing pages with. That story has changed since, and the React docs are beter about how to use components within pages. I echo the issues with the attribute syntax. I found marshalling data from the server into components to be painful. I ended up with the following: <activity-form action="/admin/applications/edit/1001/ajax-activity" :staff-member="1" :staff-member-options="[{"value":"1","text":"First Person"},{"value":"2","text":"Second Personki"},{"value":"3","text":"Third Person"}]" :activity-type-options="[{"value":"note","text":"Note"},{"value":"reminder","text":"Reminder"}]" :is-super-administrator="true" @new-activity-log-entry="addActivityLogEntry" > </activity-form> For enhancing existing server-rendered apps, is there a better story for passing data into components?

kangoo1707 8y ago
If you mix server-side rendered apps with Vue, this is the most common way. Second method is to push the data to a window.__data.staffMemberOptions = "{{ foo }}" and use it in Vue.
- pbowyer 8y ago
  Thanks, good to hear. Elsewhere I've added something similar, and populate the data this way: var vue = new Vue({ el: '#app', created: function () { for (var key in __app.dataForVue) { this[key] = __app.dataForVue[key]; } }, // ... };
  - mkopinsky 8y ago
    Or as another approach:  <div id="app" data-inventory="{{ inventory | json_encode }}" > </div> // main.js new Vue({ template: '<App :inventory="inventory"/>', components: {App}, data() { return { inventory: null } }, beforeMount: function () { this.inventory = JSON.parse(this.$el.attributes['data-inventory'].value); } }).$mount('#app');

robeerob 8y ago

A more recent account from the same author: https://www.vuemastery.com/conferences/vueconf-us-2018/how-we-do-vue-at-gitLab-jacob-schatz/ https://www.vuemastery.com/conferences/vueconf-us-2018/how-w...

satyrnein 8y ago
Autoplaying video with loud music, just a heads up. Gave me a jolt!

gumcreme 8y ago

There were many times in the beginning of working with React when I checked out Vue because I was stuck. I was reading threads like this one where people were worshipping Vue and why it might be the better choice than React. People brought up many good points but forget one important decision factor most of the time: While Vue has a big ecosystem, it's still a fraction of React's. And this is probably the most important thing about React: The ecosystem is so huge, that you have choice, strong competition between lib authors and at the end of the day often or usually superior products. You hate redux? Me too, but there are literally dozens of competitors or wrappers out there + React's own Context and Hooks which bring you quite far. You want a UI lib? There was guy on Reddit testing 40 UI kits for React. Animation? A dozen good ones plus one major one. E.g. I was looking for a page-transition lib for Vue for cross-fading page transitions (real cross-fading where pages blend into each other), I found nothing, just one which can do page-transitions but not real cross-fading (fade-out and then fade-in of the new page). Not that just that vast amount of libs makes life easier, there are so many people you can ask, React got the lingua franca of frontend. Another thing I like is the actual (small) API of React. It's low-level and if you are stuck, you know quickly what the problem is. React shines also re maintainability , if I enter my biggest and quite complex React app after months I still know where to go and how things work. Finally, the React team and how they manage issues is amazing. Their thoughts, their chosen architecture, their communication is far beyond many other maintainers on Github. You ask stupid questions in an issue, often Dan answers himself, always super friendly and helping out. Once you passed the first weeks, I realized what smart architecture React has, that it never stands in my way. Just the fact that I am always and 100% in JS makes things so much easier.

nnq 8y ago

Why would one choose Vue over React except for the goal of making the project "easier to jump into" for "more junior developers" and sort of accessible to "designer-developers" too? The way I see it Vue complicates the logic of the app (due to two-way-binding, observable state etc.), it does decrease some the boilerplate needed at the beginning, but makes getting started or doing simple UI tweaks accessible for juniors devs / designer-developers / "web-developers". (React is well known for the fact that once an app grows beyond a certain size only actual "javascript engineers" can touch it, it's no longer intelligible to "designer-developers", and it can have a codebase specific learning curve for every junior dev joining the team.) EDIT+: To clarify, the way I see it, React's advantage is its simplicity, the core conceptual logic of things is very simple/mentally-compact, you can "run around with the whole thing loaded up in your head" easily. Yes, it does require more in terms of "IQ/cleverness" and also some "sense of architecture" from developers in exchange for being able to wield this simplicity without "cutting yourself", but I'd say it's worth it. I'd say React is the "catana sword" of web frameworks in a way :)

Vinnl 8y ago
> Why would one choose Vue over React except for the goal of making the project "easier to jump into" for "more junior developers" and sort of accessible to "designer-developers" too? In my (admittedly inexperienced w.r.t. Vue) view, that is exactly the reason for Vue's popularity, and a perfectly fine one at that. What I've seen from GitLab's workflow is that their front-end developers are not of the "SPA type", for lack of a better term, but more of the "design a page using HTML+CSS and add some Javascript for interactivity" type (same lack of a proper term). And that's perfectly fine; I'd presume they work more closely with designers or take up some design work themselves, and would at least expect them to be proficient in areas like accessibility much like many in the industry are not. I think what's the better choice mostly depends on how one's organisation is structured. Though honestly, either would probably have worked just fine, and it's mostly a matter of nuance.

Halluxfboy009 8y ago

I suspect most of the issues u face exist in other frameworks too. The comparison with scala isnt too right. They are probably 2 ends of the spectrurm for moment i saw scala, i knew its crap. Vue however has a certain beauty in its design, which really isnt too different from react/angular2, but much better syntax. most probably u guys have too many inexperienced developers.

AngeloAnolin 8y ago

The main argument why I am using Vue (especially) on a lot of side projects is that I am able to deliver faster and better software products to my customers. For small businesses, they rarely care with which framework you utilized to deliver the software. What they care for is that they know they are getting value out of their financial investment and that it could really help with their operations. And the ease with which I am able to extend / scale / enhance the application within a very short notice is also one of the highest selling points of my choice. Majority of businesses equate time resources with $ and the faster they are able to utilize the software, the better their business becomes.