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.
A core ‘gov.uk normalised’ set of Sass/CSS files written in a manner that allows re-use and promotion of patterns and components.
In my opinion the front-end resources for gov.uk and any services hosted on gov.uk 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.
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 gov.uk resources were originally written.
Deliverables I’d hope to see
A gov.uk '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).
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.
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.