HTML and the DOM

Peter Paul Koch (PPK) is on a roll with his recent postings and is taking some flack for it. Some of it justified as his recent articles seem to encourage discussion and it seems to be working. His follow up templating article brings home that Front-end is hard and we still don’t have all the tools in place to make it work for large scale and high performance websites.

The fact is that even with the recent explosion of front-end orientated tooling and technologies the front-end remains fragile. This fragility is apparent when you’re developing within two extremes of UI generation.

  1. No separation, all HTML creation and changes are done on the server
  2. Complete separation, all HTML creation and DOM manipulation and are done in the browser

The third option that PPK seems to suggest and one I’d subscribe to is that all initial HTML creation happens on the server and after the all content has loaded some DOM changes should happen in the browser. The pain is deciding where to make the cut. Who gets what? Should forms be forms or should we abstract them away into a XMLHttpRequest? How little SEO do we provide and how much accessibility can we afford?

What we’re seeing is that a lot has been done to make content machine readable and user accessible after it has loaded. So it’s not entirely unreasonable to state that changes after the content has loaded should always be handled in the browser when we don’t have the option to always handle HTML on the server.

Server only HTML isn’t painless

Making a change to a form can take months (that’s not a joke) and the costs become prohibitive to making any changes. However, we must allow for changes. When a web backend is hit by high volume traffic it still has to deal with all the HTML rendering, DOM manipulation and the page reloads these changes require. There is nowhere to hide, you can’t offload these processes and you must scale up on your hardware. Offloading some of this work to the browser is appealing from both an engineering and economic point of view.

However, offloading all the HTML creation to the browser seems equally draconian to me. I won’t go into why but PPK’s Angular post covers some of that. Generating HTML entirely on either the server or the browser is effectively a non-starter, a waste of time and money.

Handling all HTML on the server and all DOM manipulation in the browser is tricky because you don’t want to duplicate all your efforts on both platforms with their own codebases. It would be nice if they could share and currently the only way to do that is with JavaScript. This were the wheels start to come off as there are no solutions, that I know of, to make this happen in a relatively painless way. That’s not going to stop me trying because we need a cost-effective, maintainable, scalable and performant web for users and devices* alike. To make that happen we need both the server and the browser to bring our UI’s to fruition.

Next entry: Flipboard flips, and so does the web.
Previous entry: CSS abstraction