GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-11-10) - page 1 of 10
 
___________________________________________________________________
How we do Vue at GitLab: one year later
138 points by unnawut
https://about.gitlab.com/2017/11/09/gitlab-vue-one-year-later/
___________________________________________________________________
 
ng12 - 3 hours 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.
 
  a13n - 3 hours ago
  When did new react developers start learning redux? From my
  experience that just isn't true.
 
    lucideer - 3 hours 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 - 3 hours 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
 
        k__ - 3 hours ago
        I started with Redux too, because the lead dev on a project
        said it's a must.Now I did two projects without and
        everything is nice and simple.
 
          a13n - 2 hours ago
          It's definitely a must after a certain codebase size. 20k
          LoC maybe? But for personal projects, no way.
 
        sotojuan - 1 hours ago
        > Wow, I wonder where people are getting the idea that they
        need to learn ReduxBecause everyone with a React job or
        substantial React project uses Redux (or a similar
        library). It is common for junior devs to rush through
        learning libraries in hopes of being employable or a "real
        developer" as soon as possible.
 
    ng12 - 3 hours ago
    The majority of complaints I hear (either at work or online)
    about React are actually about the React ecosystem -- they have
    trouble with Webpack or Redux and throw the baby out with the
    bathwater. I think very few people learn React by writing a
    pure app (e.g. hand-compiled, no state library).React itself is
    an incredibly simple library: you can explain the entire thing
    in a few sentences. In my experience it has an undeserved
    reputation for being more complex than Vue.
 
    giobox - 1 hours ago
    If you are working with React in a professional setting, Redux
    is practically the default choice for state management. If you
    are building something in a professional setting with React,
    there's a pretty good chance it's complex enough that it needs
    a state management library like Redux to do well.Almost
    everyone I know learning React in a professional capacity ends
    up having to learn Redux at much the same time, my experience
    is very much the opposite.
 
    SwellJoe - 2 hours ago
    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.
 
    acemarke - 2 hours ago
    I'm a Redux maintainer, and I spend most of my free time
    answering questions about React and Redux.Yes, since probably
    early 2016, many tutorials have basically said "you need to
    learn React and Redux together", and that's the message that a
    lot of junior devs have been taught.However, my own advice is
    the same as Dan Abramov's: you should focus on learning React
    first.  Once you understand React thoroughly, then you'll
    better understand why a state management lib like Redux _may_
    be helpful for your situation.
 
      sillysaurus3 - 2 hours ago
      However, my own advice is the same as Dan Abramov's: you
      should focus on learning React first. Once you understand
      React thoroughly, then you'll better understand why a state
      management lib like Redux _may_ be helpful for your
      situation.That's not really a fair position to take. It
      basically allows you to believe that React and Redux don't
      need to be learned together.Put yourself in the shoes of a
      CTO at a new startup. They need to decide whether to build
      their company on top of React or Vue. They need to make this
      decision quickly.Is it really fair to say they don't need to
      learn Redux? And that maybe Redux won't apply to their
      situation?Of course Redux will apply, because Redux is for
      all intents and purposes how you manage state at scale. And
      everyone who's entering the field who isn't a junior dev is
      thinking "We need to come up with a way to manage state at
      scale. Does Vue help us do that, or are we stuck with
      React+Redux?"It really doesn't help matters when you look
      into big players like airbnb and discover that they wrote
      their own state management framework rather than use Redux.
      They even have a two week onboarding process for new devs
      that teach them how to write features using their blend of
      tech. It's a bit... Eh... The whole thing just feels like
      WPF, a dead technology that few people here have probably
      heard of. There must be a simpler way.
 
        ng12 - 1 hours ago
        > Put yourself in the shoes of a CTO at a new startupOkay,
        how big is our web application? A few pages with a form?
        We'll avoid Redux for now. We might even avoid React.It's
        like anything else: should you set up a Spark cluster if
        you're only processing Gb's of data? Probably not, but you
        might need it some day -- so make your best guess.
 
        rescripting - 1 hours ago
        If you're the CTO of a new startup, don't pick a technology
        to build your startup in without building something with
        that technology first.Build something small. Learn React.
        When you're comfortable, and your small app grows in to
        something a bit bigger that might merit it, learn
        Redux.Then, build something small. Learn Vue. Repeat.Now
        you understand both options enough to make an educated
        decision. Feel confident building your big, gotta-get-it-
        right-off-the-bat startup project in whatever works best
        for you.
 
          sillysaurus3 - 1 hours ago
          Certainly, and that's the way to do it. My point is, you
          end up converging on learning Redux. You really do learn
          Redux no matter what, so it's kind of a myth that you
          "don't need to learn Redux."Theoretically, you can get by
          without learning it. In practice, the moment you try to
          build a real company, you need it. That necessitates
          learning Redux.I think this is an uncomfortable thought
          because it implies that Vue is way easier for devs to get
          into, and that's step one to displacing React+Redux. But
          that seems like an uncomfortable truth.Whoever is in
          charge of React needs to give Vue the Snapchat treatment.
          Take them seriously as competitors. There's still time.
 
          ng12 - 1 hours ago
          I don't understand your argument -- wouldn't it follow
          then that Vue devs converge on learning VueX? VueX is
          very similar to Redux, I don't see how that's a point in
          Vue's favor if our metric is time spent learning.
 
          sillysaurus3 - 1 hours ago
          It's roughly a bajillion times easier to learn. And that
          counts for a lot.You have to take yourself out of the
          "experienced React+Redux dev" mindset and put yourself in
          the shoes of "Experienced dev looking to invest in one of
          two ecosystems" mindset. Which one is the path of least
          resistance?The point is, React+Redux people would love to
          believe that it's "Vue+VueX." But in reality, it feels
          like "just vue." A sword is stronger as a single piece,
          and Vue+VueX feels like a single piece.It's up to people
          to learn both and decide for themselves, but my argument
          is simply this: it's a mistake to underestimate the
          traction Vue is gaining.There's a strong temptation to
          blame the dev: They're not smart enough, they should have
          been able to pick up Redux easier, Vue+VueX is the same
          as React+Redux. But all I can do is report my
          experiences, and an honest survey of the ecosystem would
          lead us to conclude that Vue+VueX is far easier to learn
          without sacrificing any flexibility for your company in
          the long run.
 
          ng12 - 1 hours ago
          I think you've made several assertions about Vue which
          reflect an inherent bias. VueX and Redux are _remarkably_
          similar libraries and I think your assertion that VueX is
          easier to learn (egregious hyperbole aside) is a pretty
          weak argument.To be clear: I like both React and Vue and
          am fundamentally skeptical of arguments that one is
          significantly better/worse/different than the other.
 
        shados - 2 minutes ago
        > Put yourself in the shoes of a CTO at a new startupMy
        first step is to hire someone that knows how to build a FE
        app. We'll use the tool that someone is familiar with.If
        you're a CTO of an incubator startup with 2 people straight
        out of college who learnt Python and basic JavaScript and
        you're trying to build a serious web app from there, well,
        it doesn't really matter what you pick, you'll have to
        rewrite it in a few months anyway (that's a pretty common
        scenario).
 
  josefrichter - 2 hours ago
  Rookie Vue dev here. I found Vue super easy to understand and to
  start using for my own simple stuff basically from day 1.
  Gradually as my tiny projects grew in complexity, I naturally
  started to feel the need to manage state better. And again, Vue
  docs led me gradually thru pure-Vue solutions towards VueX. It
  all felt very naturally, the documentation didn?t push me to
  anything, just gave me answers at my pace. Can?t say the same
  about React, even though I?m a big fan of both.
 
    stevenwoo - 1 hours ago
    How are you learning Vue?  Looking to expand my toolkit.
 
  sametmax - 1 hours 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.
 
  k__ - 3 hours ago
  Funny thing is, Vue wihtout extras is more complex than React
  without extras.
 
    jaequery - 2 hours ago
    no, it's actually quite the opposite. vue took all the
    complexities out of react/redux it's not even funny.
 
      k__ - 2 hours ago
      I'm not talking about Redux.
 
        sillysaurus3 - 2 hours ago
        Then it's an unfair comparison. Vue does state management
        out of the box. React really doesn't. Yeah, it has
        setState, but that's nothing compared to Vue.
 
          ng12 - 2 hours ago
          I'm very skeptical of that assertion. Can you provide an
          example of something Vue provides that React does not?
 
          [deleted]
 
          k__ - 2 hours ago
          With Vuex?
 
    sametmax - 1 hours ago
    Nope. Nope. Nope.Trainer here. I train in React and in Vue.My
    students do 3 times the work with raw vue than in raw react.
    Every one of them. All the time.It's not even on the same map.
 
      k__ - 1 hours ago
      Even if you ignore 2-way-binding?
 
        sametmax - 58 minutes ago
        The whole component russian dolls with data/callback
        passing is something most beginers have a very hard time to
        grasp. Add webpack to the mix, make them fight with JSX
        that doesn't want to do what they need and voila, you get a
        sad student.Starting with vue is just: add a script tag,
        put your template here, now your data here. Done.The start
        up experience is nothing alike.
 
          k__ - 21 minutes ago
          That wasn't my question, but okay. lol
 
      xeromal - 8 minutes ago
      I'd clarify your statement of "3 times the work" as a
      positive. I had to read twice to not think that Vue took 3x
      the effort to do something.
 
  fny - 3 hours ago
  What Vue can do is create a well-designed state management
  library that works out of the box without umpteen lines of
  boilerplate... and that's exactly VueX.If you love to type,
  though, I highly recommend Redux!    const ADD_TODO = 'ADD_TODO'
  import { ADD_TODO } from '../actionTypes'      function
  addTodo(text) {       return { type: ADD_TODO, text }     }
  dispatch(addTodo(text))
 
    ng12 - 2 hours ago
    I refuse to believe VueX is any simpler than Redux: https://git
    hub.com/vuejs/vuex/blob/dev/examples/counter/stor...Also you
    don't have to import your actions, it's just a smart thing to
    do. This gives me heartache a bit:
    https://github.com/vuejs/vuex/blob/dev/examples/counter/Coun...
 
      dubcanada - 2 hours ago
      It's not, it's literally the same (they said VueX is based on
      Redux). The difference is React.
 
        joshribakoff - 1 hours ago
        I disagree that its "literally" the same. Vuex requires you
        to mutate state, through their API (if declaring
        new/dynamic properties). Redux is agnostic about how you
        handle state, but encourages immutability. Vuex is
        inherently not immutable, its coupled to the vue reactivity
        system which is based on mutations & memoization.Vuex & Vue
        are the easier APIs to learn. Not only that the developer
        ergonomics are just better for Vue's API. For example in
        vue you have "mounted()" instead of "componentDidMount()"
        or "ngOnInit()". Likewise, redux requires learning CS terms
        (if you don't know them) like thunk, saga, memoized
        selectors, etc. Vue uses more layman's terms, like
        "computed" instead of "memoized selector" which just makes
        it easier to learn.My big hangup with Vue is having to
        declare reactive properties up front. It's author says this
        is a best practice anyways, but it leads to hard to debug
        issues when you accidentally declare new properties at
        runtime & you get race conditions. With react & redux both
        making immutability possible & encouraging immutability,
        you get easier to debug apps. But there is a more up front
        investment.I also really love Vue's single file components.
        I know you can do that in Angular & React, but again the
        API is just so much more ergonomic in Vue.
 
        watty - 2 hours ago
        It looks like VueX supports async out of the box.  That's a
        huge win IMO.
 
          ng12 - 2 hours ago
          Is it? I thought Redux abstracting out the thunk layer
          was silly until that line of thinking lead to Redux-Saga.
          It actually seems to have been a pretty smart move.
 
          watty - 1 hours ago
          There's vuex-saga as well.  Something built in would have
          been nice because even though sagas are cool, the
          learning curve is steep enough for me to avoid it in
          projects.
 
      conradfr - 40 minutes ago
      Vuex is simpler than Redux. First you don't have to grasp the
      Container/Component pattern. Second you have less middleware
      ("what, you don't use redux-saga and redux-think?").Vue and
      Vuex seem less clever JS (shiny es6 features), less clever
      programming (mutability etc) which I feel may be a detriment
      for complex apps in the long term but it is simpler.(I may be
      biased because before Vue and React/Redux I did Angular1 &
      React/Reflux and I view Vue as a Angular/React mix and Vuex
      is not far from Reflux)
 
        ng12 - 30 minutes ago
        > Container/ComponentThat's not part of Redux, it's a
        separate design pattern you can use with any Flux
        architecture. React-Redux doesn't even require you to do it
        that way, and for good reason: you might not need it.
        There's nothing wrong with just importing a store reference
        wherever you want it. That's a totally reasonable pattern
        for some applications.This illustrates my point I guess.
        There's so many people thinking about how to architect and
        implement React applications that there's a lot of cargo-
        culting.
 
    gravity13 - 1 hours ago
    To be fair, you don't really need to declare your constants
    elsewhere. This is just a pattern people stuck with, because
    they're stubborn about constants, I think. Doing a find/replace
    is so incredibly easy that it's kind of silly to add a bunch
    more boilerplate to protect against one DRY quip.
 
      ng12 - 1 hours ago
      I'm a really big fan of the Ducks pattern where your action
      types are private to each reducer unless they're explicitly
      exported as an API. In my own code I don't even do that,
      instead exporting a function which operates on the
      state.https://github.com/erikras/ducks-modular-redux
 
        gravity13 - 58 minutes ago
        Hm, interesting. I like it. I'm also curious about how
        selectors come into play here as well (exported getter
        functions for shielding app from reducer state shape).You
        might still need to place actions/selectors in their own
        directory since they're not necessarily specific to any
        reducer. I believe this is how sagas are organized, though.
 
  supernintendo - 1 hours ago
  I think one reason for that steep learning curve might be that
  many aspects of React, namely component lifecycles and state
  management within components, are abstracted away or simply moot
  once you start managing state with Redux. Also, while the two
  libraries work great together (I consider Redux indispensable for
  new React apps), they aren?t really similar as far as library
  design and patterns are concerned. Finally, there is something to
  be said about the mental overhead added by Redux middleware. If
  you?re dispatching async actions, you?re probably using Redux
  Thunk. If your app has forms, you might be using Redux Form (I
  honestly avoid it because its own abstractions and Field
  components end up getting in my way). Ultimately, the process of
  learning how to use all of these tools in tandem can feel
  somewhat disjointed, especially when you?re also integrating them
  with other parts of the web stack, modern and in some cases
  legacy.I?ve never used Vue but I?m also curious to see how it and
  VueX fares in this regard.
 
  gingerb - 1 hours ago
  > Redux came out, everyone fell in love with itNot me.
 
  jakecodes - 1 hours ago
  Hey ng12, author here. I totally agree with you. I am the biggest
  proponents of keeping things simple. I initially was hesitant to
  introduce Vuex. I've written a few huge apps in Vue without
  anything else but Vue. The cool thing is you can, of course,
  continue to do that. But again, you just have to follow some
  strict patterns. Or, to make it simpler, you can get some help
  from Vuex and let it help you follow those strict patterns.
  Either way, one is best off if they follow a strict pattern. If
  not self guided, then library guided. Especially on a big team
  you can reduce the stress of that strictness if everyone uses
  Vuex. With so much code flying through GitLab, Vuex is the
  answer, for quicker code reviews.
 
  dlwdlw - 2 hours ago
  From my experience telling people this doesn't work as everyone
  thinks they are smart enough to avoid the trap. Like many
  companies going into China assuming things will be easy. Code
  ends up complex yet works because the complexity was successfully
  wrangled, missing the point of complexity reduction rather than
  wrangling.Thematically, it may be a result of obsession over
  tools instead of product which occurs in other areas like
  photography, writing(hipster typewriters), and others. In tech,
  technology as lever supports a "hacker" mindset of getting 10 for
  1. However this misses the point of hacking to get around your
  weaknesses in order to focus on your core competency which MUST
  intrinsically have value instead of being an empty shell.The core
  competency for many client side developers is probably more
  rooted in a form of design than pure technical ability. Design,
  like music, writing, speaking, and art have incredibly low
  barriers to entry. This can create an arrogant mindset from
  people coming from more rigorous disciplines. Instead of focusing
  on the thing that must be done, they try to take shortcuts that
  only have the appearance of reaching the goal.
 
    sillysaurus3 - 2 hours ago
    One cure for this is to have someone who cares solely about
    simplicity, as an ideal above all else, in charge of technical
    decisions.When you're hyper-vigilant about simplicity, you end
    up creating the simplest design that meets the goals. It takes
    a little extra time, but it's so worth it.
 
juddlyon - 2 hours 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 - 2 hours 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 - 1 hours 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 - 1 hours 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 - 1 hours 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.
 
  savanaly - 36 minutes ago
  What was it about React that made you feel stupid? I can see how
  Redux would make someone feel that way but react is so simple I'm
  having a hard time visualizing someone not liking it for that
  reason.
 
    jorblumesea - 29 minutes ago
    Imo, doing it the "right way" and scalable requires a fair
    amount of knowledge about React before you pick it up. Things
    like ducks structure, redux thunks, store vs local state and
    other advanced usages. While not strictly necessary, it becomes
    increasingly important when building a large application. And
    then each of these are not official plugins so there's lots of
    differing opinions on how these pieces fit together.With Vue
    you can write a scalable understandable application using the
    documentation. The same criticisms do certainly apply, but many
    of the advanced features are worked into the application.For
    example Vuex is bundled into Vue and has verbose and
    opinionated documentation on how it lives in your vue
    application.
 
[deleted]
 
gt5050 - 2 hours 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 ComponentsSingle 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
thingsThis 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 availableExample:Google Search for '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] all top links
lead to official documenation on vuejs.org.Excellent
documentationAlso, 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
 
  sametmax - 1 hours ago
  Same. That and the fact it took me an afternoon to get an hello
  world with react and understand it. And 20 minutes with Vue.
 
    giantsloth - 57 minutes ago
    I implore you to checkout create-react-app to get a hello world
    really quick:https://github.com/facebookincubator/create-react-
    app  npm install -g create-react-app    create-react-app my-app
    cd my-app/   npm start  Your sentiment is correct that tooling
    around these pieces of technology needs to always be first
    class.  React failed miserably, and Vue did an AMAZING job.I'm
    probably starting to sound like a shill for React.  I've used
    both and love both.  I do like that React is "just javascript",
    which I think is why I use it.
 
      Fifer82 - 51 minutes ago
      React is the new JQuery, I really don't see Vue and Angular
      being in the same world as React.
 
        irrational - 24 minutes ago
        So, pretty soon we should see youdonotneedreact.com
        websites popping up?
 
        Rusky - 18 minutes ago
        As far as the actual libraries themselves go, if any of
        Vue/Angular/React are the new jQuery, it's Vue. It's the
        smallest of the three, but more importantly it's the
        easiest of the three to drop into a page without any
        tooling.
 
      sametmax - 42 minutes ago
      I used that. I took me a huge time just to understand what
      all the tooling was doing, how to integrate it in my current
      stack and how it was going to affect my current project.My
      pet peeve with react is that I can't just code. I have to
      stop every 10 steps and reflect on the tool I use, instead of
      the problem I'm trying to solve.
 
    allover - 53 minutes ago
    20 minutes vs an afternoon is probably not a great gauge for
    making technology choices.I highly recommend watching Rich
    Hickey's "Simple Made Easy" [1] talk which covers how the right
    ("simple") choice may not be the "easiest" (convenient, most
    familiar) one.[1] https://www.infoq.com/presentations/Simple-
    Made-Easy
 
      sametmax - 44 minutes ago
      I agree. Hence "that and".
 
        allover - 12 minutes ago
        I don't mean to be an arse, but if you agree with my point,
        then maybe you can see why I disagree that your "that and"
        is a valid strike against React/in favour of Vue.
 
  giantsloth - 1 hours 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 (       
  

 Hello 

         

 This is a thing 


       )   }
 
    untog - 1 hours 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.
 
      giantsloth - 1 hours ago
      Interesting critique.  I would highly suggest checking out
      template literals: https://developer.mozilla.org/en-
      US/docs/Web/JavaScript/Refe...Yeah styled.div is a function
      as you can check out in the mdn docs I linked, it's really
      cool stuff.Inheritance is done like:  const List = styled.ul`
      li {       padding: 10px;     }   `    const HeavyPaddedList
      = styled(List)`     li {       padding: 20px;     }   `  If
      you wanted to just change the li you'd have to:  const
      ListItem = styled.li`     padding: 10px;   `      const
      HeavilyPaddedListItem = styled(ListItem)`     padding: 20px;
      `  You're writing scss within the text blocks.  You're
      correct that you need some understanding of JS.I've never
      worked with designers that wrote css, I'd also probably not
      trust them to do so (my own failings).I don't agree that it
      looks like an unholy mess (hyperbole may be lost on me), but
      I can see how it could be jarring at first look.  I had a
      similar reaction when I looked at Relay
      (https://facebook.github.io/relay/), when they used literals
      for data fetching.
 
        untog - 42 minutes ago
        > You're writing scss within the text blocks.So, yeah, you
        lose all the syntax highlighting etc. that comes with just
        writing normal CSS. I don't think it's unreasonable for a
        designer to object to that - how would you feel if you were
        presented with a build system that required you to write
        all your JavaScript inside one big string statement?Maybe
        it's just me, but I don't find it intuitive at all.
        `styled` has properties for, I assume, every HTML tag? But
        it can also be called as a function for inheritance
        purposes? And that inherited call appears to use the same
        tag as its parent... but what if I want to reuse styles
        across different tags? How could I define some shared CSS
        properties I'd use across different elements?Don't get me
        wrong, it is cool stuff. But it also feels far too much
        like hand-wavey magic stuff. I've literally never used Vue
        before, but looking at this page:https://vuejs.org/v2/guide
        /single-file-components.htmlI have zero confusion about how
        to write styles for it. And I really don't understand why
        styled-components would be worth the extra effort by
        comparison. What does it bring to the table? It's different
        without a compelling reason for being different.
 
          shados - 10 minutes ago
          > So, yeah, you lose all the syntax highlighting etc.
          that comes with just writing normal CSSExcept you don't.
          Editor support is quite good, and syntax highlighting,
          syntax validation, auto-completion, etc all work.I mean,
          same way with Vue really. If the editor didn't know wtf a
          Vue file is, you'd lose all the integration too.
 
    sametmax - 1 hours ago
    God this is horrible. It's ugly. Hard to read. Things are
    scattered all over the code. And where is my sass ?
 
      giantsloth - 1 hours ago
      It doesn't support sass, but it does support scss.
 
        allover - 1 minutes ago
        To all intents and purposes, when people say Sass, they
        mean Scss.
 
lucisferre - 1 hours 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 - 1 hours 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 - 1 hours 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]
 
  sametmax - 1 hours 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.
 
    lucisferre - 1 hours ago
    Looks like I misread. They ultimately reached the conclusion
    that using jQuery was not ok. Good for them.I would argue as
    well that AJAX requests don't belong inside Vue components.
    They belong in services and those services should ideally be
    behind the Vuex store, but there is nothing wrong with not
    using Vuex.If we were just talking about using jQuery for AJAX
    given that you already were using it, then sure that's fine,
    use it instead of adding something else like axios. From the
    article what was being proposed was using it to query the DOM.
    There is no use case for that with Vue.
 
zackify - 3 hours 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 - 3 hours 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 - 3 hours 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 - 2 hours 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.
 
        gravity13 - 1 hours 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.
 
        zackify - 2 hours 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.
 
  filipa - 2 hours 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/
 
    zackify - 2 hours ago
    Awesome, makes perfect sense :) I get why you guys have to do
    this now.
 
  [deleted]
 
  pythonaut_16 - 2 hours 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`  endpoint="@controller.url">...

`
 
    zackify - 2 hours 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]