[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] 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 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>
    )
  }

[untog]

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]

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]

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

I 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]

> So, yeah, you lose all the syntax highlighting etc. that comes with just writing normal CSS

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

[untog]

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

In a way, that's fair. In another way, the example single component Vue file I linked to is an HTML file. It has a <script> tag and a <style> tag. Just associate .vue with HTML and you're done.

That gets to my broader point as well - styled-components reinvents the way you declare styles and the way you apply styles, and requires the entire thing to be written as a JS file. And for what? I still don't understand what the advantage is over a syntax everyone already knows (and has validators for already!)

[threatofrain]

I would argue that the right boundary for designers to be working with front-end people is via central company style assets, and not at the component level where ad-hoc styles should be stored.

It seems a little odd that the front-end designer, who is in our hypothetical not comfortable enough to actually work on component themselves, would be brought in to tag-team with someone else who also doesn't feel comfortable enough to do the work themselves.

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

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? ;)

[giantsloth]

It doesn't support sass, but it does support scss.

[allover]

To all intents and purposes, when people say Sass, they mean Scss.

[jrobn]

Code like parent comment is why I use Intercooler.js [1].

[1] http://intercoolerjs.org

[agumonkey]

Cute ideas in there. Much appreciated

[NumberCruncher]

It is a good example for solving problems without overengineering them.

[snarkyturtle]

There is the Vue equivalent though: https://github.com/styled-components/vue-styled-components

[nikcub]

Why do packages like this need to be ported or re-implemented for Vue rather than referenced? That package hasn't been updated since August while the root styled-components library has ~700 closed issues and 11,300 watchers

I've seen it with other stacks as well with almost complete re-implementations, a lot of duplicated effort and it feels like it goes against the packaging philosophy for javascript

[kimjongman]

ugly piece of code

[sametmax]

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.

[allover]

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]

I agree. Hence "that and".

[allover]

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.

[ZenoArrow]

Simplicity makes picking up the unfamiliar easier. You can't accurately deduce from time alone that the time to pick up Vue was based on familiarity with similar libraries.

[allover]

> Simplicity makes picking up the unfamiliar easier.

The talk I referenced talks about how the opposite is often true. Tools that result in objectively simpler systems can come with a initially steeper learning curve.

> You can't accurately deduce from time alone that the time to pick up Vue was based on familiarity with similar libraries.

True, I was really just suggesting questioning instincts when evaluating tools based on the initial 'time to get started'.

[giantsloth]

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.

[sametmax]

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.

[computerex]

I have no idea what you are talking about. React doesn't require any tooling. Drop a reference to React from some cdn in your HTML file and you are good to go. People confuse the myriad of libraries and tools complementary to React for React. You don't need create react app for Hello world.

Create React App gives you a zero configuration way to not only write hello world, but also bootstrap a non-trivial production ready application. In the company I work for, we were previously using JSPM/SystemJS/Gulp. We replaced all of that with create-react-app. It allows you to very easily bootstrap existing applications on top of it: http://fredrik.anderzon.se/2016/12/04/adding-create-react-ap...

And if you want full control of your project, you can "eject" and CRA will generate the webpack configuration file being used so that you can tweak to your heart's content.

I use React daily, and the whole experience has been extremely pleasant.

[kuschku]

The point is about not using external builds of react, but trying to understand what every piece does.

That means you want to be able to understand it well enough to write the webpack required for a react pack from memory.

And with react, that's years of learning.

[luord]

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

Thank you! Every time I've tried react (and enough attempts were made to finally decide it was just not for me), there was always something in the back of my mind that I didn't like and I just couldn't put it to words. You just described what it was.

And, if one forgoes tooling, then the situation is like the one you described in your previous comment: an afternoon just to get a "Hello world".

[spicyj]

What do you mean by “React failed miserably”?

[Fifer82]

React is the new JQuery, I really don't see Vue and Angular being in the same world as React.

[Rusky]

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.

[nightski]

I have a hard time understanding why this "drop in" experience is so important. Are you all writing simple contact us forms or something incredibly simple?

Any application that I've built which actually required a technology like Vue or React was a significant undertaking and a few hours getting up and going (not that either of them require anywhere close to that) is nothing.

[Rusky]

I don't see how jQuery could have been anywhere near as ubiquitous if it had required a build step.

It makes experimenting easier for beginners, for people considering switching to it, for people who are already using it and want to try something outside the context of their existing codebase, for people writing tutorials and demos, etc.

The less bullshit to wade through when using a tool, the more situations it will be applicable to, regardless of skill level or project size.

[sametmax]

First, as a learning experience it's easier. In the HN bubble it's easy to forget most web project out there don't even have npm installed. I regularly train dev that just learn what ajax means.

Secondly, a lot of my projects just don't need anything else. If i have a 2 weeks contract with a client, i'm not going to setup webpack, a ci server and docker.

Having the choice to scale up or down is an amazing feature.

[irrational]

So, pretty soon we should see youdonotneedreact.com websites popping up?

[gramstrong]

Once web components become standardized.

So...2030.

[spankalee]

They're standardized now:

https://html.spec.whatwg.org/multipage/scripting.html#custom... https://dom.spec.whatwg.org/#shadow-trees

[Fifer82]

React is opinionated document.write

[Griffinsauce]

Well... there is a good chance that you don't.

[shams93]

https://developer.mozilla.org/en-US/docs/Web/Web_Components/...

[nightski]

Which order did you attempt to learn them in? Is it possible taking the time to attempt to learn react affected how easy it was to pick up Vue? I know we love to hate on React here but they are very similar. Can you identify what in particular is so confusing with regards to react vs. vue? They have a very similar API.

[sametmax]

Vue dlc is better. Vue doesn't require webpack. All vue tutorials agree on how to so things and they work the first time you try them. You son't have to learn a new way to do templates or pass data. You can start withou components. You can even start without npm.

In summary, vue offers a simpler hands on experience while allowing smooth learning curve to more complicated setup matching react's.

React just throws you in unkown waters and say 'now swim'. And on the side of the river, 3 persons are screaming to you contradictory advices.

[nightski]

Vue requires webpack when going for anything beyond a simple hello world experience. At some point beginners are going to have to enter the real world.

BTW - You don't need webpack for React either. It is entirely possible to write React without it.

[sametmax]

> Vue requires webpack when going for anything beyond a simple hello world experience

Not at all. That's the beauty of it. A lot of projects just drop Vue in a script tag and use no components. There are 1000's of projects out there with such a scale that anything else would be overdoing it.

> BTW - You don't need webpack for React either. It is entirely possible to write React without it.

Technically yes. But realistically no. First, you will find almost zero doc/tutorials on how to do so. All the ecosystem and community assumes webpack, and a top-down component architecture. If you ask on a forum how to do x, people will promptly tell you to use Redux. And the React API is clearly not comfortable anyway without tooling.

It's a bit like saying "well you could perfectly code a Java project without an IDE". Yes you can. But who would do it ?

[dmitriid]

Why do Vue docs tell you to use webpack for “large, serious projects”? https://vuejs-templates.github.io/webpack

[delhanty]

Evaluating Vue and React at the moment:

From the Vue documentation [1]:

>Even if you don’t like the idea of Single-File Components, you can still leverage its hot-reloading and pre-compilation features by separating your JavaScript and CSS into separate files:

  <!-- my-component.vue -->
  <template>
    <div>This will be pre-compiled</div>
    </template>
  <script src="./my-component.js"></script>
  <style src="./my-component.css"></style>

If I end up going with Vue, I'd probably do that. It looks like a lot of boilerplate though ...

Is there any tool from the Node ecosystem designed to reduce that boilerplate?

Thanks for any insights!

[1] https://vuejs.org/v2/guide/single-file-components.html#What-...

[petepete]

I started off hating the idea of single page components; I'd have much rather had a component reside within a directory (with template.html, style.sass and script.es6.js files or whatever) but in reality, so long as you keep your templates light and do any heavy lifting elsewhere, it's quite manageable.

Newer JavaScript functionality makes that work nicely.

Almost all of my components fit on one screen.

[delhanty]

Evaluating Vue and React at the moment:

Another issue with CSS-IN-JS seems to be security - as it opens up another vector for cross-sight scripting attacks - see here for example. [1]

If I end up going with React, I'll probably avoid CSS-in-JS outside of React Native.

>You can’t use CSS in react-native apps. But you can use CSS-in-JS with styled-components. [2]

Disclaimer: met James K Nelson of reactarmory.com at #hntokyo on Thursday - otherwise unaffiliated.

[1] https://reactarmory.com/answers/how-can-i-use-css-in-js-secu...

[2] https://reactarmory.com/answers/should-i-use-css-in-js

[lenkite]

Well, this approach of single file components (.vue) containing separately scoped HTML, CSS and JS is what the Google Polymer team were recommending all the way for the last several years, but it seems no one was listening to them.

[lightblade]

> Standard / Official way of doing things

If you like that, why not go with Ember?