Live data from Hacker News

Why we chose Vue.js

about.gitlab.com

101–110 of 282 posts

Re: Why we chose Vue.js

#101
Side-project wise, we use Vue on StyleCI (https://styleci.io) and over the next few months we'll also be using it on Cachet (https://cachethq.io).

My experience started at work where we used it on an internal project. The ease of use was insane, we had something reactive and easy to work on in no more than 10 minutes. React has always had too big of a learning curve for us, so it'd have been a vanilla JS/jQuery mess if we hadn't found Vue.

We're now using it on almost any project we start (they're all very UI driven).

I met Evan You at Laracon earlier in the year, he's an awesome dude and has put a lot of thought into everything Vue. Thanks again for making Vue! :)

Re: Why we chose Vue.js

#102
post #82
post #76

vue is awesome. I wish there were an equivalent to something like ember-fastboot for out-of-the-box server side rendering, though. (server-side rendering for those who care about progressive enhancement in the browser, not isomorphism).

Vuejs 2.0 does server side rendering, afaik.

it does, but that isn't my complaint: there isn't an official, opinionated way to do it - something that syncs vue-router to express and serves. it's a common enough problem that fastboot solved it for ember, and I wish vue had the same.

Re: Why we chose Vue.js

#103

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…

I started reading through the docs and found it very similar to Knockout.js. Is here anyone who used both to tell the advantages of Vue?

FYI, I'm thinking about dropping Knockout because some performance problems I'm having with a very specific use-case.

Re: Why we chose Vue.js

#104

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…

I started reading through the docs and found it very similar to Knockout.js. Is here anyone who used both to tell the advantages of Vue? FYI, I'm thinking about dropping Knockout because some performance problems I'm having with a very specific use-case.

We are using Knockout in my current work. I am using vue in my spare time. They feel indeed very similar.

Re: Why we chose Vue.js

#105
post #42

To me Vue is a great tool for side projects. In React I found myself struggling to figure out what libs to use and keep myself up to date with them. I also hated configuring webpack. With Vue, I have officially supported libraries like vuex and vue-router which work great with Vue out of the box. vue-cli also allows me to scaffold projects with these libraries very easily. But the thing I like most about Vue is it al…

Wait, Vue doesn't need to be transpiled to JS like JSX? I'm equally hating configuring webpack. It's lack of documentation isn't helping either.

Re: Why we chose Vue.js

#106

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.

The thing is that most React developers don't actually think React is that complex at all.

React alone in itself is pretty small library but the pieces that you put together to it (redux, react-router, react-redux, webpack/browserify) might be a big hurdle for beginners.

Re: Why we chose Vue.js

#107

Earlier quoted context omitted.

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 ?

Yeah that and then also the stuff you have to do to get async working like redux-thunk and redux-saga.

I haven't actually built anything with these yet so maybe in practice it's ok but it definitely looks ugly.

Re: Why we chose Vue.js

#108
The company I work for has an app built with Angular 1.x (the backend is .NET). We started sensing that Angular was not best choice, especially when working with 3rd party components. There are other factors to, but they have been already mentioned in other comments. Long story short, we had enough of wrapping everything in $timeout and started looking at alternatives.

After some consideration, we were left with choosing between Vue.js and React. Coming from Angular the biggest plus was two-way-binding, Vue.js had a slight advantage. We then converted a "module" (not in JS jargon) using both frameworks.

In our experience, when switching from Angular 1.x to Vue.js, there's a sense of not changing much (we were still "declaring" logic in the templates) but nonetheless doing things better, simpler and faster. The React version needed a bit more time investment (we had no prior experience in our team; a colleague from another project helped us a bit by showing us how he implemented a project using React). In the end we chose React due to the wonderful combination between it and TypeScript. We suddenly had no more string templates and refactoring was a breeze (there are, of course other benefits as well).

What I'm trying to say is that, if you have Angular 1.x experience it's easier to switch Vue. I had fun porting the "module" to Vue and would have happily worked with it if the team had not chosen React. I consider "mixins" to be one of its killer features (would have made a lot of things easier with our app). Having said that, I don't consider React that hard to grasp and don't regret that the team picket it over Vue. As long as you remember the lifecycle, programming with it can be fun and easy. The React/TypeScript combination compensates for the lack of mixins and two-way-binding (I know, MobX, but I'm talking about the "vanilla" versions).

Re: Why we chose Vue.js

#109
post #97
post #86

Just pick something , internet and build a good structure on top of it . All this jquery-level bikeshedding is nice for your ad widgets and minimalistic web apps, but it won't help me replace proper GUI toolkits. And sadly, that seems to be in demand... I'll cope with your ill-designed template language (heck, if I can cope with HTML, I can cope with anything) or your JS async abstraction du jour (promises, async awa…

>>> if I can cope with HTML, I can cope with anything Just curious, what do you find so terrible about HTML?

HTML's horrors are highly context sensitive. One of its most generic sins is the poor support for hypertext. Various predecessors did a better job at this (Hyper-G, HyTime). Anchor- and URI-based hyperlinks are a rather insufficient solution, and I think the web would've benefitted from a more extensive and extensible architecture.

Speaking of extensible, HTML has the "class" attribute. Awesome. Something better would've spared us a lot of template languages in the first place. Not looking at you, XSLT.

And when we deviate too much from both HTML's and its ancestor SGML's original purposes, the syntax gets really ugly. Explicit end tags make sense if the beginning of your document's is more than a terminal's length out of sight, but when used in something you build UI elements out of (or where content isn't immediately there), the verbosity hurts. Never mind the general XML problem of sub-tags vs. attributes.

At least the amount of different standards is getting better. Parsing still is way more complicated than it needs be.

And let's not even start with the lateness and insufficiency of CSS.

As bad as it was as a hypertext markup language, it's even worse as core structure for this weird NeWs-like quasi-PostScript we're squeezing HTML/CSS/JS into, for lack of a better alternative.

Re: Why we chose Vue.js

#110

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…

Isn't Vue.js hype too?

I mean if I look at the GitHub stars it seems pretty hyped to me. (It's between Angular/React and Ember)

Post reply on HN