A couple of good posts on technology agnosticism lately.
Brad Frost says the design system itself is higher level than any particular technology:
… it doesn’t bet the farm on any one technology, the system is able to adapt to inevitable changes to tools, technologies, and trends.
Jonathan Snook thinks Mustache is good choice for otherwise technologically agnostic templating:
I like it because of its simplicity and because it requires the heavy work with the data to be done before it sees a template.
Here’s a slide I used at a recent workshop:
What I was mostly referring to is total HTML agnosticism. It doesn’t matter (to me) where the HTML comes from.
- Did Drupal produce the HTML? Fine.
- Is the HTML in JSX? Fine.
- Is it a Mustache template? Fine.
- Am I editing totally raw HTML like elite hacker? Fine.
- Am I piecing together partials in Nunjucks. Fine.
- Is this a Rails ERB thing? Fine.
What I care about is the final output. Whatever creates the final HTML, it’s on me to make it clean, manageable, accessible, semantic, and performant.
To be clear, I do care about the technology stack. I’m aware of the benefits and tradeoffs of different technologies (or at least I try to be aware, and can do research). It’s just that when I have my front-end developer hat on, the thing I care most about is that final chunk of HTML that hits the browser.
So a minor side note, I bet a nickel knowing HTML well and being a generally agnostic developer will make you more employable.
Been saying this for years. I Also said this about content migration. F whatever it’s stored in whenever possible and just bring in the output (actually goes for so much more than HTML).
This side-lines shortcodes in WP, bb-code in forums (a bunch of PITA things that have bit me over the years). In one piece of software I migrated in 2014 the backend seemed to have mangled dates which looked great in the front-end. The solution was to patch the theme / skin to send the values as they were output straight to a new piece of software. Works wonders and at the end of the day saves brain-ache.
I don’t totally agree with this. At least in the case of a CMS, the organization and UI needs to suit the client/admin to the best it can. In that regard, whether you care if the HTML comes from Drupal or something else, you should for the benefit of the client that pays you.
I’m not understanding the argument. I certainly don’t think you should build UI that doesn’t suit a client.
I think Ryan is saying is that if the client doesn’t like the CMS you chose, it won’t matter what the HTML looks like because they aren’t going to use it. I agree that the CMS decision should be made taking input AND output into consideration. There may need to be some compromises made on one side or the other, but the client will need to be happy with both back and front end.
IMHO the conclusion should be changed to “whatever DOM is created in the browser”. All that JavaScript-Templating-Stuff never creates HTML at all, it’s just Javascript manipulating the DOM (with some exceptions like Server-Side-Prerendering of JSX) There are other cases as well, where the HTML might give a false impression of what the DOM actually looks like. E.g. optional html elements/attributes like “tbody”, which are created automatically in the DOM.
You might find this comment pedantic, but in my experience the difference between DOM and HTML causes a lot of confusion, just because the terms are used incorrectly so often. It’s always the DOM that matters.
I agree 100%. I used to be a full-stack developer and had to care about both back-end and front-end worlds, but now I’m a solely front-end developer and only have to care about my HTML, CSS and JavaScript. It made my life easier and allows me to use best practices, leaving the back-end geniuses to find out how’s best to deliver the data and HTML I give them.
I appreciate articles like this. Having worked on a CMS for over 14 years now, we just recently moved to mustache for the same reasons. Time shows what works and what does not. All templates, configs, displays, graphics, etc… is industry standard as possible.
When I run into a proprietary system that respects my need to move my data/content in and out of a system, control how it’s used and displayed, then I know they have a long term view.
Putting the power and control in the right hands makes everyone’s life easier. Programmers should program, designers should design, and content editors should edit content. This is a simple recipe. (long live simple systems)