I don’t get Vue. What does it bring to the table over React?
From my POV, .vue single page components.
I’d love to be educated though!
That’s a tricky one.
Vue is simpler, Vue is a complete framework. React has React Native which is plain awesome, no other alternatives come close in my opinion.
I dislike React for being “just a library” so that I have to build and maintain my own framework (where each part has too many options at times with no clear winners), but after gathering the whole thing it gets sane enough and porting features to React Native is a matter of rebuilding UI parts (Redux, Sagas, API Services and all their tests will just work).
I know it’s 2017 and no one builds native apps any more, but we still have to, so we use React. For the projects that are not purely SPA I mostly go for Vue unless I can skip a JS framework altogether 
4 Likes
It’s the difference between Learn this pile of stuff including the difference between props and state and whatever; also JSX because it’s cool; Some of this will get deprecated in the next version, but so cool, it’s used at facebook - React and Look, you have HTML templates, you map javascript data to the templates and it’s magic and it works - Vuejs. Of course, you can go deeper with Vuejs, but the point is, you download one of the official webpack templates and after 5mins you have a functional app with clean code.
I’m sure React must have enormous advantages over Vuejs (just like PHP - facebook uses it! Gotta check that out), but for my things Vuejs works fine.
3 Likes
Yeh, I suppose I distrust Vue’s data binding etc. A step backwards.
I much prefer to functional one-way-data flow way of doing things - and not being tempted to do anything else - although it can be tricky.
Whatever floats your boat.
Personally, I feel W3C standard web components are underrated…
2-way databinding is just syntactic sugar for event capture. It’s not that bad. And you can easily customize the mutation graph if you want. Apparently databinding becomes even more explicit with Vuex, which AFAIK makes it impossible to use 2-way databinding.
But this is all extremely subjective, so different people will have different opinions.
1 Like
Well if Vuex is like Redux, there really is no data binding.
It’s a pity to throw away the lessons learnt from Elixir.
Sure, Ui isn’t parallel but it is most definitely concurrent - when things get complex best to keep to a functional mindset - no mutation & stay pure as possible…
But yeh, perhaps overkill if your project isn’t in danger of getting complicated : )
Vue’s data binding is just done how Polymer does it, which is done how the WebComponent examples in the spec does it. When data flows ‘into’ a component it is set via a property or attribute depending. When it flows back ‘out’ of a component the component is sending an Event up the chain to be handled. It is the modern style of handling it that allows composition of any styles and libraries.
yeh, I assume Polymer is not web components : ) which, right now, might be a strong assumption ; )
Vue’s data-binding system made the most sense to me when I viewed it as a pseudo getter-setter mechanism. Here are a few notes that I made when working through Max Schwarzmuller’s Vue course (which is really fantastic, btw):
*Vue does “proxying” of properties, computed properties and methods.
*Vue then sets up watchers for them.
*We can access them from outside of the instance by directly accessing them on whatever we stored the instance.
*We cannot add new proxied properties (since they are created via the constructor), or we can but they won’t work as normal properties that we pass into the data property or as methods when we created the Vue instance.
In theory you are not creating this Vue instance - you are calling it via the constructor, but this appears to be a core object shipped with the Vue framework. Behind the scenes, when creating an instance, Vue takes the object you pass and takes your data properties or methods and use them as native properties on the Vue instance object itself, so it will copy them.
It sets up a kind of watcher for each of those properties, which makes sure it recognizes whenever one of those properties is changed, so it knows when to update the DOM, or when to do anything.
Very different from React, but still pretty slick!
Actually Polymer requires web components, that is why it does not work in almost any browser without the webcomponents.js (or -lite) polyfill. It was designed to be a library built on and for webcomponents. 
What it does is just give a unified interface for 2-way data-binding (or you can handle the messages directly if you wish, either is useful) while using webcomponent <template>'s to define the template that is drawn while using custom elements to bind that template to code to render, while also using the shadow-DOM to encapsulate parts and keep CSS confined to just the elements it is supposed to.
As an example, this is entirely valid HTML with Polymer loaded and it ‘just works’ and works fast:
<!-- This renders the elements directly, as in it is dom-'binding' the template at this location -->
<template is="dom-bind">
<input value="{{blah}}">
You typed: [[blah]]
</template>
<!-- This is how you make a new custom element that uses a property: -->
<dom-module id="my-custom-bold">
<template>
<span>[[text]]</span>
</template>
<script>
HTMLImports.whenReady(function() {
class MyCustomBoldElement extends Polymer.Element {
static get is() { return 'my-custom-bold'; }
static get properties() {
text: String
}
}
window.customElements.define(MyCustomBoldElement.is, MyCustomBoldElement);
});
</script>
</dom-module>
<!-- That one is used like: -->
<my-custom-bold text="Blah">
<!-- Now make one that uses webcomponent DOM slots as an example, with in-element-only CSS: -->
<dom-module id="my-header">
<template>
<style>
/* These style will only apply to this element, they will not 'leak' out, not even to children nodes defined outside */
h1 {..}
h3 {..}
header {..}
tabbar {..}
</style>
<header>
<h1><slot name="title"></slot></h1>
<h3><slot name="subtitle"></slot></h3>
<tabbar><slot></slot></tabbar>
</header>
</template>
<script>
HTMLImports.whenReady(function() {
class MyHeaderElement extends Polymer.Element {
static get is() { return 'my-header'; }
}
window.customElements.define(MyHeaderElement.is, MyHeaderElement);
});
</script>
</dom-module>
<!-- Used like: %>
<my-header>
<span slot="title">My Website</span>
<span slot="subtitle">Where we learn stuff</span>
<a href="blah">Link 1</a>
<a href="bloop">Link 2</a>
<a href="blorp">Link 3</a>
</my-header>
Polymer 2.0 just released as well, it adds support for the most up to date webcomponent V1 spec-in-dev. But as you can see it follows the spec while working ‘today’. On browsers that implement a large chunk of the spec (like Chrome) it works blazing fast and safe and ‘as expected’. On other browsers, like oh IE11 it uses emulation but it is still fast, just not ‘as fast’, but on newer browsers you get a free speed boost and it will all just transparently work with any other library that uses webcomponents as well (and even without, you can take any element made in, say, Polymer, and use it in Vue.js for example, or vice-versa since webcomponent elements are fully self-contained).
Yep, that is what the webcomponent spec has done via Observers and such as well.
Yep, it is very webcomponent’ish, is how Polymer works as well, just without webcomponents (Vue.js works down to, what, IE8 or some craziness like that ^.^ where the webcomponent polyfill only works down to IE10 I think).
1 Like
I meant Polymer isn’t synonymous with web components - but true, you can sneak observers in there and all sorts of nasty JS stuff that should probably be left alone : )
What I really like about Web Components, is they give the promise of moving away from framework specific component implementations - which’ll be nice.
You can take JS out of the random-OO-style-framework but you can’t take OO-crappiness out of JS… ; )
1 Like
Ehhh, Bucklescript and Elm…
I wouldn’t consider Vue a complete framework. It’s a view model, much like React, meaning it manages data binding to your HTML, but not much more than that. There’s no concept of controllers, services or models and even the vue-router is totally optional.
I can add a bit to that.
I’ve now used this combo (Phoenix, GraphQL, and Nuxt) on three different occasions, with Edgewise (https://edgewiserealty.com) being the most recent.
In this setup, Phoenix is mostly headless. It handles the GraphQL endpoint, as well as a socket endpoint. My router.ex is pretty bare bones Additionally, it has its own GitHub repo, and deployed to its own servers, etc… Currently working on adding Apollo Engine into the mix as well.
Nuxt is essentially an opinionated layer on top of Vue, that handles server-side rendering; as well as other Webpack boilerplate. It runs in Nodejs on the server, renders the Vue app, then passes the static html to the browser. This is great for SEO (among many other reasons). Once Nuxt loads in the browser, it “hydrates” the static HTML. From there, the app functions like an SPA, using pushstate for routing. Upon a page refresh, the process starts all over again.
Nuxt is running on its own server, also using Docker containers, with its own GitHub repo. As is another app (“service” is if you prefer) that handles file caching and image processing. Again, with its own repo.
For me personally, I prefer the separation of concerns here. I personally feel Vue is a much better “templating” language to work in than eex, and it’s a no-brainer when you start introducing functionality that requires JS. The whole “some of my HTML is eex and some of it is in Vue/React/Angular” is just silly IMO.
I also prefer Vue over React and Angular, for what it’s worth. I personally can’t stand JSX. Vue’s single file components are great. As are directives, as are scopes. It’s more inline with web standards in that regard. It’s also very “progressive” in that you can sprinkle it around on small apps (almost to the point where you can use it the way many use jQuery). You can run it side-by-side older apps (the first time I used Vue, it was intermixed with Backbone.js), and of-course, it can scale to a full-blown state management (Vuex) SPA.
8 Likes
Free course on Vue.js 
1 Like
No but I’ve messed with that style in the past, it creates a whole LOT of thunks, sure executing them is fast enough but creating them is horrible on memory, lifetimes, and creating the representation itself. Notice how their benchmarks don’t measure that, they only measure the time it takes to ‘apply’ it (like I love that they actually distinguish it with phrases like The memoized DOM creates practically no garbage during an iteration, yeah the garbage is during creation and the huge amount of thunks… for note my vdom creates no garbage at application time either, only when creating the vdom itself and much of the garbage can be removed by just designing it well). If you had a pre-compiler (or a macro system ala elixir, this is actually already something similar to what Drab does) then you could pre-bake all possible states to fix ‘most’ of those costs, but at that point you may as well just use the observeable pattern.
1 Like
