Tuesday July 14, 2020; 11:51 AM EDT
- My email conversation with Allen Wirfs-Brock took an interesting turn. I had written about Really Simple JavaScript, an idea that the language would benefit from removing features. A path well-explored AWB pointed out. #
- In my last post I talked about various programming mottos that help with the design issues JavaScript has encountered. Then AWB commented about the design slogans that guide the evolution of JavaScript.#
- AWB on design slogans#
I’m big fan of design slogans. The one we used in TC39 about not breaking things was “Don’t break the web!” It’s a preservationist perspective. Much of the human digital heritage of the last 30 years and for the foreseeable future is stored as unmaintained web documents. Every breaking change to a web technology (JS, HTML, etc.) is likely to make part of our heritage permanently inaccessible.#- Another slogan we used frequently while I was active in TC39 was “consider the complexity budget.” The idea is that there are limits (whose bounds we don’t know) to the complexity that a programming language can accommodate and still remain useable, learnable, comprehensible, fun, etc. Every time a feature is added or a inconsistency is introduced we use up some of the complexity budget and it can never be recovered. So any such addition limits what do to the language in the future. Each proposed feature needs to be evaluated not just concerning its utility but also whether that utility is worth limiting future language design flexibility.#
- This is something that I worry may have faded as TC39 has grown much larger and participants somewhat more transient. A person who is representing a company in a standards group is most likely to see a positive effect in their performance reviews if they get things added to the standard rather than for helping control complexity.#
- Of course, committee-made decisions are always going to involve disagreements and compromises. In my JavaScript history paper. I have a short section (21.3.5) where I cover the deliberations that resulted in the inclusion of arrow functions.#
- DW on not breaking the web#
Don't break the web. That's a big one. #- That might be the biggest rule of all. For me, all my work really for my whole career has been directed at the web. Not breaking it is the one hope that the work won't have been for naught, as well as the work of millions of other people (of course my work is the most important heh).#
- As you know, Google et al are hell-bent on breaking the web.#
- I wouldn't be surprised if some of the people on your design committee come from companies who agree with Google on breaking the web. So maybe it would be good to have a bigger dialog on what "Don't break the web" really means. Of course the people at Google et al have never responded to anything I've written about that. #
- AWB on not breaking the web#
- Most individuals (even those representing BigCos) who participant in web standards groups generally buy into "don't break the web."#
- But to some, and in particular some big companies, it means don't break the 100 (or 1000) top web sites rather than don't break web legacy.#
- Also some have higher or lower bars for exceptions to that rule.#
- DW on the behavior of guests#
- Thanks Allen for the clarity. I fully agree with all of it. #
- I have another motto that I'd love for the standards designers of today to contemplate. #
- That imho is the single most important thing about the web. It's a platform with no platform vendor. #
Anyone who proposes to work at the center of the tech that implements the web in whatever decade it is should behave as an archeologist, on Mars. You have to wear an attitude of non-contamination. The software version of a hazmat suit. Any little change could have huge unforseen consequences. The web today is so large and diverse, no one can understand all that it does. Whatever new feature is enabled by what you propose to add is worth a small fraction of what has been built on technology you've never seen or understood, or if you do, would consider arcane. You're free to innovate, but you have to do it in a sandbox you create, with rules you define. The web already has a rule.#