Lit-Html and Responsible Advocacy

If you are a web developer in any respect and have been paying attention to the community and thought leadership from google, you may have heard of a new library they are working on called “lit-html”. It’s being pitched as a more standards-compliant alternative to virtual dom implementations, which uses tagged template string literals in place of jsx/hyperscript.

Now, the idea is perfectly fine. It is compelling to me in general, and to many other developers who have been watching. My problem is not actually with the code or the idea behind the library, it’s with the way that google has been marketing it.

Over the past few weeks, “lit-html” has come up a few times for me within discussions and social media. The first time, it was part of a lengthy twitter thread on web components, touted as a major advantage of using web components over other solutions by google employees who work on polymer. I had never heard of it at this point, and in fact the repo had just been made public a week or two before this interaction. I took a quick scan through the readme, and was wondering why I had not heard of this earlier. Then, about 2/3 of the way down the lengthy readme, after all the documentation, I noticed a section entitled “status”. In this section, it clearly stated that lit-html is in early development and is not production ready — it doesn’t work in several major browsers at all, is missing several large chunks of test coverage, and the API may change in ways that will break existing implementations. Ah well. I replied pointing this out, and it was generally ignored.

A month or two later, I was watching the talks from the google chrome developers summit, and noticed there was one on “lit-html”. I checked it out, and it was some serious evangelism. After about a half hour, the talk ended by saying they are working on ie11 support and tests, but want people to try it out. While there, I noticed another major talk from the polymer summit that was about the same. I figured that perhaps it was ready to roll now, but upon returning to the readme and scrolling for a good while, I found the “status” section, which had not changed since I last looked — not production ready. I was a little unhappy about the way it was presented given this enormous caveat, but generally moved on, knowing that I was not going to advocate “trying out” any software that was so far from being production ready.

Now, what put me over the edge was yet another video I saw today in which a couple of extremely intelligent google thought leaders further advocated lit-html. They spoke about how it was better than vdom implementation and would be the next big thing, replacing virtual dom as a method for data binding and templating, since it’s faster and more efficient. After seeing this video, I returned once again to the documentation to see if they had any benchmarking stats. After all, if it is genuinely faster than virtual dom and achieves the same goals, that is a pretty important thing to stay in tune with. I found, once again, the same “not production ready” warning, which has not changed since the first time I checked it out. And after scrolling for a while, I found, buried about 1/3 of the way down the page, the section on performance. This section states that it has not been benchmarked at all. Are you serious?

With Great Power Comes… You Know

So here I am after having encountered advocacy for this library a number of times, at a number of fairly high profile events, encouraging developers to use it and propping it up as faster and better than virtual dom implementations. Yet at the same time, it has not been benchmarked against them, and is marked as clearly not production ready. I can’t see how this is not a harmful way of spreading information to the community. I can easily see a situation where, after seeing multiple big talks about it at google events and high profile developers praising it, a developer would convince their company to use it, only to find that it is broken in major browsers, has incomplete test coverage, is likely to have breaking changes coming down the line soon, and could well be worse performing than vdom, a solution that has been stable for years and is in production in many of the largest sites in the world. And as a manager, I could easily see justification for a hit on that developer’s performance evaluation because of it. But in reality, it’s hard to blame the developer — really, google’s advocacy is to blame in this situation.

So please, both to google and to anyone else, be responsible with your advocacy. If you have some code that is not production-ready, this should be disclosed very clearly, at the very top of your documentation and readmes. It should be clearly and explicitly mentioned in any talks about it, at the beginning and end. And before making assertions about the performance of any tool, for god’s sake, complete your benchmarks. I am all for getting excited about some new experiments, and encouraging people to check it out and experiment, but this must be clearly divided from positioning them for production use.

A Community, Divided

This is the biggest thing, in my opinion, that divides the community around react from the community around google-advocated web components. I am not trying to take sides, and genuinely am invested in both, it’s just a pronounced difference I have noticed after closely following those advocating both sides.

With react, it is very specifically based on a real-world use-case: facebook, the epitome of a massive interactive web application. And as such, their advocacy and metrics are based on much more practical means. For example, with fiber, their most recent major innovation, it was tracked by the website isfibberreadyyet.com, which showed an extensive lists of tests, all of which had to be passed without so much as a warning, before it would be marked ready for use. It was also put to the test on facebook.com pretty extensively before release, ensuring that it was very much production ready, being used in production on one of the world’s largest websites. In talks about react fiber during its development, it was consistently made clear that it is experimental, and it was purposely undocumented, because it was not ready for use. Benchmarking was extensive before release, including clear interactive examples.

Compare this to google’s approach with lit-html, burying the fact that it is broken in several major browsers and has an incomplete test suite after a very complete set of documentation on how to use it. Then encouraging developers to use it in several major talks, as well as not releasing any benchmarks while asserting that it performs better than existing solutions. As much as I truly am interested in this library, I can’t help but to be more skeptical of it because of the irresponsibility here.

We Can Do Better

This goes out to everyone that is working on awesome code and sharing it with the world, or for that matter, working on anything they are sharing with the world. Keep in mind that you are an influencer, no matter how large or small an audience you have, and be responsible. If you spread something that is wrong or inaccurate, people will believe it, and it can actively harm their lives, and unfortunately, most people will not read the docs, or be very skeptical, they will just believe it if it came from a traditionally reliable source (or these days, even if it didn’t 😕).

I have called out Ev Williams before for spreading harmful, imprecise information that could damage peoples’ relationships with their children. Now I am calling out Google Developers for irresponsibly promoting an un-benchmarked, beta-quality piece of software to tens of thousands of developers who don’t realize that it’s not production ready. And to anyone else reading, remember that you are a brilliant, shining, influential star, so make sure that you are careful and thorough with the things you put out so that they are helping people and making their lives better, instead of the opposite.