My response to GDS Front-end Survey

Recently GDS (Government Digital Service) asked for feedback from Front-end developers. The bulk of my response came to the question ’Are there any specific improvements you’d like to see in the front-end resources offered by GDS?

In summary I replied

A set of resources that will allow teams to create composible components that can be selected and assembled in various combinations to satisfy specific user needs.

  • New coding standards for HTML, CSS & Javascript.

  • A core ‘ normalised’ set of Sass/CSS files written in a manner that allows re-use and promotion of patterns and components.

  • A core javascript framework that is lite but powerful and forms a basis for modularising javascript.

  • Component/pattern Schemas

At length

In my opinion the front-end resources for and any services hosted on should be refactored due to an evolving set of needs and use cases.

I’m not saying existing sites should rewrite their markup immediately but there is technical debt to pay and as soon as possible I’d hope new services could be writing against a new and improved set of code standards and current services could have a plan to refactor.

What exists is clearly a product of it’s time, that has grown organically to address various needs and has served government sites and services well until now.

However in my opinion, the markup, css and javascript are not suited to a growing set of distributed teams wanting/needing to share assets, patterns and resources.

I’m hoping that as part of GDS’s remit they can form code standards and assets that will be just enough to enable teams/departments to benefit without being too prescriptive as to hinder teams meeting the user needs their research is showing them.

In other words, enable us to be 'consistent but not uniform’ more easily. Our industry has developed more mature practices for this in the time that current resources were originally written.

Deliverables I’d hope to see

  • A set of solid CSS, Javascript and HTML coding standards formed with the general capability of government front-end teams in mind. At the same time centred around the notion that anything a front-end developer writes could be adapted with minimal effort and promoted to a global/resource module and used elsewhere across gov.

  • A 'normalised’ set of styles and resources as a base/foundation for teams to build reusable modular components. Something that allows teams to 'opt in’ to styles as opposed to wrestling with the cascade part of CSS to 'undo’ what is being thrust upon them. (ITCSS / BEM flavoured CSS in other words).

  • I hesitate to use the word 'framework’ but a basis for quickly adding javascript to services. A simple but powerful way of attaching behaviour to views/components that is based on standards that can be linted and tested.

The above deliverables should provided in as universal a way as possible. I’ve had interesting discussions on internal mailing lists about the pros and cons of centrally serving front-end assets, I’m of the opinion that done in the right way that could work well but I also appreciate the single point of failure argument and that of not wanting to be a blocker or potential unwanted master to teams. So lots of research needed on that front.

Thinking & Goals I’d like to see

I think trying to address the 'holy grail’ of front-end development (A single source of truth for HTML across development stacks/environments) (Read great discussion here) is probably futile at the moment in the current browser and technology landscape. (roll on things like web components!)

I’d rather see a standardised way of creating JSON schemas for front-end patterns/components. This would help teams write tests and abstractions in their particular development environments more easily. See excellent project’s like Pattern Kit (Demo of Pattern Kit)

If teams know the scope and naming conventions for components, (in the form of a schema), they can create their own reusable chunks in whatever mark-up or templating language they have the capability for.

Attempting to create ERB, Jinja2, Twig, Freemarker templates, etc, etc for patterns/components is a monstrous task for a central department like GDS to actively maintain, those sorts of things will develop locally and spread federally by themselves with a little encouragement.

Good luck!

I’m slighlty envious of those getting to work on this project, sounds like they’ll have a great time finding what will work best for teams across government. It’s great they are are doing a discovery and involving as many teams and individuals as they can from the start.

I’d also like to point out that I’m far from being critical of the people that wrote the code we are using now. I’m convinced that it did the job they intended it for and did so very well indeed, I just believe that things have changed as a result of their success.

I'm designing this blog "live". I believe that coding in the open promotes sharing, feedback and learning. Occasionally things will change and possibly break but that's ok. You can let me know.

Feel free to browse the source code and commit history