​

The Hardest

Problem in Frontend

I’ve worked at a few tech companies you’ve heard of. I’ve been doing this frontend stuff since before the jQuery days. And allllllllll through them. And into Backbone, Angular 1, Meteor, React, and so many more (anyone remember Riot?).

So what's the hardest problem to solve in frontend?

• DOM Interaction? neh, tons of tools figured this out.
• State management? neh, we got decent tools for that now, especially in the Vue world.
• Testing? Well, yeah that one definitely sucks and our most cutting edge tools all feel a decade behind everything else we use, but... we at least have tools for this and progress is being made.
• Styling! well, not really we haven't made a single solution that solves it perfectly but between ITCSS, Sass, and Vue's Scoped option, with some very light sprinkling of atomic classes, we're doing good enough here.
• ….

The hardest problem

No... The hardest problem to solve in frontend is easily organization. You think naming things is hard? Try keeping organized a large complex system that evolves over time with different team members coming and going, all with different ideas of how stuff should be written and organized and favoring different patterns. Good fucking luck. It's a ticket straight to spaghetti code junction.

​

This leads us into…

​

What the React

community has to say

about React Hooks

—Dan Abramov, overreacted.io

—Dan Abramov, overreacted.io

—Dan Abramov, overreacted.io

“In a well designed system,

the right thing to do is easy,

while the wrong thing is difficult,

but possible”

“In a well designed system,

the right thing to do is easy,

while the wrong thing is difficult,

but possible”

​

Vue’s Composition API

Vue’s Composition API

<script>

import { computed, reactive } from 'vue';

​

export default {

setup: function () {

const state = reactive({

count: 2,

double: computed(() => state.count * 2)

});

​

function increment () {

state.count++;

}

​

return { state, increment };

}

});

</script>

​

<template>

<button @click="increment">

Count is: {{ state.count }},

Double is: {{ state.double }}

</button>

</template>

​

Vue’s Composition API

<script setup>

import {

computed,

ref

} from 'vue';

​

​

const count = ref(2);

const double = computed(() => count.value * 2);

​

function increment () {

count.value++;

}

</script>

​

<template>

<button @click="increment">

Count is: {{ count.value }},

Double is: {{ double }}

</button>

</template>

​

Vue’s Composition API

<script setup>

import {

computed,

onMounted,

ref

} from 'vue';

​

const count = ref(2);

const double = computed(() => count.value * 2);

​

function increment () {

count.value++;

}

​

onMounted(() => {

count.value = 10;

});

</script>

​

<template>

<button @click="increment">

Count is: {{ count.value }},

Double is: {{ double }}

</button>

</template>

​

Common life cycle hooks:

​

• onBeforeMount, onMounted
• onBeforeUnmount, onUnmounted
• onBeforeUpdate, onUpdated

Vue’s Composition API

<script setup>

import {

computed,

onMounted,

ref

} from 'vue';

​

const count = ref(2);

const double = computed(() => count.value * 2);

​

function increment () {

count.value++;

}

​

onMounted(() => {

count.value = 10;

});

</script>

​

<template>

<button @click="increment">

Count is: {{ count.value }},

Double is: {{ double }}

</button>

</template>

​

Vue’s Options API

<script>

export default {

data: function () {

return {

count: 0

};

},

computed: {

double: function () {

return this.count * 2;

}

},

methods: {

increment: function () {

this.count++;

}

}

});

</script>

<template>

<button @click="increment">

Count is: {{ count }},

Double is: {{ double }}

</button>

</template>

​

Vue’s Options API

<script>

export default {

data: function () {

return {

count: 0

};

},

methods: {

increment: function () {

this.count++;

}

},

created: function () {

this.count = 10;

this.increment();

}

});

</script>

<template>

<button @click="increment">

Count is: {{ count }}

</button>

</template>

​

Common life cycle hooks:

​

• created, beforeCreate
• mounted, beforeMount
• updated, beforeUpdate
• unmounted, beforeUnmount

This talk is not about…

• This talk isn’t here to just dunk on how bad React is, the React Community does that well enough on their own, and honestly the more I think about React, the more it reminds me of that Roy Zimmerman song “Don’t make fun of the crippled boy”.
• This talk isn’t here to point out that Vue consistently learns from others about what problems people are trying to solve, examines existing solutions and implementations, and always delivers a better implementation without any of the existing documented downsides of others. Though, it’s pretty rad that they just KEEP doing that.
• React classes are awful, actually classes in JavaScript at all just serve no value and are a terrible idea from people coming from other languages where they make sense because they have restrictions JavaScript doesn’t. But that’s a talk for another day.
• And just because React classes were a horrible idea and Hooks are an improvement, doesn’t mean they’re good. And Vue’s version, Composition API, though way better than React Hooks, is still years behind where we already were.

Vue’s Options API actually has a place for everything out of the box.

• It is documented.
• You can actually point a junior dev, fuck, even an intern, to the well maintained documentation and say "do it that way".
• It is consistent.
• You can go to any Vue codebase and not have to "learn" some arrogant "Architect's" half-implemented, undocumented, idea of organization that doesn't even work there anymore.
• It is well named and predictable.
• Just look at the lifecylce hooks: created, mounted, unmounted, beforeCreate, beforeMount, beforeUnmount, compare that to React's garbage.
• And you are rewarded by using it
• The features of the framework are built in to the component’s inherent organizational structure.

​

Anyone claiming that the composition API aids in organization has fallen for the hype and doesn't know the hurt they're in for. It deeply, deeply, saddens me that Vue 3's docs will be recommending people use <script setup> + Composition API over the Options API. I get that it's "the one big new feature" for this version, but it's such a back step.

​

The Options API solves hundreds of problems, most of which are "people problems" (the hardest to solve), and only really creates one new problem (code reuse through mixins is like a 4/10).

​

Composition API solves the mixin problem (hurray!).... but, only solves a few dozen of the same problems that Options API already solves, and misses most of the rest. This is easier to visualize than to explain, here I just made a quick graphic to illustrate the bigger picture.

Anyone claiming that the Composition API aids in organization has fallen for the hype and doesn't know the hurt they're in for. It deeply, deeply, saddens me that, despite Vue 3's docs not recommending one API over the other, the community is still filled with people thinking “newer = better”. Yes, it's "the one big new feature" for this version, but it's such a back step.

The Options API solves hundreds of problems, most of which are "people problems" (the hardest to solve), and only really creates one new problem (code reuse through mixins is like a 4/10).

Composition API solves the mixin problem (hurray!).... but, only solves a few dozen of the same problems that Options API already solves, and misses most of the rest. This is easier to visualize than to explain.

People Problems

Problems

solved by

Options API

Problems

solved by

Composition

API

The Options API is focused on organization, consistency, and a well documented “Convention over configuration”. From this, it solves so many problems, including some of the hardest problems, particularly “people problems”. Though it has code reuse solutions, they are lacking in polish.

​

The Composition API is focused on extending reactivity to outside the component. It solves some new problems from this approach, especially improving code reuse, but overall, is far inferior in comparison to the amount of problems it solves and particularly the hardest problems (people problems, and organization). Though often praised for allowing you to “invent your own way of organizing things”, this is more a curse than a gift and should be seen as such.

Code reuse

problems