From cdd5838d370afad95d142f077df4360997d8785e Mon Sep 17 00:00:00 2001 From: carson Date: Thu, 29 Oct 2020 08:39:47 -0600 Subject: [PATCH] update release version in docs (missed due to bad version number) --- www/essays/complexity-budget.md | 60 ++++++++++++++++++++ www/essays/spa-alternative.md | 99 +++++++++++++++++++++++++++++++++ 2 files changed, 159 insertions(+) create mode 100644 www/essays/complexity-budget.md create mode 100644 www/essays/spa-alternative.md diff --git a/www/essays/complexity-budget.md b/www/essays/complexity-budget.md new file mode 100644 index 00000000..e206968b --- /dev/null +++ b/www/essays/complexity-budget.md @@ -0,0 +1,60 @@ +## Complexity Budgets + +Every application involves managing a complexity budget. A complexity budget can be defined as: + +> An explicit or implicit allocation of complexity across the entire application + +"Complexity" here is defined subjectively (rather than [formally](https://en.wikipedia.org/wiki/Programming_complexity)) +and in [Stewartian Terms](https://en.wikipedia.org/wiki/I_know_it_when_I_see_it). One of the primary jobs of an +application architect is to manage a complexity budget: + +* Decide if a given feature is "worth it" +* Decide if a given implementation is "worth it" +* Add in appropriate system boundaries to limit complexity between component +* Etc. + +Note that attempting to address complexity can, in fact, add more complexity. A good example of this, from experience +is [OSGi](https://en.wikipedia.org/wiki/OSGi), which when applied to an application I was working on, made things +*far more complex*, grinding development to a halt. (This is not to say OSGi is universally bad, just that in this +case, rather than boosting developer productivity, it effectively ended it.) + +A good software architect is someone who manages their software budget effectively, either explicitly or implicitly + +### Complexity Growth + +I assert, without evidence, that Stewartian Application Complexity grows roughly geometrically with the size of an +application. By proper factoring by experience developers, this curve can be held down for quite some time, and this +is one major reason why many good developers are so much more productive than others. + +However, this doesn't change the fact that, somewhere out there, there is a Complexity Wall lurking and, if you aren't +careful you will run into it and grind development to a halt. I have had multiple experiences with this: one day, +inexplicably, development on a system that I was working on went from feeling "large, but managable" to +"this is impossible to deal with". + +### Spending Your Complexity Budget Wisely + +Here are some tools for managing your complexity budget: + +1. Foremost: understanding that there *is* a complexity budget that needs to be managed +1. Saying "No" - probably the easiest, best and, also, hardest tool to use in your battle with complexity +1. Embracing [KISS](https://en.wikipedia.org/wiki/KISS_principle), even if it means admitting you are stupid (It's often very good for an organization if the senior developers can admit they are fallible) +1. Focus your "complexity spend" on the areas where your application is adding value and/or differentiates itself +1. Proper factoring of components - this is an art: Too many components and your complexity explodes. Too few... same. +1. Choosing the proper balance of expressiveness and restrictions for a component + +Unfortunately, experience shows that managing Stewartian Complexity is a subjective endeavor, and many talented and +experience developers will disagree on the proper course of action at a given decision point. + +None the less, by making the concept of a complexity budget explicit, these conversations can be more productive and +ultimately lead to better software outcomes. + +### A Final Note + +All mature applications are complex. + +Finding a new codebase "complex" is *not* an excuse for tearing everything +apart or aggressive refactoring. We must always bear in mind [Chesterton's Fence](https://fs.blog/2020/03/chestertons-fence/). + +If an application is functioning well (or even reasonably) then we should assume that the complexity budget was well +(or reasonably) managed. And we must also bear in mind that, with unfortunate frequency, attempts at addressing complexity +in existing, large applications often fail or, sadly, make things worse. \ No newline at end of file diff --git a/www/essays/spa-alternative.md b/www/essays/spa-alternative.md new file mode 100644 index 00000000..16233097 --- /dev/null +++ b/www/essays/spa-alternative.md @@ -0,0 +1,99 @@ +## An SPA Alternative + +Recently [Tom MacWrite](https://macwright.com) has written a few posts on Single Page Applications and their discontents: + +* [Second-guessing the modern web](https://macwright.com/2020/05/10/spa-fatigue.html) +* [If not SPAs, What?](https://macwright.com/2020/10/28/if-not-spas.html) + +> The emerging norm for web development is to build a React single-page application, with server rendering. The two key +> elements of this architecture are something like: +> +>1. The main UI is built & updated in JavaScript using React or something similar. +>2. The backend is an API that that application makes requests against. +> +> This idea has really swept the internet. It started with a few major popular websites and has crept into corners +> like marketing sites and blogs. + +In these two articles Tom lays out the problem associated with the React/SPA everywhere mindset. If I can summarize +them in one sentence: SPA frameworks tend to be complex, and you don't get a lot of benefit for all that +complexity in many cases. + +### An Alternative + +Tom outlines a few alternatives to the SPA approach in the second article and, I'm happy to say, mentions htmx. However, +he classifies htmx (as well as [Stimulus](https://stimulusjs.org/) and [Alpine.js](https://github.com/alpinejs/alpine/)) +as "progressive-enhancement" libraries. This is a good description, but, at least in the case of htmx, I think there +is a better term to help describe this style of library: *HTML-Centric* (or, perhaps, *Hypertext-Centric*) + +#### HTML-Centric Development + +In HTML-Centric Development, rather than being an afterthought, HTML is embraced as the primary medium of application +development. This is in contrast to most SPA frameworks, where a client-side model & the javascript that manipulates +it is the central focus. + +HTML-Centric Development builds on the original model of the web, as outlined in +[Roy Fielding's PhD dissertation](https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm), describing the web +architecture. In particular, by embracing HTML as a hypertext, you get the benefits of +[REST and HATEOAS](https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm), all without needing to +be an expert in either of those topics. (Recall, Roy was *describing* the web architecture, so the original web was +largely REST-ful, without any particular effort on the part of the original participants) + +By picking HTML-Centric Development, you accrue many benefits: + +* A simpler front end allows you to save your [complexity budget](/essays/complexity-budget) for the back end functionality + that differentiates your application from others. +* You do not face pressure to adopt javascript on the back end "since the front end is written in javascript". This allows + you to use the best backend framework for your particular application. +* With a simpler front end, a "full stack" developer can more easily manage and optimize front-to-back optimization in + your application, leading to much better system tuning +* Your web application is going to have HTML in it anyway, so by maximizing its utility you are boosting the power of + an existing component, rather than adding another layer of complexity between the end user and your application code. +* The stateless network model of the web has proven very resilient and easy to develop for. Many mature and battle-tested + technologies and techniques (e.g. [caching](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching)) exist for + building HTML-based applications. + +#### HTML: The Bad Parts + +With all these benefits of the HTML-Centric model, one may wonder why it has been abandoned (and is often mocked) by +many web developers. At a high level, the answer is: *HTML-Centric applications have historically offered a limited +amount of interactivity when compared with javascript-based applications*. + +This is in large part because HTML is a limited hypertext. In particular: + +* Only `` and `
` can make HTTP requests +* Only `click` & `submit` events can trigger them +* Only GET & POST [HTTP Methods](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods) are widely available +* A request must replace the entire screen, leading to a clunkly and sometimes jarring user experience + +Of course, none of the constraints are inherent in the concept of a hypertext, and [htmx](https://htmx.org) aims to +remove each of them. + +By removing these constraints & completing HTML as a fully-functional, high-powered hypertext, HTML-Centric +applications can compete with SPAs in many application domains, while at the same time accruing the technical +and complexity benefits discussed above. + +### Being Brave, Technically + +Tom closes his first article with this: + +> What if everyone’s wrong? We’ve been wrong before. + +Web development has gone down blind alleys quite a few times: GWT, Java Server Faces, Angular 1, FlatUI, etc. +During the height of the hype cycle around each of these technologies, it was difficult to go against the grain. It is +particularly difficult to do in the technology world , where the being left behind technically is not only a threat to +our ego, but also to our employment. + +> "No One Ever Got Fired For Using React" + +is today's + +> "No One Ever Got Fired For Buying IBM" + +That's a reality that we must accept, even if we don't feel React/etc. aren't appropriate for many (or even most) web +applications being built today. + +However, we are starting + +From the [htmx developer's starter kit](https://twitter.com/htmx_org/status/1306234341056344065): + +![What if?](https://pbs.twimg.com/media/EiCtJYuVoAIK5be?format=png&name=small) \ No newline at end of file