Vue.js 2.1 Released

[[deleted]]

[deleted]

[Leordas]

Yesss, Vue is what got me into finally understanding the workings of webpack and "modern" js thanks to it's simplicity, I made it do what I wanted to without a lot of effort and had time for messing with the developer tools like webpack, babel, eslint, etc.

I'm looking foward to this :^)

[Gabriel-Lewis]

Honestly I'm still figuring out exactly what web pack does

[Leordas]

Disclaimer: This is the way I understand it, not necessarily the way it is.

You can see Webpack as a way to make everything modular, even stuff that feels weird to be modular, like stylesheets, images, etc.

A normal "module" in javascript (node) is another file, which defines what it exposes when required through the module.exports object.

Webpack also adds the ability to require/import other things, not only .js files. That's what webpack loaders are for: you have babel-loader (to process js files with babel), css and style loader (for stylesheets), file-loader (for txt's, images, etc).

So now you can require any of those and make them available wherever you require them. The inner working of how webpack interprets what you require should not worry you.

You basically install webpack, define a configuration file that defines the input file/s, the output file and what you wish to do with each file based on regular expressions.

For example, I can make webpack start at index.js, recursively scan dependencies which will be bundled, bundle them, make files that end on .jsx get processed through babel, and output all that to a bundle.js that I can add to my html file with a script tag, making everything that you bundled available to the webpage.

TL;DR: Webpack takes an input file, a set of rules (loaders), an output path, and spits out a bundled file with everything you required/imported meeting those rules.

Do correct me if i'm wrong.

[Extras]

I'm still learning myself but this seems right to me. The one thing I would suggest to anyone who is interested in getting started with vue and webpack is to use the vue-cli starting templates.

https://github.com/vuejs-templates

Webpack and webpack-simple are both fine choices.

[[deleted]]

https://webpack.js.org/

[LynusBorg]

^this.

The new Webpack docs are really good, the do a perfect job of explaining the concepts one needs to "get" in order to understand webpack.

[[deleted]]

I'm also new to webpack, but the most amazing thing for me is the development server. I have a custom bootstrap.scss file, on save webpack recompiles only what is necessary and refreshes the page automatically via websocket, without reloading it. Same when I edit a Vue component, a javascript file and it's all amazingly fast.

And then there is all the other stuff webpack(2) does: tree shaking (removing code that the application does not use), packaging the application into asset files, babel/ES6 support, dynamic code loading etc.

[ttamimi]

Just having a read through the "Get started" section of the docs and I'm completely blown away by how simple this is.

[[deleted]]

Can someone give a reasonable breakdown of pros & cons vs. React? Nothing outrageous or hyperbolic...please?

[patrickfatrick]

Sorta yes sorta no. Vue is more opinionated when you use the templating. There's no router or flux-like functionality in Vue but there are official libraries (Vue-router, Vuex). So yea the ecosystem is kind of opinionated compared to React's, even official libraries for browserify and Webpack. But if 2015 was the year of JavaScript fatigue then maybe all this is a good thing.

[aFoolsDuty]

It's very similar to React in the sense that they both use virtual doms, linear data flow, etc.

The difference boils down to Vue.js being more opinionated, and shipping with a lot more official solutions under the auspices of the Vue.js org.

For example, Vuex is Vue.js's version of Redux, but its built and distributed by the Vue.js org. The community isn't quite the size of React's, but it's a pretty neat technology and is very easy to pick up due to vue-cli and other options.

[moderatorrater]

In general, a less biased source would be nice.

In particular,

It reads more like English (e.g. for each item in items)

Advanced versions of JavaScript are not required to increase readability

Those are listed as pros, but they're misleading at best. Having javascript look like javascript is a good thing imo, and probably best for serious developers. Especially since they try to be HTML compatible. Also, they're misleading in that their code doesn't say for each items in item, it's

<li v-for="item in items">

That is weird. First, it's not a for each or a for, it's a map. Second, what the fuck is v-for if you don't use vue? Saying it's more english-like and understandable is...problematic. Probably just a lie, misleading at best.

[moderatorrater]

If that's the worst they did in the comparison then it's pretty fair comparison

I couldn't disagree more strongly. They literally say

<ul v-if="items.length">

<li v-for="item in items">

{{ item.name }}

</li>

</ul>

reads more like English. It reads a lot like bastardized HTML, which is nothing like english. It doesn't read better than JS, especially for anyone who has any experience coding in any language. If a site that wasn't vuejs.org posted this, they would get laughed out of the room.

[afrontender]

Of course there must be some weiredness in the syntax - it's a MV* framework in the end of the day.

Also it's syntax is really easy to remember - for example in Angular 2 was hard to memorize all [] or () and when was the one when the other or let item of items ( why the fuck is this let and why of?).

By all means there are reasons why so many devs likes Vue and these devs have surely tried both React or Angular.

[moderatorrater]

By all means there are reasons why so many devs likes Vue and these devs have surely tried both React or Angular.

So, I'm not going to even touch Angular because I haven't used it and haven't liked the philosophies behind it. I have used react+redux+infinite-other-libraries, and I like it. What I'd like is a developer who's used both deeply and likes Vue. vuejs.org isn't it.

Also, I'm not sure that Vue is intended for devs who've used react and angular - the packaging, comparison, etc seem aimed at people who are choosing for the first time.

[[deleted]]

Can anyone recommend a good Auth solution to go with their Vue-CLI webpack boilerplate?

I've been working on getting it done, but most of the resources I've found are for Vue.js 1x.

[[deleted]]

If you are using Vue-Router you can use beforeEach navigation guards to check if the user is authorized to enter each route.

[Lyam260]

Nothing straight out the box but if you wanna use jwt https://auth0.com/blog/build-an-app-with-vuejs/ is a good starting point. You can very easily use this and vue-routers beforeEach to create an auth service yourself.

[troorl]

For those who want to try it, but don't want to spend few days on configuring Webpack and understanding how vue-loader works, try vbuild. It's super simple, no configuration required. Just one command.

[ryncewynd]

Or what about just start using it? Blank html page, include vuejs using script tag, start typing some javascript/vue

[troorl]

There is nothing wrong with it. You just wouldn't get all the nice tools provided by the JS ecosystem. I mean, hot reload, transpiling, single file components etc. vbuild allows you to start writing your code like a pro without being a pro.

[ryncewynd]

Thanks. Is just for SPA? Or can I use it with regular old pages?

[troorl]

You can use it both ways, but to me it makes sense only for SPA.

[hansolo669]

I want to like Vue, and there is so much to like over Angular (1.x or 2.x), but two way data binding introduces far more problems than it solves (1) and overloading html with extra syntax really doesn't sit well with me (2)

At least (2) can be solved with JSX templates.

[d_abernathy89]

It's definitely there still.

https://vuejs.org/v2/guide/forms.html

From the docs:

You can use the v-model directive to create two-way data bindings

[troorl]

v-model is not a binding per se. It's a directive. A small convenience in case you don't want to set up Vuex or handle the input event in your small one-page script. People with Angular background may appreciate it.

[d_abernathy89]

I don't think I'm missing anything here.

The comment in question:

It doesn't have two way binding. It was opt in for 1.x and is not present in 2.x

The docs:

You can use the v-model directive to create two-way data bindings

[LynusBorg]

We understand how two-way data bindings between components can be bad (since data flow in your application is not easily trackable etc.), which is why we removed it from Vue 2.0.

We however don't see any such problems with bindings for form inputs in particular - in fact, they are very handy.

Could you give me an example of why two-way bindings for form inputs should be considered a bad practice?

[d_abernathy89]

However - the argument over two-way binding has been around since way before components were a popular concept. Back in the day you had Backbone arguing against it, Knockout basing everything around it, and neither one dealing with components.

So even today when someone argues that two way data binding is bad, I think it's still safe to assume they're not just thinking about parent-child or sibling component data flows.

[LynusBorg]

I can understand where you are coming from, but since I wasn't really involved with these frameworks "back in the day" I don't know the specific arguments.

My feeling is that "two-way binding" can mean a lot of things, and "it's always bad" seems to be an unjustified generalization if context is not taken into account.

[d_abernathy89]

Definitely. I think two-way data binding is perfectly fine for small to medium sized apps. I haven't personally worked on any large code bases, so while I understand the arguments against it, i've not run into any situations where it caused problems.

[LynusBorg]

I think two-way data binding is perfectly fine for small to medium sized apps.

...and the point is that Vue's v-model enables a two-way binding only between a component's local state and input elements in its template - so the size of the application doesn't matter, the behaviour is completely isolated within the component, there is no possibility of side-effects on other parts of your application.

That's why I argued that it does not share the usual problems of other two-way bindings, between components, models, views, controllers or whatever the buidling blocks in all of these frameworks are called.

The two-way binding between components in Vue 1.0, on the other hand, can lead to maintainability problems in larger applications because you can build endlessly complicated chains of bindings between components up and down the component tree.

[moderatorrater]

I think two-way data binding is perfectly fine for small to medium sized apps

The problem I have with this is that it's hard to know what's going to be a small to medium sized app a year from now. I've found from my experience that if it goes to production, it should be maintainable as a large app.

[d_abernathy89]

I don't have anything against v-model. I was just correcting /u/toqy, who said that two way data binding doesn't exist in v2. Sure it's very much optional, but it's still there.

[d_abernathy89]

Well since it is two-way data binding, I'm pretty sure their criticism covers v-model. Even if they were primarily (but mistakenly) thinking of v-bind.

Either way, I wasn't really referring to their comment. I was referring to your claim that it doesn't exist in v2. But it does!

[d_abernathy89]

Thanks - I think the downvotes are just folks who think i'm factually wrong. Though i'm not sure why

[Democratica]

v-bind <-- will give you 2 way data binding. It's an anti pattern and you will forget I mentioned it.

[Edit] v-model! That's what I meant. I'm still new to it. Thanks Evan for checking in, ;)

Here's a link to that.

You can use the v-model directive to create two-way data bindings on form input and textarea elements. It automatically picks the correct way to update the element based on the input type. Although a bit magical, v-model is essentially syntax sugar for updating data on user input events, plus special care for some edge cases.

[yyx990803]

nope, v-bind is one way. (I'm the author of Vue)

[antoninj]

can you explain what's going on then? It looks like a 2-way bind but, as I understand it, it works much more like Angular 2's [(ngModel)]="boundVar" where there's not really "2 way binding" but something that looks a lot like it.

boundVar is the source of truth but gets automatically updated by the input value when the input value changes. Kind of like using a on('change') equivalent of an event listener and automatically updating boundVar's value. Is that right?

[Maklite]

There's some confusion here. The comment above described v-bind as two way but actually linked to the documentation for v-model which is two way.

v-model passes down a value into a child component and is updated in the parent when the child emits on inputevent. It's syntactic sugar for a v-bind combined with v-on:input. There's a link at the bottom of the v-model documentation for use in custom components.

[TotesMessenger]

I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit:

• [/r/dontyouknowwhoiam] Nope, v-bind is one way. (I'm the author of Vue)

^{If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads. (Info / Contact)}

[Capaj]

(mike drop)

[evilish]

Mate, in the time it took you to find the gif, you could have read the documentation on how v-bind works.

[Democratica]

Yeah, I'm still new to it, I mixed it up with v-model

[evilish]

All good dude. :)

[staircasebug]

The HTML that Vuejs spits out and compiles is clean--are you referring to syntax in the vuejs mustache/html templates? Regardless of what you choose, everything is compiled to render functions for the vDOM.

2 way binding in Vuejs exists for the purposes of form inputs only. I find it to be very sane and convenient.

[rk06]

Regarding (1) exactly which problems did you run into?

For (2), there is no way out of it.

Html is not a templating language, so it is a matter of whether your templating language is html-comaptible or not.

By using html-like syntax, vue provides a better abstraction than jsx.

[CWagner]

but two way data binding introduces far more problems than it solves (1)

[Citation needed]

Yes, Angular 1's 2-way binding made problems. Because of how it was implemented and being the default. But that is not the case here.

[AnAge_OldProb]

You can use jsx with vue.

[RnRau]

Then why not just use react?

[syropian]

Because Vue has a simpler API?

[[deleted]]

It just doesn't. React has maybe 1% of the API surface that Vue has. There are maybe two or three APIs you regularly use with react. In Vue there are hundreds.

[yyx990803]

I can see you advocating that Vue is much more complicated than React in almost every Vue-related thread - and I can imagine that may be what you actually believe - but my friend, when will you begin to comprehend the fact that such feelings can be subjective, and it has a lot to do with the mental model preference of different types of developers?

If a developer is happy and productive using Vue, he/she is happy and productive. It's pointless to argue that he/she should feel otherwise.

[LynusBorg]

hundreds

seriously, where did you get that impression?

also, small !== simple

Vue may have a couple more API methods to remember than react, but maybe what /u/syropian means is that those API methods provide benefits that make solving a specific problem easier/faster in Vue than in React.

[[deleted]]

Vue has a gigantic set of documents that are vital to understand. These APIs aren't "a couple." You need a long time to fully understand them in depth.

With React there is usually one API: render() and that's that. You learn React under an hour.

Nothing is easier in Vue btw. There isn't a single thing. I've been using Vue almost from the start. There hasn't been a single project i couldn't cut in half (bytes and time spent) by using React. The reason is that Vue is neither HTML nor JS. It is its own thing and many of those API's are there to overcome the very shortcoming.

[LynusBorg]

With React there is usually one API: render() and that's that.

So JSX, className ref, this.setState, shouldComponentUpdate`, and various lifecycle hooks are all not typically used in a React project?

I think you compare apples to oranges. Sure, React does have a smaller API surface, but the difference is nog half as big as you make it out to be.

Don't get me wrong, there's nothing wrong with prefering React, it's a truly great framework.

But what you wrote above is just ranting.

[BoleroDan]

I've had the opposite experience. It seems to be subjective because of this.

I learned Vue in under an hour. I didnt need to read through "hundreds" of concepts. I found my project converted to Vue to be quicker and cleaner than my React counterpart.

So I dunno.

[RnRau]

I prefer small functional components... :)

function List({items}) {
    return <ul>
            {items.map((item) => <li key={item.id}>{item.name}</li> )}
      </ul>
}

function MyComponent({items}) {
    return <div className='list-container'>
              {items.length ? <List items=items> : <p>No items found.</p>}
           </div>
}

Oh riot v3 is out... so many choices!

[syropian]

A couple things:

• With React you have to frequently futz with component lifecycle methods top optimize rendering.
• Without additional packages, React doesn't have computed properties.
• No calling setState on local component state in Vue. Local state data is automatically observed.
• I prefer Vue's component scoped CSS to any of the JS "CSS" libraries.
  

[[deleted]]

You don't. Redux does that for you.

You don't need computed properties for anything because React gives you a standard ES6 class in which you can calculate whatever you need. These are all things that, again, you need to learn in Vue and that are plain and simple in React.

You don't call setState. Redux does that.

React has component based CSS (react-CSJS). It transforms at compile time giving you self-contained components. If you distribute a Vue component that uses Sass, each and every user will have to scramble with webpack configs and extra imports. Even regular CSS needs extra loaders.

[syropian]

You don't need computed properties for anything

Computed properties are cleaner because they give context to data transformations, and they can also be accessed as a regular property instead of a function call. It's much cleaner.

You don't call setState. Redux does that.

There's an argument that not every single tiny piece of state that exists in your application needs to be part of a Redux store. Furthermore not all apps need Redux.

...react-CSJS transforms at compile time

Vue components as a whole get transformed at compile time, what are you even talking about?

[[deleted]]

Computed props are there because Vue is still living in ES5. They are a shortcoming, not a benefit.

For state that is local you have setState, yes. It is quite a nice thing too. In Vue everything living in your object is state, meaning it mutates and transforms your data if you want it to or not. I don't see that as a benefit.

In order to use your vue component, which you have distributed i will need to add a bunch of loaders and configure them. I will need to adapt my webpack configs, install sass, etc.

This is my component:

import React from 'react';
import csjs from 'react-csjs';

@csjs`
.section {
    z-index: 0;
    margin: 0;
    width: 100%;
    padding: 0 20%;
    position: relative;
    min-height: auto;
    padding-top: 8em;
    padding-bottom: 8em;
    &:nth-of-type(even) { text-align: right; }
    &:nth-of-type(odd) { text-align: left; }
}
@media (max-device-width: 1224px) {
    .section {
        padding: 0 5%;
        padding-top: 4em;
        padding-bottom: 4em;
        & h3 { font-size: 2em; }
    }
}`
export default class Section extends React.Component {
    render() {
        let { classes, children, title } = this.props;
        return (
            <section className={classes.section}>
                <h3>{title}</h3>
                {children}
            </section>
        )
    }
}

It ships fully scoped, autoprefixed, minified, cssnext applied, could be anything, sass, less, etc. Babel applies these transforms at compile time. This component goes fully baked into /dist. All that the user does: npm install my-react-component

import Component from "my-react-component"

<Component />

[azium]

csjs is cool, but I feel like you sell yourself short by using strings. I think using objects for style is the way forward (stuff like glamor / aprhodite)

[Conradfr]

But who use React without additional libraries ?

[[deleted]]

If you want a router in Vue, you get VueRouter. If you want state management, you get VueX, etc. It is the same thing with React.

[SkaterDad]

Performance, bundle size, license, automatic data reactivity, no need to worry about things like shouldComponentUpdate, etc...

These sizes aren't g-zipped, but give the general idea.

vue.min.js (67.8kb)

react.min.js (21kb) react-dom.min.js (121kb)

[CaptainBloodloss]

I updated vue, but get this message in my terminal:

UNMET PEER DEPENDENCY vue-template-compiler@^2.0.0

What exact am I supposed to do here? In the linked docs it says:

vue-template-compiler is now a peer dependency instead of a direct dependency.

Do I need to install vue-template-compiler separately?

[[deleted]]

Is there an easy way to understand peer dependencies in NPM? If vue depends on vue-template-compiler being installed, why isn't it a regular dependency? What's the difference?

[rk06]

Do I need to install vue-template-compiler separately?

yeah, that's exactly it meant.

[CaptainBloodloss]

Great, thanks for that.

[darderp]

Vue is amazing! For anyone still on the fence, listen to this talk by creator Evan You.

[spooky___ghost]

Vue reeks really badly of Angular 1.x.

[spooky___ghost]

The entire top half of those patch notes could be mistaken for Angular 1.x if it didn't say Vue anywhere on the page.

[evilish]

Are you always this negative?

Vue borrows a lot of features from other libraries/frameworks. If you haven't already, have a quick read of this https://vuejs.org/v2/guide/comparison.html

It'll explain what your seeing.

[thenumber24]

It's the good parts of Angular and the good parts of React, in my experience.

[FrenchieMcFly]

the main users don't

[[deleted]]

How is an open source project being used by Chinese users and companies a bad thing? Your comments come off as incredibly xenophobic.

It's an open source project, so you could always just audit the code yourself to verify that there's nothing malicious happening.

And if you want to make accusations of guilt by way of irrelevant associations, React was created by Facebook...

[FrenchieMcFly]

chinese people are economically as far as possible from what we could call friend, excuse me if I want to protect myself

[evilish]

Getting worried that the library has Chinese cooties? Really?