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

Why we chose Vue.js

about.gitlab.com

Post reply on HN
Print view View original

31–40 of 282 posts

Re: Why we chose Vue.js

#31

Post by lossolo »

gregmac wrote: post #11

I do very little web these days, mostly working on backend data processing, network I/O and distributed comms. A bit over a year ago, I wanted a real-time web UI to visualize some of the data I had on server-side, which I was trying to do using SignalR. I went back through some of the popular frameworks, with a pretty simple mindset of "Can I read the 'getting started', and get something basic working in about 15 min…

I have almost the same experience as you. I am maintaining big Ember app and have exactly the same problems as you described with it.I am interested in Vue lately also because it's so lightweight, easy, well structured, documentation is excellent, ecosystem around it is excellent and i have so much more freedom than in Ember. Author really cares about it, issues on github shows that, only 50 open and 3000 closed.

Re: Why we chose Vue.js

#32

Post by kentor »

After using React, I am firmly in the #nevertemplates camp. I don't ever want to learn a template DSL again when I could be using the full power of javascript.

Re: Why we chose Vue.js

#33

Post by PudgePacket »

cageface wrote: post #23
qaq wrote: post #17

Earlier quoted context omitted.

If you pair React with something sane like MobX, the React API surface that devs will need to use will be tiny.

I get that you can do some cool things with Redux but I'm not sure it really should be the go-to state management tool for React apps. It requires so much ceremony to even do simple things and the async story is pretty complex. I haven't tried Mobx yet but it looks like a saner solution that don't need Redux's more advanced state management tricks.

Could you expand on what you mean by ceremony and state management tricks ? From my use of Redux there is a bit of set up cost in making the types and actions and getting the store into the components that need it, is that what you're referring to ?

Re: Why we chose Vue.js

#34

Post by anonyfox »

As someone who went through the complete frontend hype-trains (jquery, backbone, angular, ember, react, all in production): Vue.js 2.0 with single file components is exactly what everyone looks for desperately.

- performance: faster than react now

- learning curve: a few hours from scratch

- getting started: cli-tool for initial scaffold & configuration

- components: simple .vue files with a , and . Super easy to get going, no need for JSX

- "official" packages for routing, ajax and state management. No wasting of days for choosing every tiny package for days

- vuex 2.0 is one of the cleanest flux implementation i've seen in the last year

... and much more. Give it a try with the full webpack template of the cli tool!

Re: Why we chose Vue.js

#35

Post by tracker1 »

petre wrote: post #15
nodesocket wrote: post #4

I as well gravitate toward Vue.js for its simplicity, but I wonder if React's mind share and community size "trump" simplicity. For example, if you're hiring for a front-end position, you'll probably get more candidates familiar and experts in React over Vue.js.

Couldn't you just ask for JavaScript in the job description instead of React? Because if a dev knows JS s/he will handle Vue easily. Most React devs already write something else: JSX. Of course you can skip using that but won't it be like coding with your hands tied?

I tend to ask mostly JS questions in interviews, and very few "angular" or "React" questions when screening candidates... if you're good with JS and know at least 2 other languages, you'll be able to handle pretty much any modern JS framework without much difficulty.

Re: Why we chose Vue.js

#36

Post by miaumiau2 »

BinaryIdiot wrote: post #25

How does Vue.js handle high latency issues? With Angular 1.x I've always had issues where the GUI will "flash" while the HTML is loading and the angular.js has not yet finished loading on a slow connection (so you might briefly see all of these {{message1}} {{message2}} etc on the page). I'm curious how Vue.js handles that case or if it has the same problem.

ng-cloak is your friend..

Re: Why we chose Vue.js

#37

Post by tracker1 »

cmpb wrote: post #7

My team and I are considering switching from Knockout.js to Vue.js. Has anyone here made that (or a similar) transition and do you know of some pros / cons, battle stories, etc.?

you'll probably see less disconnect from Knockout to Vue than pretty much any other modern js ui approach... even ng1 to ng2 is a really big break. I happen to like React's approach more, as it's more pure to JS (even with JSX) than augmented DOM, or template engines are imho.

Re: Why we chose Vue.js

#38

Post by tracker1 »

smegel wrote: post #16

Oh man, I just started learning React... https://vuejs.org/guide/comparison.html

I find the comparison to React there pretty biased, especially wrt the learning curve... JSX is a cakewalk, and OMG, oh noes, you need to know the current JS language.

Re: Why we chose Vue.js

#39

Post by Yaggo »

kentor wrote: post #32

After using React, I am firmly in the #nevertemplates camp. I don't ever want to learn a template DSL again when I could be using the full power of javascript.

So what is JSX if not DSL? (Yeah, you can use React without JSX, but still.)
Post reply on HN