Live data from Hacker News

Why we chose Vue.js

about.gitlab.com

231–240 of 282 posts

Re: Why we chose Vue.js

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

> it's a seriously underrated benefit. It is not without a cost, the cost being an lack of standard ways to accomplish things. For long running projects where devs may come and go, having a standard way to do things is an incredible advantage, and will result in a much more consistent code base. For real world front end project, this is a much more important concern, imho, than ease of picking up. For your particular…

I've heard this argument before and I find it fascinating. Why can't we have something that is both standardized and easy to pick up? Is there something inherent to one that blocks the other? Any ideas?

Disclaimer? I don't use Vue, but I've seen this argument made for Ember (against Angular 1.x) and Angular 2 (against React).

Re: Why we chose Vue.js

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

Could you please elaborate more on mithril vs. vue? Was it ease-of-use, performance or something else that pulled you over?

Re: Why we chose Vue.js

#233
post #154

I actually interviewed with Jacob Schatz when he was trying to figure out which frontend framework to use for GitLab. I had been working in React for the last year or so which was apparent on my resume. He prefaced our interview with something to the effect of "I know you do a lot of React but we are not going to ever use React at GitLab" It was weird. I tried to ascertain his reasoning and pretty much all I got was…

Hi @49531. Sorry you felt that our conversation was weird. Regardless of my opinion of React, Vue or any Frontend Framework, I never want anyone to have a weird interview. My main feeling with Vue vs. React (maybe this should be a different post, as this post was meant to explain why Vue, and focus on the positives): 1. Vue is minimal to add in with existing code. React, is also not bad, but Vue is much simpler to mi…

Vuejs starting page itself uses some if and for tag for looping. That's like learning a DSL while I could use simple js to do that in reactjs.

Re: Why we chose Vue.js

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

The nice thing about JSX is that it is an embedded DSL. When you use JSX you can take advantage of all of Javascript: variables, loops, conditionals, subroutines, closures, etc.

The bad thing about most other template DSLs is that they recreate all of these features from scratch, often in buggy ways. For example, many template DSLs have dynamically scoped variables instead of lexically scoped ones.

Re: Why we chose Vue.js

#235

A long time ago (7-10 years ago) Web 2.0 was the craze. It was the beginning of making interactive web applications. There were few major players that were even backed by companies: Dojo, Prototype, GWT, (and like 4 more that I can't remember). These libraries were complicated and were generally component based with their own flair of inheritance. You could not iteratively enhance your existing web 1.0 app. You had t…

>>There were few major players that were even backed by companies: Dojo, Prototype, GWT, (and like 4 more that I can't remember).

Vaadin comes to mind :)

+1 on Elm, also don't think the learning curve for someone with any "functional" (even if JS) exposure is that steep.

Re: Why we chose Vue.js

#236
post #226

Earlier quoted context omitted.

This is because it takes about one or two years before all the hordes of idiots to abandon the last ship they sank and come swimming full speed towards a new ship to sink. The unfortunate part is that it's moments like this (when a framework makes it into the spotlight in a big way like this) that those hordes begin their swim. Evan is an excellent developer, and it won't by through his volition that Vue gets ruined.

No, what happens is a new framework comes out that fixes the complexity problems of the previous popular framework, but ignores why that complexity existed in the first place. Once the new framework gains popularity the limitations caused by ignoring complexity start to surface and so the framework has to add features to handle them, creating complexity of its own. Then the cycle repeats itself.

See my explanation below my OP. Your comment is correct, but these complexities should not be solved in the framework, lest we forget the vision that drove the creation of this framework in the first place, providing an obstruction layer that doesn't solve all problems at all layers.

Re: Why we chose Vue.js

#237

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've written a express renderer library so you can use vue component files without webpack. Just using res.render()

https://github.com/danmademe/express-vue

Re: Why we chose Vue.js

#238

Earlier quoted context omitted.

> it's a seriously underrated benefit. It is not without a cost, the cost being an lack of standard ways to accomplish things. For long running projects where devs may come and go, having a standard way to do things is an incredible advantage, and will result in a much more consistent code base. For real world front end project, this is a much more important concern, imho, than ease of picking up. For your particular…

I've heard this argument before and I find it fascinating. Why can't we have something that is both standardized and easy to pick up? Is there something inherent to one that blocks the other? Any ideas? Disclaimer? I don't use Vue, but I've seen this argument made for Ember (against Angular 1.x) and Angular 2 (against React).

>Why can't we have something that is both standardized and easy to pick up?

Simply because one has to learn the standards in the former case. In the latter, it is mostly left to the users imagination and their own sensibilities, which differ from person to person.

Re: Why we chose Vue.js

#239
post #31
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.

Interestingly enough, maintaining and developing Vue.js is now the author's full time job! Check out his patreon here: https://www.patreon.com/evanyou

Re: Why we chose Vue.js

#240

I know that Gitlab is written in pretty traditional Rails' style and takes advantage of turbolinks. Did you run into any difficulties adding a framework that likes to "own the page" like most single page app frameworks do? I've found these can often end up fighting with turbolinks and similar libraries.

@wadentandy, Yes that is still something we are figuring out the best way. For a major feature (like issue boards), because we won't use Vue for everything, we load those files on a per page basis.
Post reply on HN