Data outlasts Code, yet Code keeps winning

My recent End of Localhost piece on Hacker News came with the usual dash of HN criticism devolving into blaming beginners for not knowing the same parts of the stack that they consider mandatory:

The perennial debate between gatekeeping vs emphasis on fundamentals aside, I was reflecting that the whole situation with [ANGULAR/REACT/SVELTE/etc aka FRAMEWORK YOU BLAME FOR ALL EVIL, hence forth known as $FRAMEWORK] vs The Web Platform™ arose out of multiple constraints:

• The failure of HTML imports to offer sufficient componentization compared to $FRAMEWORK
• The failure of Web Components to server-side-render and progressively upgrade compared to $FRAMEWORK
• Employers severely overindexing on interviewing for JS skills over HTML, leading bootcamps/other professional prep institutions to respond in kind
• The lack of the Web Platform having approachable, friendly, non-judgemental-or-yelly-graybeard teachers/advocates

Analysing the causes of a problem (if this can be called a problem - it is in the small, but not in the large, and yet may be a problem in the very large - there is a more complex trinomial here than either side would have you believe) is a different matter than solving the problem. It may well be that it cannot be solved.

I remember a (since deleted?) comment from Guillermo Rauch, observing that JS build tools (which do many jobs, as I’ve documented) are a Pandora’s Box - once opened, it cannot be closed.

I think it is the same for HTML vs JS. We opened the box, and moved stuff from data (“dumb” HTML) to code (“smart” JS), and once we saw how much control code gave us, we were never going to go back to just writing data again. Even the LISPy projects behave more like “data as code” rather than “code as data”.

The fundamental theorem of software engineering goes: “We can solve any problem by introducing an extra level of indirection.” When you can reflect, metaprogram, optimize, cross-compile and do basically whatever you want in code, it’s hard to give that power up in just data.

This is, to me, a more profound and interesting frontier than the distinction between “imperative” code and “declarative” code - or “sync” and “async” code - you can easily move the barriers between those, because at the end of the day, you’re still dealing with code at the end of the day, which is maximally expressive.

Whereas dealing with data involves interfaces, standards, and encoding a huge number of tradeoffs (different dimensions of performance, learnability, flexibility, futureproofing, etc) to achieve a Narrow Waist.

Aside: there is a related Torvalds quote here: ”Bad programmers worry about the code. Good programmers worry about data structures and their relationships.”. I have also personally observed that Data Structures are more important than Algorithms (explanation).

The cynical subtext behind the Third Age of JavaScript is that every 10 years a new generation of devs come along and rewrite the universe in order to make their name - React is as old as jQuery was when React itself first came out, and there are a slew of attempts at making the next generation framework. $FRAMEWORK is likely to last for a long time, but nobody spending all day writing thousands of lines of $FRAMEWORK all day long is under any illusion that any of this code will still run after we’re gone.

But data - you can put data into the literal Arctic, and 1000 years later, as long as the archaeologists of the future have the right “decoder ring” (understanding the schema/having a standards compliant interpreter), they’ll be able to get out what we put in.

I could pad out this essay with a longer discussion on the nuances of getting the “data” right, and the many redeeming qualities of code, but I have no conclusion on this beyond a sad observation that all the work we do in code is far more likely to be shorter lived than a single good decision that we have in data.