
How we do Vue at GitLab: one year later - unnawut
https://about.gitlab.com/2017/11/09/gitlab-vue-one-year-later/
======
gt5050
At my last job we did a comparison between Vue and React before rewriting a
major frontend application.

We did a POC in both React/Vue and ended up using Vue mainly due to the
following reasons:

 _Single File Components_

Single file components (.vue files) is the best thing about Vue. I understand
this might be a personal preference, but we wanted to avoid CSS-IN-JS. Our
designer could churn out neat html/css, but was a beginner in Javascript. With
Vue's single file components, he could also hack parallely with us while
iterating on html/css.

 _Standard / Official way of doing things_

This again is a personal preference but Vuejs comes with a recommended way to
do a majority of things. Vuex(state management) and Vue-Router are
provided/maintained by same Vue core team.

React at times can be overwhelming for beginnners, just because of the amount
of choice available

Example:

Google Search for 'React CSS style'
[[https://www.google.co.in/search?q=react+css+style](https://www.google.co.in/search?q=react+css+style)]
points to a bunch of links all of which link to valid solutions, but I have to
go through a few of them before I get what I am looking for.

Similar search for 'Vue CSS style'
[[https://www.google.co.in/search?q=vue+css+style](https://www.google.co.in/search?q=vue+css+style)]
all top links lead to official documenation on vuejs.org.

 _Excellent documentation_

Also, as a team we were primarily writing Angular 1 when we decided to choose
a frontend framework for newer projects. I feel this also made our transition
to Vue easier vis a vis React

~~~
giantsloth
I agree that single file components are awesome. I wish you had been
introduced to styled components in react:

    
    
      import styled from 'styled-components'
    
      const Container = styled.div`
        padding: 10px;
        background: ${
          ({ isHovered }) => isHovered ?
            'green' :
            'red'
        };
      `
    
      const H1 = styled.h1`
        font-size: 15px;
      `
    
      const P = styled.p`
        font-size: 10px;
      `
    
      const MyComponent = ({ isHovered }) => {
        return (
          <Container
            isHovered={isHovered}
          >
            <H1> Hello <H1>
            <P> This is a thing </P>
          </Container>
        )
      }

~~~
sametmax
God this is horrible. It's ugly. Hard to read. Things are scattered all over
the code. And where is my sass ?

~~~
mottomotto
I much prefer putting the styles in a separate {componentName}.scss file,
import'ing that into the component and using the Webpack Extract Text Plugin:

[https://github.com/webpack-contrib/extract-text-webpack-
plug...](https://github.com/webpack-contrib/extract-text-webpack-plugin)

I guess now you have two files per component but to me, it's well worth it.

~~~
onenite
You can work with two files per component if you must truly put the styling in
another file.

One of the boons of react is that you can create a set of reusable base
components that can be built upon throughout your app.

If you can code-split the app, lazy-loading components as needed, and if you
can cache all of the static app anyway, why does it matter if the presentation
is tied to the logic?

The same can be said for vue.js. :)

The two languages have many merits and they both make their own sacrifices.
But they are ultimately two peas of a pod.

Like Thor and Loki. But who is Thor and who is Loki? ;)

------
ng12
> We discovered that VueX makes our lives easier. If you are writing a medium
> to large feature, use VueX. If it's a tiny feature, you might get away
> without it.

I feel like this is Vue starting to get the React treatment. React was (and
still is!) a very simple library until people realized they needed to do fancy
things to make complex applications manageable. Redux came out, everyone fell
in love with it, and React+Redux became an official couple. This lead to the
perception that React has a steep learning curve because new developers were
learning React+Redux without learning React first.

I wonder what Vue can do to avoid the same pitfall.

~~~
a13n
When did new react developers start learning redux? From my experience that
just isn't true.

~~~
SwellJoe
I've been learning React lately, and many tutorials, even those targeted at
beginners, include Redux. Many seem to be a sort-of cargo cult without any
understanding of why they're using Redux, and in many cases, there's no reason
to introduce Redux into the mix. I've also noticed a lot of tutorials are
content marketing from companies wanting to sell bolt-on services and tools,
which is pretty weird; I've never used a language/ecosystem that had so many
hangers-on before. And, it leads to the same situation: "Learn React (plus
these other complicated things that we want to sell you)!"

I mean, it's necessary, at some point, to see a full system that uses all the
tools for delivering a real application. But, it is definitely a lot of
concepts to grok at once. I actually found it most useful to see tutorials
that started without even using React, and built up from first principles to
what React does (given that React is conceptually very simple, this isn't so
crazy...a toy version of React can be built in an hour or so, so it's perfect
for a video or article; much of the complexity in React is in making it fast
rather than in making it work). But, that may not be a necessary first step
for people who have more frontend or reactive programming experience than I
have.

~~~
jbreckmckye
There is a big problem with the commercialisation of React. More and more
companies are using learning resources as marketing material. And now one
popular JS developer has started beginning his GitHub readmes with
advertisements for a paid JS course. It's a far cry from the open, guileless
sharing culture of webdev 10 years ago.

~~~
SwellJoe
I'm somehow less bothered by the latter. Folks gotta make a living, somehow,
and sometimes people have to make choices between doing OSS development or
having a real job and doing a lot less of the OSS work.

But, the learning materials and marketing are the ones that bug me...
_especially_ the ones that neglect to mention that the materials cover
React+product, and only mention React in the title. You might not even know
it's marketing until you've read half the darned thing and the crux of the
thing turns out to be "now create an account here and use this service to
outsource the specific thing you googled to learn how to implement yourself".
GraphQL has a lot of the same thing going on. It's like "how to draw an owl",
only instead of "now draw the rest of the fucking owl", it's "now send us
money every month for the rest of your app's life and we'll draw an owl for
you".

------
lucisferre
I would strongly disagree that it is ok to use jQuery with Vue. I mean sure,
it's _ok_ in that most of the time it isn't going to hurt or break anything,
at least if you are just using it to query elements from the DOM.

However, I would argue that is not _ok_ in that it should never be necessary
and it's use would be a code smell to me and indicate that the code in
question is likely not using Vue properly.

I suspect it would be more valuable in the long term to ask people to take
more time and learn to use Vue instead of jQuery to solve the problem at hand.

Edit: I should note that Gitlab came to the same conclusion and I misread
their comments on it as accepting the argument that it would be ok for
querying the DOM. What the article says:

> At first I had several discussions about using jQuery with Vue. Some had
> said it might be OK, but only in read-only (querying) situations. However,
> after doing the research, we found that it is not a good idea to use jQuery
> with Vue. There will always be a better solution. We found that if you ever
> find yourself needing to query to DOM within a Vue architecture, then you
> are doing something wrong.

This I completely agree with.

~~~
sametmax
Vue and jquery works ok together.

First, you can gradualy migrate from jquery dom to vue. As both are very
light, having both is not bloated.

Plus, you need something to do ajax anyway, and if your site uses it, why add
axios as well?

Actually I'd say that vue is probably the best tech if you want to
progressively improve a legacy jquery heavy website instead of doing a
complete rewrite.

~~~
petepete
Isn't fetch widespread enough to use these days?

~~~
sametmax
Only if you want to ignore 12% market share or use a polyfill:

[https://caniuse.com/#search=fetch](https://caniuse.com/#search=fetch)
[https://www.netmarketshare.com/browser-market-
share.aspx?qpr...](https://www.netmarketshare.com/browser-market-
share.aspx?qprid=2&qpcustomd=0)

Plus, although fetch is tremendously better than XMLHttpRequest, it still has
quirks. It doesn't send cookies by default. The promise resolve on success on
code 400 and 500. Headers are verbose. You have to encode and decode json
manually. You have to force CORS for it to work.

The end of this article show you the problem:

[https://medium.com/@shahata/why-i-wont-be-using-fetch-api-
in...](https://medium.com/@shahata/why-i-wont-be-using-fetch-api-in-my-
apps-6900e6c6fe78)

Eventually you end up writting code to wrap fetch. So why not just use jquery
or axios ? It's already documented and tested.

------
juddlyon
React made me feel stupid, Vue made me feel smart. So I use Vue. I came at it
as a long-time jQuery dev with Angular 1 experience.

~~~
nightski
In general it's best to push your comfort boundaries. It's called learning.
I'm not saying React is better than Vue (I honestly think they are very
similar). Just that picking a technology based on whether it challenges you or
not is probably not the best strategy.

~~~
ademup
I strongly disagree. Parent poster specifically states 'as a long time jquery
dev...', so their objectives almost certainly do not aline with those of a
student. Indeed, "picking a technology based on whether it challenges you or
not..." Has almost no value at all for a prudent, real-world dev making real
world software.

~~~
nightski
The problem is experience in jQuery and even Angular 1 are not relevant to the
issue of why React (or even Vue for some) may be perceived as difficult. They
use a very different model.

Emacs was very difficult for me when I first started learning it. It was much
more difficult than using a simple text editor (and this was with 10 years of
programming experience)! Yet I persevered and you know what? After giving it
some time and learning it properly I found myself vastly more productive with
the tool.

Some things don't lend themselves well to immediate gratification. If the OP
provided even a hint as to why React was more difficult for him I'm guessing
it's not something with React but rather that he was using two completely
different state management solutions.

~~~
thebigkick
Curious, how long did it take before you before emacs was your go-to choice?

I'm a big vi and sublime text user but always open for better tooling.

btw - I actually agree with you on the learning thing but React just sucks.
I'm able to get shit done with Vue and at the end of the week I haven't wasted
three afternoons learning jsx/webpack/deployment/relearning-a-new-way-of-
doing-css blah blah. I say this with some hesitation but CSS is a solved
problem in my opinion with Sass.

------
pluma
I'm very happy the React and Vue projects are headed by people like Evan You
and Dan Abramov, not HN commenters. The hostility in these threads is
upsetting. There is no _best_ approach and both React and Vue have their
worth, if you like them or not.

Every time I see a topic about Vue or React (or practically anything JS
related) I see the polar opposite of the disarming friendliness coming from
the community leaders on Twitter.

~~~
erikpukinskis
It’s true, that H.N. Commenters guy is a real piece of work.

... But in all seriousness, there is a diversity of viewpoints here. It’s a
conversation and people vote up things they find thought provoking. Would you
prefer only people who think React and Vue are great post here?

~~~
pluma
I don't mind people having opinions. I mind people denouncing everything that
competes with their personal preference. Note how I said "hostility".

I'm talking about comments like

"God this is horrible. It's ugly. Hard to read."

"ugly piece of code"

"React failed miserably"

"The JS ecosystem is like the baskin robbins of st"

and so on.

------
Karupan
I personally have been bitten by the two way binding and CSS in JS "feature"
more than once. As an angular developer for two years, it frustrated me to no
end.

React took time to learn, but it was definitely worth it. The one way data
flow and explicit event handling (aka no ng- or v- tags) just seems cleaner to
me.

Of course this is no way a critique of Vue. Its a great framework for people
who want that sort of thing.

------
zackify
Why is GitLab putting data into their html? "You can pass your endpoints in
through the data attributes." Why store endpoints and other js related data on
a DOM element. This sounds like a left over paradigm they kept from their
jQuery mindset, or am I mistaken?

~~~
filipa
Hi! I am a Frontend engineer at GitLab.

Our frontend application was originally built with Rails. When we added Vue,
we did not refactor our entire code base.

This means that we've kept the existing server rendered pages. Once the page
is rendered we build our vue app on top of it.

The reasons why we pass certain data through HTML is: 1 - Avoid duplication.
Our endpoints and paths are still built in rails, by passing them through data
attributes we keep only one single source of truth 2 - Passing data from the
server to the Vue App Some data is not being sent through the API, but we
still need to access it. For those cases we also use the data attributes.

We know that this is not ideal but it was a mid term solution that allowed us
to quickly add Vue.

You can read more about our architecture with Vue in this blog post:
[https://about.gitlab.com/2017/06/29/gitlab-at-vue-
conf/](https://about.gitlab.com/2017/06/29/gitlab-at-vue-conf/)

~~~
zackify
Awesome, makes perfect sense :) I get why you guys have to do this now.

------
neals
I wanted to build something in Vue a few months ago. I really like the single-
file-component thing. I also like the code to update automatically and my
browser to refresh.

I decided on Webpack. First time using it and no idea where to get started. I
ended up downloading some boilerplate webpack / vue / vueX that now does
everything for me, but I have no idea what webpack is actually doing or how it
is doing that. I'm not even sure how big this stack is... how big is my chain
of dependencies here?

Am I going to be in trouble at some point? It feels like I'm on borrowed time
here and my little house of cards will come tumbling down soon.

~~~
breakingcups
I'm in a similar boat right now, I started exploring Vue with the vue-cli
default template and VS Code. Webpack and the associated npm ecosystem scares
me to no end. When it works, it works wonderfully but it is so incredibly
fragile and built upon assumptions that might change if you do not use the
exact flavor of tools and utilities the creator of the template does.

For a long time, the way webpack worked in the Vue template was at least 70%
black magic to me. I had some issues with it, sometimes I solved those issues
after google-ing a lot and landing on completely unrelated projects Github
issues for a fix. I never quite felt that I had mastered that whole ecosystem
like I felt I had mastered my regular programmin languages and tools.

My day job is C# and my day IDE is VS2017. I've been given permission to
explore doing a new application in .NET Core with Vue. So, I've started to
translate the default template from vue-cli to Visual Studio and I have
learned a LOT by trying to glue these pieces together that no one else seems
to have glued together for me. Luckily, MS has done a lot of work to make
React play nice with VS2017 and that seems to benefit Vue as well.

I'm not quite there yet, a few last issues remain. Most of them have to do
with Intellisense's understanding of Typescript vs. Webpack's understandinf og
Typescript. Some remain unsolvable for now (Single File Components using
Typescript and SCSS).

Still, the point I'm trying to make is that being forced to read through the
entire thing has increased my understanding of the Webpack process immensely.
I feel like I'm at 80% mastery now.

------
jrochkind1
This is one of the most aggressive, defensive, and religious comments thread
list I've ever seen in a highly rated HN post. Not sure what to take from
that.

~~~
Etheryte
Javascript libraries and their preferences are always a high tension
discussion because at the end of the day, it often comes down to whether you
made the right decision for years to come.

~~~
hmillison
Totally agreed. Unfortunately (and fortunately, depending on how you look at
it), there is no single benevolent dictator of JS to help you make your
decision like in other communities.

I think this quote from this article is a good summary of this discussion:
"Scala people don't have time for redditing and blogging, they're busy getting
crap done."

While it might seem like all the JS devs are arguing on here over their
choices, there are many folks who are silently being incredibly productive
with whatever tool they choose.

------
ZenoArrow
I hope one day more web developers will realise all the major JS frameworks
are just a band aid to plug the gaps in vanilla JS. It should be easy to build
web apps using vanilla JS. No frameworks pushing a certain way of working,
just a reliable batteries-included language that you're free to extend with
your own application-specific extensions and mix-and-match external libraries,
just like desktop app developers have taken for granted for over a decade.

~~~
mort96
Say that your opinion is correct, and every web developer agrees with it. What
could web developers do about it? The gaps you are talking about in vanilla JS
does exist, so until they're plugged, web devs would still prefer to use these
frameworks until the standard bodies and browser vendors make a better
alternative.

Web Components might be the solution, but it's not exactly ready yet:
[https://caniuse.com/#search=components](https://caniuse.com/#search=components)

~~~
ZenoArrow
Web Components are a good step forward.

To understand how to improve JS, try writing in vanilla JS (no frameworks) and
find the common pain points. Organise with fellow JS developers to get
features to address these shortcomings in the EcmaScript standard. Once this
is done, use tools like Babel to polyfill the missing functionality from the
EcmaScript standards until browser vendors implement them. Rinse, repeat.

------
IgorPartola
I love me some Vue. VueX is actually quite simple, especially compared to
Redux. It doesn’t try to invent too much new terminology.

I did end up needing to reach for jQuery in two situations with Vue. First was
to auto focus form inputs when the form becomes visible. For the life of me
could not find a good way to do this with Vue. Second was when a particular
architecture of the app required using lots of modals. Vue just doesn’t do
well with components that live inside modals and need to be reset whenever a
modal is opened or closed. Basic CRUD using Bootstrap modals is a huge pain,
especially the Update mode. I ended up creating rather gross hacks for
notifying the component in the modal that it needs to be reset.

One of the coolest things I did with Vue/VueX is having updates about server
side events delivered via WebSockets. A single generic connection to the
server pushes CUD events about all the relevant models to the client, where
VueX duetifully executes the ADD/UPDATE/REMOVE actions for instant updates to
all parts of the app.

------
kabes
Although they are very different under the hood, as a developer the experience
vue gives is very much like component based angularjs (version 1). Yet
everyone seems to hate angular 1, while they love vue. I really can't see why.

------
agentPrefect
So I've used Vue for personal projects before, it's really nice. I lead the
dev on a small team within a large corporate company, we focus on React &
Angular(io).

The primary reason why I would not adopt Vue is because Vue is still driven by
Evan You - which is great, but if something had to happen to the guy (and I
hope nothing does), I'm unsure Vue would have the long term support & drive it
does right now.

~~~
Etheryte
While Evan is currently the main force behind Vue, there are many large
companies with stake in it, as well as a reasonable number of contributors.
Personally I prefer the current state of operations over the dense bureaucracy
surrounding some other libraries, but you’re obviously free to disagree.

~~~
agentPrefect
Nothing to disagree on. :)

------
lsllc
Hmmm ... This is almost certainly a repost, but it comes to mind reading these
comments:

[https://hackernoon.com/how-it-feels-to-learn-javascript-
in-2...](https://hackernoon.com/how-it-feels-to-learn-javascript-
in-2016-d3a717dd577f)

------
luord
Great write-up. I'll keep in mind, specially for when I have to migrate a
traditional server-side application into a SPA.

