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

121–130 of 159 posts

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

#121

Post by mcv »

Illniyar wrote: post #110

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

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.

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

#122

Post by gumcreme »

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.

To be honest, your post is like this submission. It's not helping people who want to decide. You just say Vue is great but people would like to understand why or why it might be better than React. This submission is also not helpful because it's from 2017 and I wonder why it is heavily upvoted and not a newer post. Things changed in two years and again, readers would like to understand how Vue compares against React but in 2019.

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

#123

Post by kangoo1707 »

pbowyer wrote: post #116

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

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.

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

#124

Post by Smithalicious »

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 ?

What exactly is your issue with props?

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

#125

Post by kangoo1707 »

toastal wrote: post #87
seanwilson wrote: post #82

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

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.

Outside Angular, I have never heard about two way binding as a source of bug

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

#126

Post by kangoo1707 »

parthdesai wrote: post #32
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.

A portion of Vue projects are not single page app: it can be used on top of a server-rendered frameworks like Laravel, Rails. Even the document mentions using Vue by a script tag inside the HTML.

This may contribute to Vue being downloaded through npm in lower volume than React

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

#127

Post by nnq »

seancoleman wrote: post #27

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!

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

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

#128

Post by nnq »

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 :)

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

#129

Post by lloydatkinson »

pbowyer wrote: post #116

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

I'm sorry but blaming the tools for that HTML encoded mess you've got there is just wrong.

Pass the values from the parent component.

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

#130

Post by Vinnl »

nnq wrote: post #128

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

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

Post reply on HN