13 ms·

How we do Vue at GitLab: one year later

385 points by unnawut 9y ago

zackify 9y ago
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?
- ftxrcc 9y ago
  Because it works, it's simple (requires not much overhead), and sometimes it's just the best option. This "hurr jQuery and everything it brought sucks" mentality is not good.
  - zackify 9y ago
    HTML is for displaying information, not being littered with things js needs to query for and access. That's the whole point of using something like vue? Put a function on the vue component that will make a request, keep all the data stuff in vue.
    - dubcanada 9y ago
      While I largely agree, that's not really true... React for example wrecks your HTML with react related attributes on every DOM element. There is nothing wrong with storing some information in the DOM.
      - zackify 9y ago
        This is not the same as what gitlab is doing. React had attributes in order to remount correctly on the client side after a server render, this was removed. Using the latest react versions have nothing on the dom that isn't specifically needed to render correctly.
      - gravity13 9y ago
        >There is nothing wrong with storing some information in the DOM. Except you're coupling your application state with the document model. If you ever do anything to change the DOM later on, (like installing React into your codebase) it'll come back to bite you in the ass hard, as now you need to find a means to communicate state that you just threw into the DOM like it were a slightly more acceptable global variable.
- deleted 9y ago
  [deleted]
- pythonaut_16 9y ago
  I don't know GitLab's exact motivations although I noticed the same thing. I suspect it might be because they're using Vue components on already existing Server Rendered pages as opposed to a full SPA, so by passing the endpoint in the template they can allow the actual URL for that page to be set in the controller, maintaining cohesiveness. E.g. on the server-side .html.erb they'd have something like `<div... data-endpoint="@controller.url">...</div>`
  - zackify 9y ago
    Just feels like you're halfway following good JS practices. Ex: using Vue is great, but still rendering templates the "old way" instead of server rendering correctly for the whole app and having components remount. Totally get your point :)
    - deleted 9y ago
      [deleted]
    - pythonaut_16 9y ago
      I don't disagree but the real power of Vue is that you can immediately start using it in your existing application without having to jump to a full SPA. Vue works just as well when added to a single page or feature in an existing application as it does in a full SPA
- filipa 9y ago
  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 9y ago
    Awesome, makes perfect sense :) I get why you guys have to do this now.
ng12 9y ago
> 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.
- sametmax 9y ago
  It avoids it by design. Most of my vue project only uses vue. Not even webpack. Just the static vue file. I don't even have that many components because view doesn't force that on me. It's good enough and fast enough as it is for most medium side projects. And the awesome thing is that you can scale it up for this one big project you need it for.
- a13n 9y ago
  When did new react developers start learning redux? From my experience that just isn't true.
  - lucideer 9y ago
    While I personally avoided this pitfall and learnt React alone before Redux, I have not meet anyone else who did the same. Literally everyone I've talked to about learning React did so (or tried, and failed to do so) with both, up front.
    - a13n 9y ago
      Wow, I wonder where people are getting the idea that they need to learn Redux. If you start a new job at a company that uses React, then you probably need to learn React + Redux simultaneously. But if you're just picking up React, Redux isn't useful whatsoever. This image, from React conf years ago, communicates this sentiment perfectly: https://i.stack.imgur.com/tnk9a.png https://i.stack.imgur.com/tnk9a.png
gt5050 9y ago
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 9y ago
  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> ) }
  - untog 9y ago
    That really doesn't work well with: > Our designer could churn out neat html/css, but was a beginner in Javascript. I write JS every day, and frankly that code looks like an unholy mess to me, so I can't imagine what it looks like to a beginner. Is "styled.div``" a function call? It's not self-evident. How do you do inheritance? Is that a template string with functions inside it? Would that CSS autocomplete? That code looks very much like it sacrifices ease of writing CSS for ease of writing JSX. That isn't the correct tradeoff for everyone.
juddlyon 9y ago
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 9y ago
  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.
  - jazoom 9y ago
    I'm sure the point was, why build an app with a difficult platform when the is an easier-to-use platform that does the same thing.
  - ademup 9y ago
    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 9y ago
      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.
deleted 9y ago
[deleted]
lucisferre 9y ago
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.
- demircancelebi 9y ago
  AFAIK, their old codebase was full of jQuery and they are replacing some parts with Vue, hence they use both. They might not have used jQuery at all if they were starting from scratch.
  - lucisferre 9y ago
    Perhaps not, but there is no reason to use jQuery within the Vue components. Doing so now means that it is basically there to stay. That may be acceptable, but it is definitely unnecessary.
- deleted 9y ago
  [deleted]
- sametmax 9y ago
  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.
jrochkind1 9y ago
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 9y ago
  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 9y ago
    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.
  - always_good 9y ago
    This explains a lot of fanboism in general. Like when I would argue about how Xbox > PS3 on forums as a kid because my parents certainly weren't going to buy me both. I was stuck with the Xbox so I had to validate that reality to myself by defending it on the internet. It's no different on HN.
luord 9y ago
Great write-up. I'll keep in mind, specially for when I have to migrate a traditional server-side application into a SPA.
agentPrefect 9y ago
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 9y ago
  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 9y ago
    Nothing to disagree on. :)
Karupan 9y ago
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.
ZenoArrow 9y ago
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 9y ago
  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 9y ago
    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.
- Too 9y ago
  Easiest way to solve this would be to simply bundle a precompiled Vue into the browser and call it a day.
  - ZenoArrow 9y ago
    Vue is not a one-size-fits-all solution though is it.
neals 9y ago
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.
- jbreckmckye 9y ago
  I'm actually writing about this right now. I've worked with a lot of teams that have kicked off big, production-grade applications with boilerplates like Create-React-App. Your intuition is right: they get to prod having no idea how their buildchain works, and once something goes wrong they're stuck. You really don't want your first time reasoning about your build process to be some kind of deployment disaster or production bug. And that's exactly what these tools are selling you.
- swsieber 9y ago
  I found this link to be an enlightening tutorial on webpack: https://what-problem-does-it-solve.com/webpack/intro.html https://what-problem-does-it-solve.com/webpack/intro.html
- breakingcups 9y ago
  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.
IgorPartola 9y ago
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.
pluma 9y ago
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 9y ago
  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 9y ago
    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.
kabes 9y ago
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.
lsllc 9y ago
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-2016-d3a717dd577f https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...

385 points by unnawut 9y ago

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?

ftxrcc 9y ago
Because it works, it's simple (requires not much overhead), and sometimes it's just the best option. This "hurr jQuery and everything it brought sucks" mentality is not good.
- zackify 9y ago
  HTML is for displaying information, not being littered with things js needs to query for and access. That's the whole point of using something like vue? Put a function on the vue component that will make a request, keep all the data stuff in vue.
  - dubcanada 9y ago
    While I largely agree, that's not really true... React for example wrecks your HTML with react related attributes on every DOM element. There is nothing wrong with storing some information in the DOM.
    - zackify 9y ago
      This is not the same as what gitlab is doing. React had attributes in order to remount correctly on the client side after a server render, this was removed. Using the latest react versions have nothing on the dom that isn't specifically needed to render correctly.
    - gravity13 9y ago
      >There is nothing wrong with storing some information in the DOM. Except you're coupling your application state with the document model. If you ever do anything to change the DOM later on, (like installing React into your codebase) it'll come back to bite you in the ass hard, as now you need to find a means to communicate state that you just threw into the DOM like it were a slightly more acceptable global variable.
deleted 9y ago
[deleted]
pythonaut_16 9y ago
I don't know GitLab's exact motivations although I noticed the same thing. I suspect it might be because they're using Vue components on already existing Server Rendered pages as opposed to a full SPA, so by passing the endpoint in the template they can allow the actual URL for that page to be set in the controller, maintaining cohesiveness. E.g. on the server-side .html.erb they'd have something like `<div... data-endpoint="@controller.url">...</div>`
- zackify 9y ago
  Just feels like you're halfway following good JS practices. Ex: using Vue is great, but still rendering templates the "old way" instead of server rendering correctly for the whole app and having components remount. Totally get your point :)
  - deleted 9y ago
    [deleted]
  - pythonaut_16 9y ago
    I don't disagree but the real power of Vue is that you can immediately start using it in your existing application without having to jump to a full SPA. Vue works just as well when added to a single page or feature in an existing application as it does in a full SPA
filipa 9y ago
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 9y ago
  Awesome, makes perfect sense :) I get why you guys have to do this now.

ng12 9y ago

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

sametmax 9y ago
It avoids it by design. Most of my vue project only uses vue. Not even webpack. Just the static vue file. I don't even have that many components because view doesn't force that on me. It's good enough and fast enough as it is for most medium side projects. And the awesome thing is that you can scale it up for this one big project you need it for.
a13n 9y ago
When did new react developers start learning redux? From my experience that just isn't true.
- lucideer 9y ago
  While I personally avoided this pitfall and learnt React alone before Redux, I have not meet anyone else who did the same. Literally everyone I've talked to about learning React did so (or tried, and failed to do so) with both, up front.
  - a13n 9y ago
    Wow, I wonder where people are getting the idea that they need to learn Redux. If you start a new job at a company that uses React, then you probably need to learn React + Redux simultaneously. But if you're just picking up React, Redux isn't useful whatsoever. This image, from React conf years ago, communicates this sentiment perfectly: https://i.stack.imgur.com/tnk9a.png https://i.stack.imgur.com/tnk9a.png

gt5050 9y ago

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 9y ago
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> ) }
- untog 9y ago
  That really doesn't work well with: > Our designer could churn out neat html/css, but was a beginner in Javascript. I write JS every day, and frankly that code looks like an unholy mess to me, so I can't imagine what it looks like to a beginner. Is "styled.div``" a function call? It's not self-evident. How do you do inheritance? Is that a template string with functions inside it? Would that CSS autocomplete? That code looks very much like it sacrifices ease of writing CSS for ease of writing JSX. That isn't the correct tradeoff for everyone.

juddlyon 9y ago

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 9y ago
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.
- jazoom 9y ago
  I'm sure the point was, why build an app with a difficult platform when the is an easier-to-use platform that does the same thing.
- ademup 9y ago
  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 9y ago
    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.

deleted 9y ago

[deleted]

lucisferre 9y ago

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.

demircancelebi 9y ago
AFAIK, their old codebase was full of jQuery and they are replacing some parts with Vue, hence they use both. They might not have used jQuery at all if they were starting from scratch.
- lucisferre 9y ago
  Perhaps not, but there is no reason to use jQuery within the Vue components. Doing so now means that it is basically there to stay. That may be acceptable, but it is definitely unnecessary.
deleted 9y ago
[deleted]
sametmax 9y ago
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.

jrochkind1 9y ago

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 9y ago
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 9y ago
  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.
- always_good 9y ago
  This explains a lot of fanboism in general. Like when I would argue about how Xbox > PS3 on forums as a kid because my parents certainly weren't going to buy me both. I was stuck with the Xbox so I had to validate that reality to myself by defending it on the internet. It's no different on HN.

luord 9y ago

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

agentPrefect 9y ago

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 9y ago
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 9y ago
  Nothing to disagree on. :)

Karupan 9y ago

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.

ZenoArrow 9y ago

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 9y ago
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 9y ago
  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.
Too 9y ago
Easiest way to solve this would be to simply bundle a precompiled Vue into the browser and call it a day.
- ZenoArrow 9y ago
  Vue is not a one-size-fits-all solution though is it.

neals 9y ago

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.

jbreckmckye 9y ago
I'm actually writing about this right now. I've worked with a lot of teams that have kicked off big, production-grade applications with boilerplates like Create-React-App. Your intuition is right: they get to prod having no idea how their buildchain works, and once something goes wrong they're stuck. You really don't want your first time reasoning about your build process to be some kind of deployment disaster or production bug. And that's exactly what these tools are selling you.
swsieber 9y ago
I found this link to be an enlightening tutorial on webpack: https://what-problem-does-it-solve.com/webpack/intro.html https://what-problem-does-it-solve.com/webpack/intro.html
breakingcups 9y ago
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.

IgorPartola 9y ago

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.

pluma 9y ago

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 9y ago
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 9y ago
  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.

kabes 9y ago

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.

lsllc 9y ago

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-2016-d3a717dd577f https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...