Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we do Vue: one year later (2017)

about.gitlab.com

Post reply on HN
Print view View original

31–40 of 159 posts

Re: How we do Vue: one year later (2017)

#31

Post by kinow »

keyle wrote: post #14

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.

I worked more with backend (Java, Python, PHP), but in my current project we needed a good UI, and decided to use Vue. No regrets. Using it almost everyday. I knew Backbone and a bit of Angular, but after using Vue, its cli, i18n, vuex, and also vue mastery, I'm not looking at any other tool for now.

The community around it is also extremely helpful.

Re: How we do Vue: one year later (2017)

#32

Post by parthdesai »

asdffdsa wrote: post #25

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

React and Vue have 6.25 and 1.01 weekly downloads respectively. As of now, they are not even in the same league.

Re: How we do Vue: one year later (2017)

#33

Post by yura »

keyle wrote: post #14

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.

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

That's exactly what it's like. Working with Vue doesn't even feel like you're using a JavaScript framework. You just write your HTML, your CSS, your scripts/data and you're done. Vue is brilliant.

Re: How we do Vue: one year later (2017)

#34

Post by hombre_fatal »

stefan_ wrote: post #2

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

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.

Re: How we do Vue: one year later (2017)

#35

Post by ceejayoz »

digitaltrees wrote: post #24
Townley wrote: post #22

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 o…

Check out quasar-framework

Or Ionic, which now supports Vue (and others) and is IMO substantially more polished.

Re: How we do Vue: one year later (2017)

#36

Post by jimmy1 »

koboll wrote: post #30
keyle wrote: post #14

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.

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 Vu…

I have to agree with this. Ultimately whether or not you like Vue or React better boils down to if you agree with the semantics of the web, and including them in your app building process (i.e you like html, and css, and just want to "pepper" in some logic and interactivity with JavaScript), or if you would rather just embrace JavaScript whole-heartedly.

Vue relies too much on overloading the string type for my taste (fundamentally, all JS libs do this to some extent). Too much magic happens with these string-based v-bindings.

Irrespective of that, these days I am hard pressed to not use typed JS in some form or fashion anyways.

Re: How we do Vue: one year later (2017)

#37

Post by keyle »

codegeek wrote: post #23
keyle wrote: post #14

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.

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 ?

That's a problem you'll have with any of those frameworks. Personally I have endpoints that ask for the data at a component level and if they're small, they're being passed the data from the view that contains them.

Re: How we do Vue: one year later (2017)

#38

Post by keyle »

kbody wrote: post #20
keyle wrote: post #14

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.

Have you tried React in a similar setting? Personally I couldn't bear it and it's massive adoption on frontend pushed me away from following that route much. Vue on the other hand certainly looks more "logical" to my eyes.

Yes I've used React. React was ok, but I had to think React and work the React way. With Vue, I work my way with minimal conformance.

Re: How we do Vue: one year later (2017)

#39

Post by wp381640 »

Tade0 wrote: post #10
Kiro wrote: post #4

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

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.

> 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

Re: How we do Vue: one year later (2017)

#40

Post by tashoecraft »

odorousrex wrote: post #19
keyle wrote: post #14

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.

>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…

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.

Post reply on HN