I argue that there has never been a more promising time for developing fruitful new notations.
Some, considering the enormous success of modern LLMs in solving increasingly complex “problems” – in terms of translating a verbal or pictorial design specification into code – means programming is now a “solved” problem. They imagine a future where humans no longer need to understand or write code.
I believe this is wrong on several accounts.
[Read More]
Or – “Evading Gilad’s Comparison”.
A 2014 posting of Gilad Bracha’s, A DOMain of shadows, has prompted a lot of thought over the years. I refer to it in passing in last month’s On UI as Code but this week a line of argument became a bit clearer on how the comparison in the posting might be dodged.
Gilad’s note is about the design tension constantly pushing complexity into any purportedly “simple” user-facing language, that we might call a DSL.
[Read More]
UI as Code as a named slogan originated in the context of Dart’s Flutter UI toolkit created by Google. It is centrally described by Bob Nystrom in this thoughtful posting Marking Dart a Better Language for UI. I see it as part of a wider trend in many environments to express designs in general-purpose programming language code rather than configuration languages with less expressive power. For example, ESLint’s flat config system introduced in 2022 moves its previous JSON-based linting configuration into JavaScript code.
[Read More]
A recent posting Why the Latest JavaScript Frameworks Are a Waste of Time sparks a short train of thought. As well as the characteristically disrespectful tone of discussion that technical people often adopt, and the suggestion, contrary to my speculations looking at DOM reconciliation, that people really do use low-level benchmarks when choosing frameworks, is the notion of frameworks contributing to development speed. One commentor invites us to watch him against the clock to implement a front end in Svelte rather than React.
[Read More]
Since the Infusion 6 renderer is close to being a reality, it is time to understand the characteristics of some of the various DOM reconciliation algorithms out there.
Could we do without a virtual DOM entirely? To start with is the question of whether we even really want one at all — the classic Svelte Virtual DOM is pure overhead post has been though its various hype cycles but 7 years later the majority of frameworks out there still have one so the consequences are clearly not as clear-cut as the argument would have it.
[Read More]