Live data from Hacker News

Why we chose Vue.js

about.gitlab.com

111–120 of 282 posts

Re: Why we chose Vue.js

#111

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

We had a similar experience in our office. We chose Vue.js and we are all very pleased with the results. Vue is simple enough to understand and be productive in in a reasonable amount of time.

Re: Why we chose Vue.js

#112
I am more and more of the opinion that you should NOT use a js framework for long term projects (that span more than a few years), but just use vanilla js with some libraries that you can easily switch when something better comes out. Vue.js is here today, and it is nice, but tomorrow gintzx.js comes out, and the community will be flabbergasted and everyone will use it and vue.js will slowly die. Making big complex webapps with just some libs is absolutely possible. Just choose them wisely and make a good directory structure.

Re: Why we chose Vue.js

#113
post #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)

It's definitely hype. I'm honestly surprised nobody seems to be complaining about it breaking their noscript, accessibility, SEO, etc.

Re: Why we chose Vue.js

#114
post #85

Earlier quoted context omitted.

Whoa! Thank you for this. I think this is exactly what I am thinking. I have done exactly what you did and I'm trying to figure out what the rage is as well. I want to find a framework that works for me without all the intricacies and nuances of something so complicated... something that gives me the errors that I need to know to debug the issues I'm having.

Personally, it's the lack of pain when getting started. React has an unfamiliar syntax and the cognitive load to "get it" while not huge, was going to take time. Angular seemed fine but a little verbose and a new version was coming out that diverged from Angular 1 in a way that caused more than a few headaches, apparently. With Vue.js I read through the excellently presented guide and started building my app, instant…

> React has an unfamiliar syntax and the cognitive load to "get it" while not huge, was going to take time.

Maybe because I have a background in functional programming, it only took me an hour or two to get React itself. The basic concept is dead simple declarative programming: declare a React component some state, and it renders it. The lifecycle adds a bit more to understand, but most of us have dealt with lifecycles somewhere, whether in WordPress, Android, etc. And then there's local component `state`. But that's it.

However, what's commonly accepted as the React ecosystem (meaning webpack, babel, flux/redux, eslint, sometimes flow etc.) takes a lot longer to understand. And can be quite (perhaps overly) complex.

Re: Why we chose Vue.js

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

Vue looks interesting. I went through a similar thought process,but ended up with Riotjs. Maybe if I had heard of Vue earlier, I would have chosen it.

Re: Why we chose Vue.js

#116
post #113
post #110

Earlier quoted context omitted.

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)

It's definitely hype. I'm honestly surprised nobody seems to be complaining about it breaking their noscript, accessibility, SEO, etc.

I read a writing about how SEO isn't an issue with SPAs. (can't find it at the moment)

As far as I know, all major search engines are evaluating JavaScript client-side and index the resulting html, only a chinese one had problems with SPAs.

There was even a site from Google, where you could enter a URL and see how Google sees the page.

Re: Why we chose Vue.js

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

Jsx is horrible is mixing markup and code all over again A DSL like Elm does is much better

Re: Why we chose Vue.js

#118
post #39
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.)

It's markup mixed with code. a DSL is a different thing

Re: Why we chose Vue.js

#119
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 wanted a real-time web UI to visualize some of the data

Got the same problem, but we already went for React/Redux and it wasn't really nice.

I would go for Cycle.js in my future projects. Because everything is modeled as a Observable (no differentiation between data and UI) and it allows to handle real-time data really well (backpressure, etc.)

Re: Why we chose Vue.js

#120
post #78
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.

Just so you know Vue 2.0 supports both templates AND JSX (or hand-written render functions): https://github.com/vuejs/babel-plugin-transform-vue-jsx

Haven't tried Vue yet but I like the idea of having a choice. It would seem to me that for most cases one would simply a template since it gets you there easily and without any boilerplate. For the cases where one does need the full power of Javascript, JSX is the solution. I'd imagine that most components would initially be written as templates, and some would be refactored into JSX along the way, which is probably not much of a pain.

Really want to play with it ...

Post reply on HN