
How and why we moved to Vue.js - fodoj
https://mkdev.me/en/posts/how-and-why-mkdev-moved-to-vue-js
======
mythz
Having used both React and Vue extensively. I'd say React's great at Single
Page Apps in the true sense of the word, Apps that have a single UI like an
IDE:

\-
[https://github.com/ServiceStack/Gistlyn](https://github.com/ServiceStack/Gistlyn)

Vue's nicer to use without any build tools using just vanilla JavaScript:

\-
[https://github.com/NetCoreWebApps/Redis](https://github.com/NetCoreWebApps/Redis)

Vue's also nicer for "page-based" Websites that are converted into Single Page
Apps. Nuxt.js really shines here which lets you develop complete Websites
using Vue's Single File Components and takes care of routing by following a
conventional page structure. Nuxt.js + Vuetify will be my goto for many
traditional Website style Apps (implemented as SPAs) going forward. It imposes
an opinionated convention but saves you a lot of effort having to manually
configure and integrate different libraries together.

Vuex is more pragmatic and requires less effort/code to use than Redux, but
Redux is great when you need to access previous states, e.g. it makes it
effortless to capture "Snapshots" of the entire current state of the App that
you can send to someone else so they load your App exactly as you see it:

\-
[https://github.com/ServiceStack/Gistlyn#snapshots](https://github.com/ServiceStack/Gistlyn#snapshots)

Or when you need to sync state changes between network apps:

\- [https://github.com/ServiceStackApps/typescript-
redux](https://github.com/ServiceStackApps/typescript-redux)

But if you don't need these features, in general Vuex/Mobx is easier and
requires less effort to develop with.

~~~
dabernathy89
You may know this already, but using Vue Dev Tools you can easily export &
import Vuex state.

~~~
mythz
It will never be as easy as Redux where the entire state is maintained in an
immutable and naturally serializable plain JavaScript object in which all
messages can be inspected, serialized, dehydrated, sent over the network, etc
with every App state transition being easily captured / replayed or reverted
to any period of time. You can force it with other state management libraries
with additional machinery, but Redux's approach of sending plain JS object
messages to create immutable states is naturally well suited for the task.

~~~
dabernathy89
I'm sure they operate differently under the hood (and that's a bit of a black
box for me), but as an end-user I can do any of those things with Vuex as well
- time traveling, serializing state, subscribing to state mutations, etc.
Doesn't require Dev Tools either, although obviously that's much more user-
friendly.

~~~
mythz
Like I said it's possible but requires additional effort and machinery, with
Redux your App already constructs and dispatches state transition
instructions/delta messages and renders the plain state object as a first-
class construct, whereas other state management libraries need to create
foreign artificial constructs to support it.

~~~
dabernathy89
Perhaps I'm missing something. Vuex state is almost a plain JavaScript object
but with Vue's getters/setters on it. I can access the root state object
easily with `store.subscribe((mutation, state) => {}`. Mutations feel nearly
identical to reducers (but simpler!) and interact with the state as a plain JS
object. What `foreign artificial constructs` are we talking about here?

EDIT: I assumed Vuex state was immutable outside of mutations, but that's only
true with 'strict' mode enabled.

------
jaequery
Coming from Angular, I hated seeing another framework that has conditions
inside elements, like v-if, v-bind, etc.

Especially when I saw things like @click, @submit, etc, I said Vue is not for
me.

However, you quickly realize it's not like Angular where those declarations
can at times be overwhelming. In Vue, there are not that many and it is
actually much more simpler and even intuitive.

Also, when coming from React, being able to use certain things like v-model
makes you not want to go back to React, and has shrunk the code and simplified
it quite a bit.

~~~
spraak
> Also, when coming from React, being able to use certain things like v-model
> makes you not want to go back to React

Could you explain that further? I definitely see Vue as an improvement over
Angular, but React still is much better for me than Vue, so I'm curious what
you mean.

~~~
fbonetti
v-model is a two-way binding. In other words, you don’t have to write a setter
function for every piece of state - you can hook up a state field directly to
a text input, for example.

React doesn’t allow two-way binding, or at least heavily discourages it. The
downside of two-way bindings is that they can make it hard to track and
understand state changes. The upside is that they drastically cut down on
boilerplate for things like forms.

~~~
FlorianRappl
Personally, I think one of the best things of React is that it left out two-
way binding _on purpose_. I agree, that sometimes people write a lot of
boilerplate therefore, but at least it can be understood (and modified)
easily. Advanced people write nice re-usable functions with the same effect,
but less boilerplate.

~~~
ohceecho
v-model in Vue is not exactly two-way binding. It is just syntax sugar for
passing the value as a prop and setting an event handler for the “input”
event. It looks like two-way binding but has none of the gotchas.

I agree with you point btw.

~~~
fbonetti
How is that not two-way binding? The Vue documentation even calls it two-way
binding:

“You can use the v-model directive to create two-way data bindings on form
input and textarea elements.”

[https://vuejs.org/v2/guide/forms.html](https://vuejs.org/v2/guide/forms.html)

~~~
ohceecho
Yeah, the documentation should probably reflect that. It works like shallow
two-way binding, but it implemented differently. Instead of using observers on
the data itself, it uses an event, thus maintaining a cleaner interface
between the components and avoiding the performance problems and bugs that
come with two-way binding.

`v-model` is just a syntax sugar to save you from typing `v-bind:value="val"
v-on:input="val = $event.target.value"` over and over. Nothing more than that.

~~~
dabernathy89
V-model is great. For other folks reading this thread, a few things it lets
you do:

1) You can still use v-model with Vuex:
[https://vuex.vuejs.org/en/forms.html](https://vuex.vuejs.org/en/forms.html)

2) You can easily distribute custom components that provide `v-model` to users

3) You can dynamically accept 3rd party components that implement `v-model`.
E.g., I have a component that incorporates standard form fields, but can also
be used with any custom components that properly implement `v-model`.[1]

[1] - Vue Query Builder ([https://dabernathy89.github.io/vue-query-
builder/](https://dabernathy89.github.io/vue-query-builder/)) - try adding a
'Range' rule to see this in action

------
navd
These posts are becoming redundant. Although I do understand where the author
is coming from. I think the issue is that frontend development is hard!
Especially modern frontend dev. It requires an entirely different thought
process than backend development and this is why I think so many people get
scared and reach for the most familiar lib out there.

However, getting used to the React ecosystem really does have huge benefits
(code clarity, minimization of bugs, ease of creating complex interactions)
and I do recommend that those interested really just dive in and build
something simple to see for themselves.

If you're new, ignore [babel, redux, (insert buzz lib here)] and just build
something. Checkout [https://medium.com/@clmyles/react-without-npm-babel-or-
webpa...](https://medium.com/@clmyles/react-without-npm-babel-or-
webpack-1e9a6049714) on how to create something with just React.

All the extra libs and tools are helpful and make your job easier in most
cases. But they can be phased in as you get a deeper understanding of the
ecosystem.

The ecosystem is standardizing now. And I don't see webpack or React going
away anytime soon.

------
ourmandave
I'd love to read the follow up article 1 year from now. And then 3 years, and
5 and 10.

Vue 2.0 was a complete rewrite and their "long-term-support" for v1 was _9
months_ of security updates.

I'm not trying to single out Vue, but I wonder how many job posting are for
someone to maintain a legacy framework code base. (Legacy meaning 6 months
old.)

~~~
huskyr
The difference to me with other frameworks (most notably Angular) is that the
transition from Vue 1.0 to 2.0 was relatively smooth. I've migrated a couple
of smaller applications and that was done in just a couple of minutes. If Vue
keeps the core and focus small i think maintenance will be easier than with
comparable frameworks.

~~~
krob
Vue is the php of JS frameworks. Feeling a bit ironic for using it, I'm also a
user of php, and it just feels right.

------
erokar
I don't get the Vue hype. Sure, Vue seems nice enough, but it is concepteually
very similar to React, so nothing new there. The pros of React are a smaller
API and JSX instead of an added templating language (the latter being a
contentious issue, I know).

EDIT: I realize now Vue does have optional support for JSX and you are not
forced to use a templating language.

~~~
GhostVII
I find vue much simpler to start out with and build off of, since it is almost
all just regular html and JavaScript, as opposed to React which uses jsx and
has lots of painful setup of tools like redux and react router. Vue.js has a
really good webpack starter kit that will give you a working site that you can
expand really easily so that makes setup super simple.

~~~
Bizarro
Just don't use redux. Maybe one day there will be a decent, ergonomic
framework on top of the flux architecture, but redux ain't it.

Try mobx state tree for all the benefits that redux has without the pain.

Vuej seems nice enough (especially for migrating server side tech apps), but
I'm still not digging the templating engine. I've seen the way you can use JSX
in Vuej, and I don't like it.

------
jaequery
In my opinion, Vue is the most elegant javascript library out there. Jquery
used to take this spot for me, but Vue has superseded it .

Everything just makes a lot of sense without a lot of fluff added to it. It
does everything React does and I'd say does a lot more using less codes.

When choosing a framework, simplicity, performance, and support are the main
things you should look for and Vue is a hands-down winner here.

~~~
mercer
> Everything just makes a lot of sense without a lot of fluff added to it. It
> does everything React does and I'd say does a lot more using less codes.

This is also why I'm positive about Vue having a good 'place' in the
ecosystem. React can be a bit overkill for smaller projects.

That said, I feel about it a bit like I do about testing. It might not be
necessary for a lot of stuff, and it can feel tedious to do, but as projects
grow, I often find myself wishing I'd added tests from the start.

In general I find myself leaning towards preferring too much 'boilerplate'
over too little, at least as rule of thumb.

~~~
BigJono
I'm curious how people think React is overkill when it's entire API pretty
much boils down to one or two functions.

React is the simplest, most powerful library I've used in my life. It's the
community that (often misguidedly) adds the complexity.

~~~
mercer
Overkill might not have been the best choice of words. What I meant was that
because React is so simple, it can be a lot more work for relatively little
gain in a smaller app. It's same reason I used to often still go for jQuery.

But I agree, I love the simplicity and it fits well with my rapid descent into
being a functional programming weenie.

------
amelius
I tried to use Vue.js recently, but found that there's a huge set of idiomatic
coding principles, as opposed to a small set of primitives. Which basically
makes it not for me.

What I also disliked was how they don't explain how to get it working without
a build-environment like webpack. That makes it really a "framework" in the
sense that it's all-or-nothing. Again, not my style. I prefer self-contained
libraries.

~~~
ohceecho
I disagree with the assertion that it has "huge set of idiomatic coding
principles", but I think that's a matter of opinion.

However:

> What I also disliked was how they don't explain how to get it working
> without a build-environment like webpack.

This doesn't make sense. The official website includes a way to use it by just
including a script from the CDN, on the "Get Started" page. It even
discourages using the build tools if you don't have prior experience:
[https://vuejs.org/v2/guide/](https://vuejs.org/v2/guide/)

~~~
amelius
> The official website includes a way to use it by just including a script
> from the CDN, on the "Get Started" page.

But how about an explanation of how to compile the .vue files (used in the
examples) to JS? Or how to do without them?

~~~
ohceecho
You mean the examples in the link I posted? Those are just javascript and
HTML, there's nothing special about them.

Just put that on an HTML file and run it in a browser. No need for any tool
other than a text editor.

To compile .vue files you have to use vue-cli (linked on the "Get Started"
page), or some third-party tool (instructions here:
[https://vuejs.org/v2/guide/deployment.html](https://vuejs.org/v2/guide/deployment.html)).

~~~
amelius
Ok, upon a second look, it seems that those directives are translated in-place
in the HTML document, so indeed I could have coded the examples in HTML. But
it feels a bit like magic.

Still, I wonder, how do I make components? Are they also encoded in the DOM
tree? It feels a bit strange to encode templates in the actual DOM tree, even
without using them.

------
adventured
I keep waiting on fully commiting to either Vue or React, to see which might
end up dominating so I don't have to waste a lot of time on the one that will
likely end up wilting. I've been doing the equivalent of full-stack web
development non-stop since 1995 or so. My tolerance for going with the loser
has declined persistently toward zero year by year, due to two decades of
randomly eating shit when going with the wrong platform/library/tool/whatever
(wrong, meaning, the one that loses the popularity contest and ends up
practically disappearing).

I've spent a modest amount of time with both. I find myself repeatedly drawn
back to Vue every time I work with the two. I like it dramatically more than
React. HN seems to love Vue, I can't decide if that's primarily due to its
underdog non-FB position. HN loves the underdog, as most forums made up of
people will. Whatever the case, React is winning the popularity contest at the
moment. I'm pulling for Vue.

------
burlesona
One thing that is really great about Vue is it’s ability to just work with
whatever setup you have. Sure if you’re building from scratch it’s great to
have robust build tooling, but sometimes you need to write good front end code
in the midst of an old app that’s in bad shape. Having used both React and Vue
extensively, I’d always reach for Vue when trying to add modern UI components
to a legacy app. It manages to work beautifully even when you need it to just
be loaded old school via script tag and to interop with adjacent jQuery code.

~~~
zmmmmm
> I’d always reach for Vue when trying to add modern UI components to a legacy
> app

This is the thing that steers me strongly to Vue. If I'm building a component
I like the idea that it's at least _potentially_ reusable in the widest
possible set of situations. With React I feel like my component is usable only
in other React apps (including the full webpack build etc), which, as popular
as React is, is still approximately 0% of the world's web applications. With
Vue I feel I can make a component that can drop in seamlessly to just about
any HTML page in the world.

------
Tade0
We use Angular (2+) at work, but after hours my framework of choice is Vue.

One striking difference between these two is: I can build a Vue application
from scratch mostly relying on my memory using a basic text editor if need be.
The same feat is nigh impossible with Angular.

A decent IDE helps, but being on my second project now using this framework I
still rely on examples from the first one.

What I wanted to say is that comparing to Vue Angular is full of unnecessary
complexity.

~~~
nojvek
After dealing with angular complexity, vue is great.

But the simplicity of react/preact can’t be beaten.

Vue does have nicer bells and whistles though.

------
nojvek
Not sure why he/she hates webpack or any sort of web bundler. It’s one of the
most nicest things. I can use es6 modules and declare dependencies upfront.

Also I don’t get the hype about vue over react or any virtual dom based
framework.

Vue just doesn’t feel like you’re dealing with functions. It’s too much
spaghetti.

I want to be able to hot replace templates, it’s controller logic and styles
without a page refresh. I also want great type checking and intelligent
refactors of props and states

Typescript with React is a godsend.

~~~
burlesona
Vue does hot module reload and all that jazz, and it works with Typescript
too.

I totally disagree with you about the code being spaghetti. To me the
spaghetti is designing views in React and having a relatively simple DOM
structure broken into twenty little functions so that it can be expressed as
readable JSX.

To me one of the best things about Vue is that it lets you effortlessly choose
between and even combine templating and JSX. Templates are vastly easier to
read when you need to understand the DOM structure and when you're looking at
something on the screen and identifying where it lives in your components. And
when you have complex elements where a render function really is better, JSX!

~~~
joshribakoff
Vue nor react do hot reloading per se. There are official webpack plugins to
do so, which the author didn't want to use so presumably that wasn't a
motivating factor. I also disagree that small focused components are
spaghetti. The authors giant components smell like spaghetti because they mix
business logic and rendering. Author should look into separating container and
presentation components, which is idiomatic in react

------
bichiliad
Honestly, I empathized a lot with this. I spent a lot of time at work writing
non-frontend code, and felt pretty rusty once I moved back to it. There are a
ton of fuzzy things to learn: what's the right way to require a module? build
systems are common practice now? what happened to bower? are there
differentiators between node and browser libraries?

Worse yet, every time you search for a topic, there are dozens of conflicting
community-generated articles, just because the landscape changes so quickly. I
don't think there's a solution apart from "watch what the industry is doing"
and "be patient."

~~~
burlesona
Yeah, front-end dev is a mess right now, and it probably will be for a while.
I think a simple description of what we're living through is the low level
primitives (DOM and JS) are locked in and are gradually becoming more
powerful.

Meanwhile developer world doesn't love working on complex apps using low level
primitives, and since the web is pretty easy to grok there are a million devs
who feel like "oh man I can write a good higher level framework/pattern/tool
on top of this," so they charge off and make it.

And the thing is, most of the tools being built are reasonably good and
useful, but it is overwhelming trying to keep up.

What I suspect will happen is that the more successful patterns will become
more and more deeply entrenched until there are only really two or three
accepted "good ways" to build stuff, and then you'll see a few major libraries
in each of those camps that rise to the top, and this will all start to settle
down into boring old tech as the hipsters run off to tackle some new hot
ecosystem.

We're probably still a few years out from that, though :)

~~~
crimsonalucard
It's already happened. There are basically already 2-3 good patterns: Vue,
Angular and React. It's just that the existing patterns are far from perfect
so the industry continues to evolve at a breakneck pace.

------
byte1918
I was expecting a comparison to react or angular. Comparing jQuery to a
reactive frontend framework in 2018 is just... too easy.

------
brwsr
> I’m very bad with the front-end and don’t like it. The rest of our team has
> the same feelings.

Hmmm..

> In early 2017 we almost solved the problem with the front-end, as we hired
> an expert who made the whole site over using BEM block technology.

BEM! hahaha

BEM is not mandatory for a good front-end, at all.. It sounds like you
actually need a good, experienced and passionate front-end developer. But if
you don't want one, I agree that Vue.js is a relatively safe choice. I only do
Vue.js for smaller projects, a little bigger and I switch to React or Angular.
But I always try to mind (before switching and advocating a library) that
there is a fair chance that within 5 years it is deprecated already, just like
jQuery.

~~~
conradfr
I've always disliked BEM code looks-wise. Maybe it's a shallow reason to avoid
it ...

~~~
mercer
I figure if you're gonna use BEM, you might as well just go for CSS-in-JS
these days.

------
franciscop
Using tools that other people created, documented, and put up for free for
anyone to use and calling them "junk" makes me really sad :(

~~~
fodoj
I didn't mean calling tools themselves "junk", but rather dozens of auto-
generated files which don't give me any profits at this time. I am pretty sure
all these things make a lot of sense, and we are getting to the point where
trying out WebPack might make sense for us.

~~~
franciscop
How is that possibly true? You even named the _junk_ :

Babel, postcss and yarn.

And then you stated a 3rd person saying:

"It’s not junk, these are the most important _tools_ "

Disrespectful AND lying, nice combo you got going...

------
ggregoire
I'm not so familiar with Vue (coming from jQuery -> Backbone -> Angular 1 ->
React) but I know there are different ways to write components in Vue
(including classes and JSX). Well, it's the first time I saw the style they
chose and it looks awful. It seems like Backbone but with everything in a
single JS object. A component as a configuration file. Maybe it makes sense
for Backend people? (familiarities with defining systems in json, yaml,
dockerfile, etc)

------
Bizarro
I've been doing React for a couple years now, but for the past couple days
I've been watching some videos and reading up on Vuej.

The thing that I will always hate about Vuej (and other/most frameworks) are
templating engines (aka string code in attributes). That's always going to be
a code smell to me.

That said, I can see the appeal to Vuej. There's a very gentle migration path
to Vuej. It's much more natural just to use ES5 with Vuej than with React.

Vuej like most "frameworks" is opinionated about the rest of the pieces of the
puzzle - routing, state management, etc. React is very a la carte in that
regards. State management is still a complete mess in the React world.

I'll probably have to try a small project or two in Vuej. The tooling in
VSCode seems to be decent these days.

------
baby
I made a DAPP with Vue.js recently (www.davidwong.fr/FiveMedium) and it was
amazingly fun to learn and use. Things made sense while I had difficulties
grasping how to use React or even follow their tutorial to do anything
practical.

I'm definitely happy to see more and more people using Vue.js

~~~
fbonetti
I also made a couple DAPPs recently, the first using Vue (which I have very
little experience in) and the second in Elm (which I have years of experience
with and have used in production).

I never thought I’d say this, but I was a lot more productive with Vue and it
was more fun. Static types and immutability are great for long term stability
and refactoring, but it felt great to just bang out an app in a few hours and
not worry about the overhead and boilerplate that comes from using a strict
language/framework like Elm. I’m definitely going to use Vue on my next DAPP.

------
lol768
Unsure if it's just me, but the article doesn't seem to render the text
properly: [https://i.imgur.com/donfa0W.png](https://i.imgur.com/donfa0W.png)

With that said, definitely an interesting read and reassuring to see that you
don't need a million tools to get started. I'm doing less frontend than I used
to now, but I'd still like to have a play around with Vue.js at some point to
try and avoid the jQuery mess you often end up with when you end up sprinkling
some client-side functionality on top of a primarily server-side rendered app.

------
IgorPartola
I feel very productive using Vue. I wish it had first class support for forms
though. My home cooked concoction for that works well enough but isn’t ideal.
Otherwise, it’s the best thing I’ve used in 2017.

~~~
mythz
Vuetify Forms has great support for client validation + easy ways to hook up
server validation:
[https://vuetifyjs.com/components/forms](https://vuetifyjs.com/components/forms)

------
sjellis
Vue.js is due to drop support for legacy browsers in March (oddly, in a point
release):

"Will be targeting evergreen browsers only in order to leverage native ES2015
features"

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

I sympathise a lot with the desire, but if you work with corporate or other
markets where old browsers just won't die, then Vue may not be a feasible
option.

~~~
breakingcups
It actually won't be a point release if I recall correctly, it's just weirdly
worded on the roadmap. 2.X (current version) and the next version will be
maintained in parallel.

------
dham
They're using jQuery wrong and now reaching for a framework. If you write bad
code in jQuery you're going to write bad code in a framework. I've seen it a
dozen times. Use event delegation and behaviors, not "if window.location =
''". That's just wrong. You can solve a ton of problems with jQuery(or plain
DOM api) and mutation observers.

~~~
dyeje
I disagree. As someone who recently made the switch from jQuery to React, it
is way easier to shoot yourself in the foot with jQuery. React let's you focus
on how the component should behave instead of doing mental gymnastics trying
to manipulate the DOM. There are always so many edge cases with DOM
manipulation, it rarely turns out well for anything but trivial things (which
I still use it for).

~~~
shams93
Yeah if you need a SPA jQuery won't work. Ultimately react and Vue will give
you much cleaner code at the cost of learning the shadow Dom. All the old Dom
methods from jquery and vanilla js over to shadow Dom instead.

~~~
masklinn
> Yeah if you need a SPA jQuery won't work.

It will certainly work, there are plenty of SPA which use jquery (or even
vanilla JS) for their DOM manipulation. But it will likely be significantly
more painful and prone to desync bugs than using a vdom-based system

Not just SPAs either, any non-trivial component is affected.

~~~
dragonshed
I challenge anyone to use jQuery to build a SPA and not re-invent backbone
(poorly or otherwise).

I built a simple site recently and one complex page ended up with shitty
recreations of backbone Model and View.. and never knew until a colleague
reviewed my code and suggested I look those up.

~~~
temporallobe
I recently did exactly this and it wasn't that bad. It's not that I couldn't
use Backbone, I decided not to because I didn't see the point in introducing
yet another library when all I really needed to do was bind inputs to a model,
which I did in about 5 lines of terse jQuery. Besides, I had custom widgets
that wouldn't have benefited from Backbone anyway and would have required
customization anyway. I think judicious use of libraries is ok, but tbe more
elite among us tend to become libray snobs and shame people for not doing
things the "right" way.

------
mythrwy
`There are 284 lines of such unbearable mingle, which is absolutely impossible
to grasp for anybody.`

284 lines of (relatively straightforward if poorly written) jQuery? Oh the
horror!

`Want to be as cool as Kirill Shirinkin?

Then enroll to the training! In his articles Kirill shares only a glimpse of
his true knowledge.`

I think I've seen enough but thanks for the offer.

~~~
always_good
The jQuery might be straight-forward in the sense that you know what
`$cardForm.find('input[type=submit]').prop("disabled", false)` does, but the
hard part is reasoning about the possible states of your UI when your only
source of truth is a bunch of procedural mutations.

Not only does it incrementally change the DOM, but it also queries state from
it. We've been trying to move away from that for some time now. I remember
that's how jashkenas pitched Backbone 7 years ago.

~~~
tomgp
Still, introducing a framework and a build system and everything that entails
for the sake of 300ish lines of code? You could rewrite that in plain js
avoiding the pitfalls you mention in less time I would have thought. As others
have mentioned they’d be better off employing a front end specialist...
whether they’d recognise a good one is a moot point.

------
wdhilliard
Sounds like they could have solved their problem by hiring a solid Front-End
Developer. Saying that you like to "focus on the backend" is a lot like saying
you only like to do half the work. If you find it too hard to master a whole
suite of software that you have ignored for 3+ years, go find someone who
already has and quit treating the front end like it's a toy

~~~
ggregoire
Exactly.

> In early 2017 we almost solved the problem with the front-end, as we hired
> an expert who made the whole site over using BEM block technology

Seems like they reduce the front-end to CSS.

~~~
BigJono
For some reason the phrase "BEM block technology" makes me cringe. It sounds
like something a non-technical manager would say, but these guys are actual
devs...

~~~
altern8tif
Same here. BEM is not "technology". It's a philosophy or an organisational
pattern.

------
tiuPapa
I am kinda new and here is one confusion I still have about frameworks like
Vue or React, why do we still need Virtual DOM? Shouldn't the browser DOM
already be first enough?

~~~
fbonetti
The virtual DOM automatically updates the real DOM for you, in a way that only
touches the parts that have actually changed. Think of it like a diff.

This allows developers to focus on the business logic and presentation of
their apps without worrying about how to update the DOM efficiently to match
the current app state.

------
mi100hael
...from jQuery. Safe to say any JS framework would have been an improvement
(and that's coming from someone who has very little love for JS frameworks).

~~~
GordonS
Disagree. Well, better to say 'it depends'. jQuery is still absolutely fine
for server-rendered apps that need some client-side functionality. Especially
if your devs are well versed in frameworks such as ASP.NET. MVC Core, for
example.

~~~
kangoo1707
What jQuery could have done with those server-rendered apps, Vue could always
do better. jQuery is just bad because of its DOM mutation paradigm.

You can totally use Vue with any MVC, no need to convert to SPA style

------
nikon
That example component code is hideous. It reminds me of Backbone, and not in
a good way.

------
crimsonalucard
Anybody have experience with vue building something that is long term,
maintainable and very complex? What is the technical dept when compared with
React?

Are there options to incorporate type checking into vue?

------
luord
Similar experience to mine, only I already had experience with the frontend
and other frameworks.

Vue is just that nice to work with.

------
azr79
Anything compared to jquery looks good, would be more reasonable to compare it
to Angular, or React

------
nthnclrk
On the front page:

"Hire a programming mentor and learn how to do everything he knows."

Might be worth being a little more inclusive here.

~~~
drumttocs8
Boy, it's a good thing we don't speak a language with strict grammatical
gender, or you'd be all kinds of pissed off

------
kevin_thibedeau
2018\. The year of VueJS.

~~~
moocowtruck
i think 2018 is the year of 'who cares js'

~~~
k__
Yes.

I had the feeling 2017 was year of Vue.js

I think the biggest players (Angular+NativeScript/React+React-Native) have
left Vue behind. While they try to abstract the UI problem from problems like
native, web or whatnot, leading to better abstractions and ease of use on
multiple platforms, Vue and co. are still meddling around on past problems.

~~~
adverbly
Fair point, but I'd like to add that if Vue is able to come up with better
solutions to past problems, then they will likely come out on top in the end.

~~~
k__
After using Angular, React and Vue I think this is greatly a matter of taste.

They all have great solutions.

------
mruniverse
How useful are these "Why we moved to ..." blog posts?

