
Vue.js: the good, the meh, and the ugly - prostoalex
https://medium.com/@Pier/vue-js-the-good-the-meh-and-the-ugly-82800bbe6684
======
ilovecaching
I really like a lot of things about Vue. I was apprehensive about using JSX
when I first started using React, and I also did not like setState. I think
the real issue, though, was that I wasn't thinking functionally. I now rarely
write a stateful component, and when I do, it's usually once, for the entire
application, or maybe for a few large subtrees if the app is very large. State
kept alive by parameters is extremely powerful and elegant (just read about
gen_server in Erlang or the State monad). I am never a fan of two way data
binding as an alternative. It's extremely hard to reason about, and it's not
nearly as composable or simple as a tree of functional transformations. So I
think that, if you compare Vue to React Component classes, Vue can be quite
nice, but the reality is that idiomatic React should have you writing 80%+
small, simple, composable functions with no state, and you really can't get
any syntactically barer then that. It's also the way I teach React. When you
first see a function going from state to jsx, it really just makes so much
sense, and you ask yourself why you'd ever bother with anything else.

~~~
stupidcar
If plain, idiomatic React so great, why does every semi-complex React app end
up bringing in a separate state management framework like Redux or MobX?

The reason is that while you may be able to break up your _HTML_ into a
composable hierarchy of purely-functional components, the actual data and
state you need to distribute to them has a structure that is _completely
unrelated_ to how its laid out in the DOM. In a complex web app, a component
nested twenty levels deep may need to display pieces of information, like the
user's date of birth and the current temperature on Mars, that none of its
parent controls cares about.

At that point, you can either bite the bullet and pass state through layer
upon layer of props, completely eliminating any semblance of separation of
concerns in your component layering, or inject state into your components via
some other mechanism, like Redux/MobX/Context. At which point, JSX is
basically just another fancy HTML templating library.

"Idiomatic" React is a fun game to play when doing basic examples, using
something like a todo manager, but as soon as you're in the real world, you
hit its limitations very quickly.

~~~
allover
> If plain, idiomatic React so great, why does every semi-complex React app
> end up bringing in a separate state management framework like Redux or MobX?

Sadly it seems that's mainly been cargo-culted. It's not the case that
React+Redux is the equivalent to say Angular, but by some unfortunate accident
due to Facebook's announcement of Flux, and then the hype around Redux as a
'better Flux', people started assuming React+Redux is what is needed to build
a React app.

Meanwhile Dan Abramov, Redux creator says [1]:

> Flux/Redux is meant for big apps with complex nested UIs that have many
> independent parts but share common caches of data.

That's not "every semi-complex React app". In most "semi-complex React apps",
most state can be derived from the route (e.g. react-router) or is relatively
local. Redux is not required.

[1]
[https://twitter.com/dan_abramov/status/732719257579065345](https://twitter.com/dan_abramov/status/732719257579065345)

~~~
atombender
There's unfortunately a thin line between cargo-culting and attempting to
follow the mainstream.

As developers we can't all be building tools. We choose tools that others
build for us, so that we can get our job done. Soemtimes I'm interested in
going "one layer down" and build tools, but it's almost always a distraction;
we want off-the-shelf products like React and Redux. We need to pick stable
tools that promise some sort of longevity. We also need to pick tools where
best practices and idioms have been established.

To do this we have to trust someone else's opinion _and_ try to gauge which
solutions have the best prospects. This means not just evaluating software
based on its own technological merits, but also listening to what "the
community"/"the industry" seems to be rallying around; you don't want to be
stuck using a library that nobody is maintaining, just as you don't want to be
stuck using something that's just badly designed.

When we started using React, there was no state management framework
available, and everything was handled somewhat ad-hoc. Then Facebook described
Flux, and we realized they were onto something, so we started using their
patterns, with some simplifications where theirs seemed overly complicated.
Then Redux came along and seemed like a better way to do things.

At each point there was uncertainty about what best practices and "idiomatic"
solutions would turn out to be, because the technology was immature. I don't
think anyone was cargo-culting. It was just that a lot of people were busy
trying to _create_ things, and when there isn't clear guidance, and the
alternative is going back to Backbone or jQuery or something, then you just
forge ahead, trying to do fit the pieces together.

~~~
allover
But if you looked at the official React docs the answer was always 'setState'
and embracing components, that was the whole promise of React to begin with.
Not once did the React team/docs ever say you needed Flux to build a React
app. All of those answers you got were cargo-culted from the community.

Can you really look at where the community is, the perception that still
exists that React+Redux is necessary, projects like redux-form (that now admit
Redux was a poor fit for forms) and honestly say no cargo-culting happened?

Sympathy for 'attempting to follow the mainstream' though, I understand that.
Personally I stuck with Backbone for years longer than most, avoiding the
Angular/Ember wars, and the early days of React+Flux til the React ecosystem
had matured a little, before jumping over to React at which point it was
clearer that Flux/Redux were being misused.

~~~
atombender
Can we blame all the bloggers who take upon themselves to explain what the
best practices is? Absolutely. There are also projects (like React Forms and
React Router) that clearly led down a path of confusion. But it's hard to
blame the developers who read those blogs and try to figure out what they
should be doing.

I never got the impression, even from the start, that setState() was a good
solution, by the way. But it's not like the React authors were completely sure
of where the right design was, either. Flux, for example, as it was originally
described, appears completely overdesigned at this point. The good design is
to be found in Relay and GraphQL.

~~~
allover
> Can we blame all the bloggers who take upon themselves to explain what the
> best practices is?

It's not really about blaming bloggers.

It's really on software team leads and senior engineers to not just follow
blog posts blindly. They should be pushing back on bad advice like redux-all-
the-things, because to a senior software engineer the tradeoffs of something
like Redux should be fairly obvious.

> The good design is to be found in Relay and GraphQL.

Nah again, good example to question what you read/hear.

GraphQL is great from a front-end point of view but complex to implement in
the backend, so it really depends on your use-case whether that backend
complexity is worthwhile.

------
octref
Have to do some clarification here on the point of "Unclear architectural
patterns", as the article is way too misleading.

\- The reason the API call is made at `created` lifecycle is that the video is
a quick, 5 minute intro for __beginners __. Beginners, as in "people who are
familiar building static websites using html/css/js". There is no need to
bring in Vuex or vue-router yet. In fact the whole beginner example can be put
into a single HTML file by including a Vue script tag. The approachability is
what made Vue shine. Some other frameworks assume that you want a build tool,
state management, client side routing etc and beginners spend hours
configuring those tools and figuring out state management and client-side
routing, instead of doing real work.

> To answer to my initial question: API logic should not be written in Vuex
> nor in components. There is even a good example on how do that in some of
> the official code examples.

\- The example[0] clearly has the API logic in the Actions. The `/api` folder
is a mocked API for illustration purpose.

[0]: [https://github.com/vuejs/vuex/blob/dev/examples/shopping-
car...](https://github.com/vuejs/vuex/blob/dev/examples/shopping-cart)

~~~
voltagex_
>Some other frameworks assume that you want a build tool, state management,
client side routing etc and beginners spend hours configuring those tools and
figuring out state management and client-side routing, instead of doing real
work.

Okay, say I do the tutorial and build a simple page - how hard is it to
retrofit routing or whatever to it? A lot of the time with new frameworks, if
I get past the initial setup hurdle, I can't work out how to easily move away
from toy apps to something I can use in production.

~~~
octref
One thing I want to say is: Don't assume only developers make websites. Don't
assume everyone wants to ship a heavy and complex SPA.

Example 1: A great typographer, Wenting Zhang, author of Type Detail[0],
contributing to Source Han Serif, learning Vue to do some interactive widget
for variable fonts[1].

Example 2: Brian Terlson on TC39. He's using Vue without Vuex or Vue-router to
build an app to track TC39 discussions[2].

I hope we can admit that many people might not need store and router[3]. Store
and Router are necessary for building complex SPA, but don't make them
necessary, as many don't want complex SPA. They impose learning efforts in
exchange of better architecture, but the imposed effort might not be worth it
for many people who just want some data-rendering, some reactivity and some
interactivity on their websites.

[0]: [http://typedetail.com](http://typedetail.com)

[1]:
[https://twitter.com/DesignJokes/status/1015003288528400386](https://twitter.com/DesignJokes/status/1015003288528400386)
and
[https://twitter.com/DesignJokes/status/1014260361535647744](https://twitter.com/DesignJokes/status/1014260361535647744)

[2]:
[https://twitter.com/bterlson/status/913433979239436293](https://twitter.com/bterlson/status/913433979239436293)
and [https://github.com/bterlson/tcq](https://github.com/bterlson/tcq)

[3]: [https://medium.com/@dan_abramov/you-might-not-need-redux-
be4...](https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367)

~~~
nightski
This will probably be downvoted but I have come to appreciate frameworks which
are opinionated and target a specific use case than very general and trying to
please everyone.

------
ElatedOwl
We adopted Vue 2 years ago and I've been extremely happy with it. It's very
easy to get into, the learning curve is not steep at all, and for the most
part it just works.

TypeScript support is mediocre. It's supported (Vue will let you use anything)
but it's clearly a second class citizen.

There's also no real accepted best practices, which the author touches on
(where do API calls go). Third party component design varies pretty wildly. I
think this is just the reality of a young framework casting a wide net, we'll
see what the future brings.

It's not perfect, but like the author, Vue was a great decision for my team.

~~~
ilovecaching
I'm curious to know, what about Vue makes it easier to learn than React? It's
just a function that takes in data and returns a piece of html. React also
just works, and unlike Vue, it's worked for companies like Netflix, Wallmart,
Facebook, Instagram, etc that have exceedingly complex requirements and
require exceedingly fast rendering. What did you really buy with Vue over
React?

~~~
ElatedOwl
Netflix, Walmart, etc. solve a much different set of problems than most shops.
I'm proud to work for a small company with simple (but rapidly changing)
requirements. :)

~~~
ilovecaching
That doesn't answer my question. What about Vue actually made it a better
choice for those requirements? In my experience, the fact that React is a
simple view library makes it the perfect choice for small shops. You're taking
on considerable risk when you use a technology without a vested backer
(Facebook is heavily vested in React, look at Angular 1 for an example of a
framework with a big backer than is not vested, the API was completely broken
in a rewrite). Smaller frameworks also suffer from a lack of sustained
development.

~~~
ipntu
> In my experience, the fact that React is a simple view library makes it the
> perfect choice for small shops.

Vue is also a simple view library.

You keep bringing up Angular, as if Vue has something to do with it. Vue is so
much closer to React than to Angular.

> You're taking on considerable risk when you use a technology without a
> vested backer (Facebook is heavily vested in React, look at Angular 1 for an
> example of a framework with a big backer than is not vested, the API was
> completely broken in a rewrite). Smaller frameworks also suffer from a lack
> of sustained development.

Sorry, but that sounds a lot like rationalization and wishful thinking,
written purely to make React look good and anything else look bad.

Vue also has backers that contribute financially, a large community using it
and sustained development. The fact that it isn't as big as React doesn't make
it unworthy of existing or unable to provide the same technical benefits as
React.

------
KaoruAoiShiho
Pushing so much support to chat is an astonishingly big mistake. Not only are
platforms like stackoverflow vastly better at answering questions and
providing long-term documentation, it also builds broader communities. People
use things like "number of stackoverflow questions tagged vue" to determine
health and activity. You don't want to miss out on those metrics that other
libraries are rolling with.

------
carusooneliner
I can vouch for the author's points on the good parts of vue.js.

We've built our single page application (SPA) web app with vue.js and are very
pleased with the results --
[https://checkoutclip.com](https://checkoutclip.com). We were able overcome
most of the stumbling blocks by looking up
[https://vuejs.org/v2/guide/](https://vuejs.org/v2/guide/),
[https://github.com/vuejs/vue/issues](https://github.com/vuejs/vue/issues) and
[https://forum.vuejs.org](https://forum.vuejs.org).

For server side rendered (SSR) pages, we're using nuxt.js, which is working
out great as well. E.g. SSR page:
[https://video.checkoutclip.com/-LDQ5TtL_yywYCgUNb6K](https://video.checkoutclip.com/-LDQ5TtL_yywYCgUNb6K)

I would recommend vue.js for anyone building their first SPA even if they
don't have prior experience building one...it's easy to pick up.

~~~
mcbits
Five (5) megabytes of JavaScript for a basic brochure site... I assume 99.9%
of that is only necessary _after_ signing up and signing in, not while
unfortunately viewing the page on a less-than-flagship mobile device and
metered data plan?

~~~
carusooneliner
It's going to change and get less hefty, we're looking into code splitting.

~~~
caseymarquis
Vue makes it incredibly easy!

~~~
BJanecke
The new module system makes it easy ;)

------
_bxg1
I've used React full-time at work for a year and a half now, and I did a
personal project in Vue for a while to try it out, before converting it to
React.

There are some things I really, really hate about React. It is not kind or
accommodating (Vue is both of these things), but it gives you control. I was
head-over-heels for the first few days of using Vue; "breath of fresh air" is
exactly the phrase I'd use. But the project I was using it for was an IDE of
sorts, and eventually I just needed more control than it allowed for.

If someone told me they were going to build a basic website - not a web app -
with React instead of Vue, I would laugh at them. Vue truly is a successor to
jQuery for the reactive age. But for really complex applications, it's too
"magical" in my opinion.

~~~
panoply
I choose Mithril.js regardless of the apps complexity nowadays. I've built
apps in React and Vue and do agree that Vue is the logical choice over React
but I don't see it as ground breaking or magical. I see Vue for what it is, A
JavaScript framework that gained popularity by being included by default in
the Laravel framework and now has good financial backing.

Mithril.js is a framework that is truly "magical" in my opinion. I mean its
8kb, includes routing and XHR Utilities out of the box. Faster render times
than Angular, Vue and React. You can write HyperScript or JSX. The syntactic
variants allow you to write your components as ES6 Classes or closures.
Lifecycle methods, a render and mount option and the list goes on and on.
People tend to dismiss Mithril because it's a lesser known framework but it
has a vigorously thought through programmatic approach and you've got a direct
line with the maintainers, you cannot match that.

Sure, each to their own but calling Vue "Magical" is an incorrect assessment.

~~~
aidenn0
I also use Mithril, and in my opinion, it's less "magical" than React in the
sense that the GP is using[1].

When I ran into an issue using React, tracking it down was extremely difficult
(by the end it was just "difficult" due to improved tooling around react).
Mithril is small largely because of its simple implementation, which makes
debugging a joy.

1: They seem to mean magical in the sense if "I'm never going to understand
how it works"

------
condescendence
>You’ll be adding similar boilerplate for computed properties, component
state, watchers, etc. Pretty much everything in Vue has its own special syntax
with more boilerplate.

I kinda like this syntax, when I first learned vuejs I knew immediately that
some magic was going on in the background. If I saw marko's syntax I'd be
wondering how this shit is getting done. It also makes it easier when
searching for issues or suggestions. "vuejs computed property" vs searching
generic terms.

>Chat based community

This part is simply not true, there's tons of individual vuejs communities all
pretty decent. Shoot me for saying this but laracast isn't a bad option for
Vue help. Everytime I have an obscure problem I find a solution on there.

>The reactivity system will only track changes under certain conditions. Don’t
expect to throw anything you wish at it

This is the one part I hate about vue.

>Does this mean authentication logic goes in Vuex too? Will a state manager
start mediating all application logic now?

Been there done that. I typically use vuejs for lightweight applications
solely because I do run into this issue.

~~~
davidmurdoch
I hadn't heard of laracast until starting Vue development a few weeks ago.

The quality of answers were so low I found myself longing for the days of
expertsexchange.com.

Why did laracast get so popular for Vue? What was wrong with Stack Overflow?

~~~
flaviocopes
AFAIK Vue got a big popularity boost when Laravel's lead dev posted
[https://twitter.com/taylorotwell/status/590281695581982720](https://twitter.com/taylorotwell/status/590281695581982720)

Then the Laravel ecosystem adopted it widely, and a good Vue.js tutorial
series was published on Laracasts (which also happens to host the official
Laravel forum)

Hence the close link with Vue and the Laravel community.

------
sireat
I like that Vue is easy to add to an existing site (ie the new jQuery).

I dislike that Vue feels too much like Vue and its magic and not enough
Javascript. With React I feel like writing normal ES6 Javascript.

I love the official Vue documentation and examples.

I am a bit cautious about the ecosystem surrounding Vue. About a year ago when
I looked at various interesting projects/tools extending Vue it seemed most of
them were in China with very limited English documentation.

Finally the job situation for front-end work. In my region it seems to be
about 75% React/20% Angular/5% various(Vue rarely mentioned)

------
ixtli
One of the gems in this that i think might be getting overlooked:

> This trend of using chats for questions is plaguing open source projects and
> I think it needs to end. There is no collective learning anymore.

This is a very important notion not least of all from an archival pov.

~~~
tnolet
Yes! Also things like Gitter and Slack are really messy for storing knowledge.
Questions get lost, answers are interspersed with more questions. Maybe I'm
getting old, but give me a forum based, one-thread per topic any time of the
day.

~~~
anderspitman
I prefer forums as well, at least for technical questions/discussions. It
seems to me the biggest advantage of chat apps over forums is that you can use
a single account to join many rooms. Are there any forum platforms designed
around that idea?

~~~
dave7
> Are there any forum platforms designed around that idea?

That's basically Reddit

------
dstick
This is going to be a drop in the ocean but Vue is the bomb! It made perfect
sense, and that's a big compliment for a framework.

For me personally it took the MVC into SPA territory, got rid of all the muck
that's jQuery and replaced it with a fun, easy to design UIs with platform.

If you ask me it's biggest achievement is that it put design, experience and
interaction on the same level, literally - thanks to .Vue files :)
Consolidating them just made sense.

~~~
marcstreeter
+1 for .Vue files. I really like the organization around components and not
around file types(.css, .js, .html) within a project's file structure. For me
it's an immense time saver knowing exactly which css and javascript was
intended for a particular component (using scoped scss for example - which for
me is still a pain in the React I use at work).

------
Tade0
>To answer to my initial question: API logic should not be written in Vuex nor
in components. There is even a good example on how do that in some of the
official code examples.

Ok, but where's an example that shows how this backfires? _Why_ should the API
logic _not_ be written in Vuex?

One more thing I think deserves mention: Vuetify - Vue's material design
component set. It's being used in the project I'm currently in and I worked
with Angular's material design component set and I have to say the former is
_way_ better built.

~~~
pier25
> Ok, but where's an example that shows how this backfires? Why should the API
> logic not be written in Vuex?

(Author here. I didn't really expand on that because the article was getting
pretty long already.)

For example, think about authentication logic.

It involves more than just calling the API. Eg: extracting the JWT, saving it
to localStorage, decoding it, maybe checking user roles, etc.

If you do that kind of logic on Vuex actions then these will start being
responsible for a lot of your application. If you are fine with that, by all
means, use Vuex actions to do (a lot of) stuff not really related to managing
state.

Personally I don't think it makes any sense to delegate that kind of logic to
Vuex in the same way I won't use Axios for anything other than making HTTP
requests.

There are also practical aspects. Vuex actions need to have a very particular
signature, since you never really call them yourself. To me that was the final
reason for moving a lot of logic to their own modules.

In my latest projects I've almost stopped using Vuex actions altogether and it
feels really good. Authentication is not managed by some parts of Vuex, but by
my own auth module.

~~~
philliphaydon
I use vuex with namespaced modules, but then those modules just call out to
abstracted implementations if it's more than just http request. So for example
with auth, I have a vuex auth module.

It then has some getters which just get the state from the store, but the
actions call to a separate module which manages storing it in LocalStorage or
making the http requests.

Works for me, but I just took what I learned (Vue) moved it to when I learned
a year later (Vuex), when things became complicated in Vuex I just moved the
complicated bits back 1 bit more and everything became simple again (which
seemed like the logical thing to do).

------
dsco
A lot of the boiler plate can actually be removed if you combine Vue with
TypeScript decorators. Here's a library which will do that for you:
[https://github.com/vuejs/vue-class-component](https://github.com/vuejs/vue-
class-component)

Although at this point in time it is pretty cumbersome to get the entire Vue
stack type safe. I think it's getting better but it's far from ideal. You'll
need a wide range of libraries to get everything set up. For instance here's
the list of libraries I use for bootstrapping projects:

Vue-class-component - Vue-loader - Vue-property-decorator - Vue-template-
compiler - Vuex - Vuex-class - Vue-router - Vuex-router-sync.

The ecosystem just keeps getting larger and larger and for a beginner it can
seem pretty daunting. I don't complain though - UI's have become a lot more
technical and complex the last 10 years - and of course that'll increase the
learning curve of learning how to program them.

~~~
sharpercoder
I would highly recommend against this setup. While Vue is already very
challenging to get right with any build tool, it's especially terrible
regarding typescript and much more so with typescript decorators. You need to
enable hardly documented configuration switches in multiple dependencies.
Then, you must wrestle through a plethora of error messages coming from a
diverse set of build tools/libraries/scripts. After you've done that, the only
options is praying to the gods a config will work.

I have worked with multiple Vue projects now. The time is spent about 50/50 in
pure development and getting the build setup working correctly.

Better pick another tool to do the job which has mature integration with build
tools.

~~~
breakingcups
Just to provide a different point of view. We're using Vue + Typescript +
ASP.NET Core in about 4 mid-sized projects now and it's working really well.
The only thing which was excruciating to get set up right was Webpack, but
that's not Vue's fault nor Typescripts.

Granted, the reason it works well for us is because we started out right by
looking at existing templates using Vue + Typescript which probably saved us a
lot of hassle. The wrestling with configuration switches was by and large
already done for us, but having used this combination extensively now I can
say I'm familiar with all configuration matters in our projects and I find
none of them particularly poorly documented or obscure.

------
sharpercoder
One particular weak point of Vue is it's dependency on build tools. I spend a
few days buiding a great app, and then another few days on getting the build
apps configured right with Vue. You google from one error message to another,
where each message is unclear and no relation to any build
tool/plugin/library/script is made.

I really like Vue for the many great strong points it offers. But I'm equally
ready to completely ditch Vue for its complete and utter garbage with respect
to build/debug configuration.

~~~
shakna
Version with debug enabled:

    
    
         <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>
    

Production version:

    
    
        <script src="https://cdn.jsdelivr.net/npm/vue"></script>
    

If you need something more complex, vue-cli has webpack inbuilt:

    
    
        vue init webpack my-project
        cd my-project
        npm install
        npm run dev
    

Or if you need webpack, but not the complexity, swap the word 'webpack' in the
above command to 'webpack-simple'.

... Vue has already done the hard work of getting the build apps configured
for you.

~~~
The_suffocated
I don't follow. How to use Vue's single-file component if you only load Vue
from a script tag? And can I use Brunch instead of Webpack if I want to use
single-file components?

~~~
crazyideaman
Vue's single file components (SFC) require a build tool such as Webpack or
Browserify. See [https://vuejs.org/v2/guide/single-file-
components.html](https://vuejs.org/v2/guide/single-file-components.html)

------
fiatjaf
It is good just for the simple stuff, the world of webapp examples, todo lists
and so on. For all that, Elm is much better.

For all things more complicated and that require intelligence to think about
good architecture and how to structure state, the magic of Vuex won't do the
job for you, and in fact it will hinder you from doing it. React doesn't have
these limitations.

Also, the community on Discord is not friendly, in fact the community and the
limitations of the framework are quite similar, they're all "write a todo-app
like the tutorial, or I won't be able to help you".

~~~
tarellel
Care to explain how complicated apps are a no go? I've used Vue for about a
year and half now. Some of my apps have been very simple some of them have
been extremely complex. I can say I've had very few issues along the way.
VueJS is absolutely amazing. You just need to throw-in some mixins, Vuex, Vue-
Router, and whatever else you may need and you should be golden!

------
hardwaresofton
I agree with the point that one of the biggest warts on Vue are the corners of
the reactivity system (first point in the "Not so magic" section of the
article") and how it can surprise you. IMO if Vue had reactivity like
KnockoutJS did, it'd be perfect on that front.

I disagreed with the "unclear architectural patterns" \-- I've found just
writing Vue components that function as Services to hold all that kind of
logic more than adequate, and have never really needed to follow the Flux-
ish/Vuex approach. 90% of the time all you're doing is making web requests and
possibly displaying data or results to the user on the frontend... If you're
clever, you're doing a little caching and figuring out _when_ to perform
remote fetches, or storing stuff in local/session storage.

I think Model-Service-View frameworks are the (minimal) future, where you just
pair a view library with a data management component (something _like_
Backbone, if not Backbone itself). MVC was the dominant paradigm (angular 1
days), then MVVM made an appearance (knockoutjs), and now MV-? where the ? is
some event-driven system or flux/vuex style system. I think abstracting to
Services allows flexibility at the model-management layer -- if you want your
services to send out events (and wire up your components to listen), then
good. If you want them to have promised based interfaces, that's fine too.

~~~
easymovet
Has anyone actually run into limitations of knockoutJS that Vue or React
solve? Knockout has typescript support, stable codebase, excellent tutorials,
large plugin base, and components that can be loaded with requireJS. We've had
great luck with it in the wild too.

~~~
DCoder
TSX views with full typechecking blow all stringly-typed templating solutions
like Knockout Templates out of the water. In addition to that, immediate DOM
repaint without any consolidation is inefficient and hard to debug at times.

------
andrewstuart
I don't get the thing about ReactJS boilerplate where he says "Moving from
React to Vue seems like a breath of fresh air. No more bind(this) or
setState() everywhere. Yay! "

Surely there's better ways of doing ReactJS rather than lots of setState? Of
course I use setState but try to avoid it generally.

And I almost never, ever use bind() - don't es2015 fat arrows make it
obsolete?

~~~
acemarke
Sort of. The nicest-looking approach is to use the Stage 3 Class Properties
syntax to write class methods using arrow functions, which auto-binds them to
the component instance as it's created (the equivalent of calling `.bind()` in
the constructor).

------
crimsonalucard
My problem with current gen frameworks is composition and modularity with
components. Making components stateless and having all data come in as props
from parents is good for modularity but how do you pass data back to the
parent? This is where the modularity becomes awkward.

I know of two ways in vue to do this and both ways either completely break or
make modularity awkward. The first way is to signal the parent with emit. This
ties the parent object to a signal and if you want to pass info even further
up past the direct parent you have to have components explicitly pass that
signal up. While this doesnt break modularity it absolutely makes it awkward.

The second way is to use vuex as a global. This breaks modularity by
immediately tying the component to a global. Vuex makes things easy but breaks
modularity completely as soon as a component refrences vuex.

I understand why things were done this way. Essentially it's done to prevent a
certain class of endless looping bugs but there has got to be a better way.

~~~
vanderZwan
> The second way is to use vuex as a global. This breaks modularity by
> immediately tying the component to a global. Vuex makes things easy but
> breaks modularity completely as soon as a component refrences vuex.

Can you explain a bit what you mean here?

I haven't used vuex yet, but to use my Redux/React experience as stand-in: the
channel to emit data changes through is passed as a prop as well, so the
component is still "modular" in that it is not hardwired to redux (or,
presumably, vuex). Since it has to connect to the outside world _somehow_ ,
that can't be the criterium for breaking modularity either. So I don't see
where the modularity

Having the data in a Single Source Of Truth seems a sensible reason to store
it globally as well.

(aside: elsewhere here I discovered S.js, a reactivity library that looks
really interesting. Perhaps using something like that to make the data
reactive to UI changes is what you're after?)

~~~
crimsonalucard
>Can you explain a bit what you mean here?

Any time you have something reference a global it becomes tied to that global
whether it's a function, component or something else. If I want to take that
component and move it to another project then I have to take that global and
move it along with the component. That is a form of broken modularity.

Passing a closure or global channel from parent to child is not modular. It
ties the parent to the child.

Observe function composition, lets say I want to build a function that adds 3
to a number and then adds 2 to a number. I have a base function called f
defined as:

f(n) = n + 1

now I create two functions through composition:

g(n) = f . f . f

h(n) = f . f

by composing f 3 times then 2 times I have thus created the equivalent:

g(n) = f(f(f(n))) = n + 3

h(n) = f(f(n)) = n + 2

the final function d(n):

d(n) = g . h = g(h(n)) = n + 3 + 2

Every aspect of my created function is modular and I have maximized code
reuse. Vue or React components do not have this property. If I build a UI from
vue components, the majority of those components can never be reused while on
the other hand my d(n) function is the reuse of a single function composed 5
times. The main reason is because data from the child must be sent back to the
parent this either makes the child tied to the parent or the parent tied to
the child.

The property of composition is achievable with a single source of truth
cascading data down to stateless components that only display the data.
Modularity breaks on the feedback loop. Is there a category we can invent that
will fit the UI mold?

------
parr0t
Interesting timing with coming across this article for me. I have started
developing re-designing our site frontend to use Vue with Vuex and the point
this author makes about where to put the API logic also made me scratch my
head a bit. Sometimes I just need to make a simple API call that does not
alter the application state and just needs to grab some information and render
said information in 1 component. Technically, in the component, I can just
call Axios and get the data then and there, but then I have other components
such as the Login that does need to set some Vuex state and therefore that's
abstracted away further in the actions/API class as all documentation seems to
suggest that's what you should do. I suppose I am just finding it a bit of a
challenge to keep things a) consistent and b) not overly abstracted for the
task at hand.

~~~
petepete
It's not perfect, but I think Vuex Pathify can help keep Vuex organised and
somewhat sane.

[https://davestewart.github.io/vuex-
pathify/](https://davestewart.github.io/vuex-pathify/)

~~~
davestewart
Is there anything in particular you found sub-optimal?

------
CryoLogic
Funny, the meh and the ugly points are all non-issues with Ember.js.

Sounds like he wants a convention over configuration framework from a
barebones DIY from the ground up style framework.

------
mmcnl
The ugly in this article isn't really the ugly, it's the good. Nobody's
holding you back from writing a simple ES6 module that handles API requests
for you. Vue is a view layer, nothing more and nothing less.

~~~
narrowtux
To be fair, being used to full frameworks such as angular, you think that you
have to do it in some kind of vue-way or react-way. I even made the mistake of
using a vue-specific HTTP library when I started. Only later I learned that
Vue and react give you the freedom to do whatever you want.

~~~
Too
Great comment. Seeing all the hate Angular gets I think this is the biggest
mistake people do when they use angular, they try to do _everything_ the
angular-way with an angular service for everything, like you say even getting
a angular-specific HTTP library, wtf?! They should have just removed the whole
concept of services to not confuse people. If you instead only use it as a
view layer it is actually quite nice. Same with vue and react, you should only
use it as a view layer, not build your entire business logic on top or around
of it!

------
bschwindHN
I mention this is pretty much any thread talking about frontend framework
architectures. Check out ClojureScript's re-frame project. It's maybe not for
everyone but in my opinion it's an elegant and distilled method for writing
React-esque views and handling data subscriptions. The syntax is of course
polarizing but it really gets rid of a lot of boilerplate.

[https://github.com/Day8/re-frame](https://github.com/Day8/re-frame)

------
Sir_Cmpwn
>Chat based community

There's nothing wrong with using chat for collaboration and support. However,
using a proprietary platform like Discord for this purpose a braindead move.
It's astonishingly dumb to do this.

Listen, IRC is not sexy. But it works, and has been chugging along for decades
now - in the same time that a few _dozen_ proprietary chat platforms have come
and gone. It's supported by dozens of open source clients and servers, has
integrations with all sorts of bots and git and ticket trackers and such,
there are dozens of libraries for working with it, and networks dedicated to
open source projects. It's a no brainer.

The particular issue called out in this article is trivially solved on IRC.
There are a half dozen ready-to-roll public IRC log softwares, and most of
your users have clients which are automatically keeping logs that can be
restored from if there's ever a service outage on your logger. Hell, if you
send me an email I will put my IRC client in your channel and publish public
logs for you for free.

~~~
KaoruAoiShiho
UI clients unfortunately suck in comparison. That's really the problem with
these no-owner platforms. Nobody has the financial incentive to make the big
monetary investment needed to get the last 10% user experience stuff fixed.

~~~
MaxLeiter
Work is being done in this front with ircv3 and modern clients, though

~~~
Operyl
We’ve been hearing this for the past ten years now it feels like. IRCv3 seems
to have fallen short on most of its promises.

------
caseymarquis
What the article refers to as boilerplate is actually something I like about
Vue. Standard component organization is a good thing.

------
NathanCH
I think both React and Vue become difficult when working with complicated UIs.
If you're already using Vue or React, these simple articles are not
comprehensive enough to be convincing.

React and Vue basically manage state the same way, which is 90% of what you'll
be doing in these libraries.

And just like in React, default state management is insufficient in Vue.

~~~
orangecat
_And just like in React, default state management is insufficient in Vue._

That hasn't been my experience at all. The medium-sized app I worked on used
what is apparently called the "store pattern": a state class with data and
methods that mutate it, and components that read the data but only update it
by calling its methods. This provides the major benefits of Redux
("functional" components whose only state is purely local) with much less
complexity.

~~~
littlecranky67
Redux is only a little more work/complexity than the "singleton state class"
approach but brings a lot more benefits: timetraveling debugger, serialization
of the state (i.e. to localStorage to allow multi-tab operation or resume
after tab was closed) and separation of pure HTML/Visual Components versus
Container components.

Oftentimes beginner would create just a single React component that references
the state - which immediately couples the visual parts of your Application to
your data, making it harder to introduce automated testing later on. When
using the smart/dumb pattern together with react-redux it is very
straightforward to come out with a good architecture, that does not mix ui and
business logic/data handling.

------
rajangdavis
I tried nuxt (a vue framework) the other day and was disappointed. It seemed
like a very straightforward way to create a UI over a REST backend, but I kept
getting stuck with the issue of how to have a clean separation of the back end
and front end responsibilities.

For example, I wanted to have a UI that was rendered based on the JSON payload
that would get committed to a Vue Store. I consistently ran into issues where
Vue would complain about the client rendered code differing from the server
rendered code.

Are there any js frameworks where you can specify which components are
rendered on the server and which are clientside?

~~~
KaoruAoiShiho
Strapi just released their tutorial on nuxt and other backend stuff.

[https://blog.strapi.io/cooking-a-deliveroo-clone-with-
nuxt-v...](https://blog.strapi.io/cooking-a-deliveroo-clone-with-nuxt-vue-js-
graphql-strapi-and-stripe-bonus-deploy-part-7-7/)

~~~
rajangdavis
I appreciate the share, but looking at this
example([https://blog.strapi.io/cooking-a-deliveroo-clone-with-
nuxt-v...](https://blog.strapi.io/cooking-a-deliveroo-clone-with-nuxt-vue-js-
graphql-strapi-and-stripe-restaurants-list-part-2-7/#gist90478038)) it appears
that they are employing a pattern that I do not want.

I want to be able to have essentially have everything server rendered with
reactive views. Not sure if there is anything that supports that, but I feel
like that's how a SPA "should" work to an extent.

Also, what gets really weird is if you are trying to use environmental
variables. The solution is to inject your environmental variables into the
client ([https://nuxtjs.org/api/configuration-
env/](https://nuxtjs.org/api/configuration-env/)) which is what I want to
avoid.

I can do what I want to an extent with Ruby and Sinatra, I just want to avoid
setting up webpack and babel for getting the reactive components.

------
tnolet
Been writing a lot of Vue.js lately. Tried React, but hit the same snag when
learning (ancient) Greek in high school: when I look at a page of JSX my mind
just freezes. It's the type of symbols and the syntax that just make me glaze
over. Of course, this is very very personal and doesn't say anything about the
validity of JSX or ancient Greek for that matter.

------
deckar01
There is a plug-in that lets SFCs use es6 class syntax instead of objects [0].
The code looks so much better. I don’t think the docs ever mention it.

[0]: [https://github.com/vuejs/vue-class-
component/blob/master/REA...](https://github.com/vuejs/vue-class-
component/blob/master/README.md)

------
bryanlarsen
Rather than abandoning chat, they could use a service that is google-able and
linkable. I recommend zulip. Added bonus: open source.

------
zubairq
I used React for 3 years but once I discovered Vue I switched. The reason is
that React and Vue have different audiences. Vue is more for people who don't
think in code whereas I think tht React is more for "Hard Core Developers", so
I chose Vue for a Javascript development platform that I built

------
ld00d
>Will a state manager start mediating all application logic now?

The author refers to the shopping cart sample -- which is exactly what I used
as a blueprint. I think that's acceptable that the design pattern suggestion
is coming from the store layer vs. the template layer (who is focused on the
UI/UX).

------
vmware505
It is just my feeling that Vue.js is almost like Ember.js, the only
differences that Ember.js is more matured?

~~~
sametmax
VueJS has a lower API surface than Ember: you just have components. Not a
specific type of object for your model, and the a controller on the side, and
specific methods, etc.

You have one component with data. You may bind it do a template. You insert it
in the DOM, or in another component, and if the data changes, everything
rerender automatically.

That's it. There is nothing more to it.

------
HumanDrivenDev
I started out with vue, but found it too heavyweight and clunky. A viewmodel
framework shouldn't need its own god damn compiler or file format. I ended up
switching to mithril.js, which is much smaller than vue and comes with its own
router. Haven't missed vue at all.

------
vanderZwan
Has anyone checked out the linked framework benchmark[0], and some of the
other frameworks linked in there? I had not heard of surplus and S.js before,
but they look like an interesting combo[1][2].

Their reasoning for why surplus uses real dom nodes seems pretty solid[3]. My
oversimplified TL;DR: a virtual DOM mainly solves the problem of _JavaScript_
not being reactive; the DOM already is. So if you have an efficient general
solution for adding reactivity to JS, the need for a virtual DOM is reduced as
well, and removing it then saves on the performance / complexity / interop
overhead that it would add.

And S.js looks like pretty sweet reactivity library, even without surplus -
lots of fine-grained control options too.

[0] [https://github.com/krausest/js-framework-
benchmark](https://github.com/krausest/js-framework-benchmark)

[1]
[https://github.com/adamhaile/surplus](https://github.com/adamhaile/surplus)

[2] [https://github.com/adamhaile/S](https://github.com/adamhaile/S)

[3] [https://github.com/adamhaile/surplus#why-real-dom-
nodes](https://github.com/adamhaile/surplus#why-real-dom-nodes)

------
noname120
Previous discussion:
[https://news.ycombinator.com/item?id=17349849](https://news.ycombinator.com/item?id=17349849)

------
mey
I wish Typescript and Vuex played better together.

~~~
cholmon
Agreed. Luckily "Better TypeScript inference" is on the roadmap for Vuex 4.

[https://github.com/vuejs/roadmap#vuex-4x](https://github.com/vuejs/roadmap#vuex-4x)

------
philliphaydon
> The Vue community hangs out on Discord

Oh? I've only ever been in the gitter room... I had no idea there was a
discord too...

------
nnq
What I still never saw so far, and what this article also avoids, was an
actual explantion of

\- _why ever choose Vue over a minimalistic React setup?_

I mean, yeah, when people say "React" they mean "Reach + a ton of other heavy
complex stuff", but core _react + redux_ seems even _more lightweight_ than
Vue. Or you'd just choose Vue to keeps way the "React gurus" that would come
in and overcomplicate everything? :)

------
baby
I'd say today, there is little to no reason for small to medium sized websites
to use React instead of Vue.js

~~~
plopz
For small to medium websites, what benefit does React or Vue have over plain
HTML + jQuery?

~~~
baby
It’s a framework, meaning it makes a lot of things easy out of the box, if
you’re willing to re-implement this stuff or if you don’t need it then
html+query all the way

------
k__
I like the WebComponents integration, but the rest feels like Ember components
to me.

React achieves much more with much less.

------
hvidgaard
> Vue is really fast. Maybe not the fastest, but its performance is overkill
> for the vast majority of web projects. When was the last time you needed to
> render and update thousands of DOM elements per second?

Rubs me the wrong way. Better performance is always a net gain, and a high
performance website provides miles better UX than the same website with
waiting all the time.

~~~
Vinnl
> Better performance is always a net gain,

I think that's easily disputed: it's always a trade-off. A 0.001 ms
improvement in performance is a net loss if makes code 10x less readable,
because that means programmers are more likely to introduce bugs, which would
be a net loss. For example, I one worked with someone who changed all i++'s in
a codebase to ++i's, even though they were not in performance-critical
codepaths. That was not worth the effort.

~~~
hvidgaard
I was speaking in the context of two different frameworks, not code, but I
suppose the clarification is nessesary.

> I one worked with someone who changed all i++'s in a codebase to ++i's

Did you use the previous value of i, or did you just intent to increment it?
++i communicate that I'm not interested in the old value, where as i++ does
the opposite. I actually use it as such, because my intent to a future reader
of the code is more clear.

That said, for complex types, and with "stupid" compilers ++i can absolutely
be significantly faster.

~~~
Vinnl
> Did you use the previous value of i, or did you just intent to increment it?
> ++i communicate that I'm not interested in the old value, where as i++ does
> the opposite. I actually use it as such, because my intent to a future
> reader of the code is more clear.

I would consider that a valid reason to use ++i. In this case, however, he
indicated performance as being the reason. Furthermore, this was for a school
assignment demonstrating that we could properly implement a particular
algorithm, so the performance difference was absolutely irrelevant.

------
jorblumesea
One of the best arguments against Vue is typescript support. React has really
good support for it, even for the state libs like Mobx/Redux etc. Until they
turn that around it will be hard for any frontend application to scale
properly.

I think Vue is great for smaller projects and would absolutely recommend it.

~~~
philliphaydon
TypeScript works fine?!?!? With @vue/cli it's trivial to setup, it's literally
option in a new app.

Vue 3 they are moving to TypeScript:

> Will be using TypeScript. For internal implementation only. Does NOT affect
> ES users, but should improve TS integration for TS users.

[https://github.com/vuejs/roadmap#3x](https://github.com/vuejs/roadmap#3x)

~~~
jorblumesea
Hardly as polished as other frameworks. Sorry, just not true.

------
david-cako
If this is your article I'd love to know your VS Code color scheme.

------
pwaai
is there any progress on progressive web apps regarding with vue.js or is this
still an after burner project?

