Just kidding, they don’t hate me, they hate the Javascript — but who wouldn’t when we keep rebuilding our tooling every few years 🙄

Back in my day…

On the grand scale, reactive frameworks (and by that I mean declarative, rather than imperative, ala Vue, React, Angular, etc) are young — with jQuery around since 2006 and the first of the reactive frameworks taking off in 2012.

We’ve only had a bit more time with these new frameworks than we’ve had without them (yes I’m aware the internet existed before jQuery, but it was a dark time; you should see my first Geocities website).

Then, on the scale of reactive frameworks themselves, Vue is young — with AngularJS taking off in 2012, React in 2014, (Angular again in 2015, this time without the “JS” in its name 👍), and Vue in 2015.

Six years and four frameworks? It’s understandable that not every developer wants (or has the time) to jump on every new Javascript framework that takes the world by storm. Anything we as front-end devs can do to wrap up some of that magic can make the lives of our back-end, QA, support engineers, etc. a little easier.

What’s this history lesson for?

So we as front-end developers might understand the problem I’m tackling in this article — how to build front-end components for others in our organization. We all know how, what, and why we built our own components, modules, classes, etc — but us knowing why we did things doesn’t scale very well beyond, well… an organization of us.

Awkward sentence right? Lots of references to oneself in there — and Skilljar sure isn’t an entire team of front-end developers either. I’m one of two front-end developers working alongside an entire team of back-end devs that may one day have to look at — or worse — implement front end code 😉

So “my” code? That’s also their code.

Just as major languages (Node with NPM, Ruby with Gems, PHP with Composer, Python with PIP, etc) all have packages — reactive frameworks allow us to wrap up complex HTML, CSS, and Javascript into “components” that all developers (back-end, other front-end, junior) can implement without needing to understand the internals.

So how do I make the world a better place then?

At the end of the day the server is spitting out HTML, CSS, and Javascript anyway, so let’s not over complicate this component architecture by reinventing the wheel.

Aka not this — let’s call it the <search-form> example

There’s no way <search-button-icon> rolls up enough functionality to warrant being it’s own component.

There’s no reason to re-invent an entirely new, custom HTML spec for your site; it only makes it impossible for others to reason through all your front-end code — and remember, it’s still all output as HTML, CSS, and Javascript.

Ok… then what SHOULD I do?

What if I told you that your components don’t need to be overly complicated — that you can write impressive, modern components, that can still be easily understood by all?

At Skilljar, for example, we recently launched a new Vue Datatable component that looks a little something like this —