The golden path

A community upvoting platform that lets us collaborate on best practise in front end code.


For those of you that don't know me, my name is Mairead. I'm a front end developer and I've been doing this for around 15 years. This is my response to the discussions I heard at Edgeconf 2014 in London on March 21st.

The first panel centred around Web components, introduced by Peter Gasston. Like Peter I feel these are essential for the progress of our industry. A later panel member mentioned we are still treading well worn paths. Freeing ourselves from the repetition of the mundane is essential if we are to innovate.

I realise I am preaching to the choir here.

Peter also raised another important point. As a community, how do we address the proliferation of components? Anyone who has ever searched for a jQuery carousel knows what I'm talking about here.

The problem, as I see it, is we have no mechanism for quality control and no platform for promoting the best we have to offer. This is a perennial problem with our development stack.

It was interesting to hear this issue echoed in the build tools panel. Which build tool do you use? Once you've chosen, which plugins will you implement into your workflow? At the moment we have no choice but to suck it and see and this can be a costly exercise. (Only 2556 Grunt plugins to choose from, yay!)

There will always be situations where a total custom build is your best bet but for the other times when 'off the shelf' will do a community upvoting platform that lets us collaborate on best practise in front end code is my suggested approach.

The problem

What it is

What it's not

Next steps

The problem expanded

For those of you still reading or curious to understand the driving focrces behind my idea.

Lack of collaboration

There isn't currently a great deal of opportunity for practioners to collaborate and review code. Our closest solution which supports discourse and debate is stackoverflow.

Increasing complexity

The primary concern levelled at this seems to be that it is raising the barrier of entry for learners. In more practical terms for a development team it makes it harder to leave behind a coherent and maintainable development stack for practioners of all levels and makes hiring more difficult.

Wasted effort

I am tired of rebuilding the same UI componenents repeatedly every time the front end stack moves on. I feel I can keep my skills current but code re-use is essentially a myth to me akin to a golden feathered Hypogriff. I feel this is holding us back.

Proliferation of code

Its natural that everyone wants to make their own code. After all you learn best by doing and that's a good thing, which we should encourage. However we are swimming in a soup of front end plugins, UI components, frameworks and libraries and there is no clear delineation between the good and the bad.

No quality control

At the moment a developer's only clear pointers towards code quality are: reading source, community adoption, recent commit activity and corporate branding. Whilst these are all useful, they each have their limitations and don't necessarily give you full confidence when choosing a solution.


As our industry matures our development practises are solidifying into more complex stacks. I welcome this and I think it's necessary progression but it can be hard to keep a weather eye on every development as they become increasingly diverse.

Re-inventing the wheel

This touches on points 3 and 4. I'm tired of writing the same code, particularly when I know 50 libraries already exist that are basically the same but slightly different in the one crucial way that means I have to write my own, from scratch, again. I think we are making classic mistakes of software development. We are not writing code that is modular, encapsulated and extensible. We need to get better at this without question.

Lack of Re-use

Its got to the point where even code I wrote 6 months ago is obsolete. I don't think I am alone in struggling to keep my front end stack current, re-usable and maintainable. I rarely manage to bring code forward into the next project. We have great tools to support this like Yeoman and Bower but I think we can do more to keep things DRY, particlularly looking forward into the new era of web components.