diff --git a/www/content/essays/10-tips-for-SSR-HDA-apps.md b/www/content/essays/10-tips-for-SSR-HDA-apps.md index fb0937d4f..58ace2ea4 100644 --- a/www/content/essays/10-tips-for-SSR-HDA-apps.md +++ b/www/content/essays/10-tips-for-SSR-HDA-apps.md @@ -6,8 +6,8 @@ description = """\ architectural advantages.""" date = 2022-06-13 updated = 2023-06-13 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/a-real-world-nextjs-to-htmx-port.md b/www/content/essays/a-real-world-nextjs-to-htmx-port.md index 40add19de..06be6b0e4 100644 --- a/www/content/essays/a-real-world-nextjs-to-htmx-port.md +++ b/www/content/essays/a-real-world-nextjs-to-htmx-port.md @@ -6,8 +6,8 @@ description = """\ about modern web frameworks.""" date = 2024-11-07 updated = 2024-11-07 +authors = ["Pouria Ezzati"] [taxonomies] -author = ["Pouria Ezzati"] tag = ["posts"] +++ diff --git a/www/content/essays/a-real-world-react-to-htmx-port.md b/www/content/essays/a-real-world-react-to-htmx-port.md index a68eb88e6..b8a453d18 100644 --- a/www/content/essays/a-real-world-react-to-htmx-port.md +++ b/www/content/essays/a-real-world-react-to-htmx-port.md @@ -1,14 +1,14 @@ +++ title = "A Real World React -> htmx Port" description = """\ - David Guillot at Contexte gave what we are calling "The Mother of All htmx Demos" at DjangoCon 2022. This essay \ + David Guillot at Contexte gave what we are calling 'The Mother of All htmx Demos' at DjangoCon 2022. This essay \ summarizes this real-world case study of replacing React with htmx in a SaaS product, demonstrating significant \ improvements in code size, performance, and development team efficiency through the adoption of a hypermedia-driven \ architecture.""" date = 2022-09-29 updated = 2022-10-15 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/a-real-world-wasm-to-htmx-port.md b/www/content/essays/a-real-world-wasm-to-htmx-port.md index 4ec139295..8922fc077 100644 --- a/www/content/essays/a-real-world-wasm-to-htmx-port.md +++ b/www/content/essays/a-real-world-wasm-to-htmx-port.md @@ -6,8 +6,8 @@ description = """\ complexity and improved development efficiency.""" date = 2025-01-10 updated = 2025-01-10 +authors = ["Joe Fioti"] [taxonomies] -author = ["Joe Fioti"] tag = ["posts"] +++ diff --git a/www/content/essays/a-response-to-rich-harris.md b/www/content/essays/a-response-to-rich-harris.md index f18795c18..ec36c76a8 100644 --- a/www/content/essays/a-response-to-rich-harris.md +++ b/www/content/essays/a-response-to-rich-harris.md @@ -1,14 +1,14 @@ +++ title = "A Response To "Have Single-Page Apps Ruined the Web?"" description = """\ - In this essay, Carson Gross gives an analysis of Rich Harris's talk "Have Single-Page Apps Ruined the Web?", \ + In this essay, Carson Gross gives an analysis of Rich Harris's talk 'Have Single-Page Apps Ruined the Web?', \ exploring the debate between Single-Page Applications (SPAs) and Multi-Page Applications (MPAs). Carson examines \ Harris's criticisms of both approaches and proposes hypermedia-oriented solutions using htmx, while discussing the \ broader implications for web development architecture and the future role of JavaScript in web applications.""" date = 2021-12-24 updated = 2022-05-27 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/alternatives.md b/www/content/essays/alternatives.md index 5bcc70a16..c7e8fe48a 100644 --- a/www/content/essays/alternatives.md +++ b/www/content/essays/alternatives.md @@ -7,8 +7,8 @@ description = """\ hypermedia-driven application development options beyond htmx.""" date = 2025-01-12 updated = 2024-01-12 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/another-real-world-react-to-htmx-port.md b/www/content/essays/another-real-world-react-to-htmx-port.md index 44b359a5a..37c79f4f6 100644 --- a/www/content/essays/another-real-world-react-to-htmx-port.md +++ b/www/content/essays/another-real-world-react-to-htmx-port.md @@ -6,8 +6,8 @@ description = """\ how content-focused web applications can benefit from a hypermedia architectural approach.""" date = 2023-09-20 updated = 2023-09-20 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/architectural-sympathy.md b/www/content/essays/architectural-sympathy.md index 8df4af196..2da02e342 100644 --- a/www/content/essays/architectural-sympathy.md +++ b/www/content/essays/architectural-sympathy.md @@ -1,19 +1,25 @@ +++ title = "Architectural Sympathy" +description = """\ + In this essay, Carson Gross explores architectural sympathy as a software design principle where new software adopts \ + and conforms to the architectural patterns of existing systems. Carson examines the application of architectural \ + sympathy in web development through htmx, its advantages and tradeoffs, and drawing parallels with medieval \ + cathedral construction to illustrate the balance between innovation and coherent design.""" date = 2023-04-06 updated = 2023-04-06 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] +tag = ["posts"] +++ # Mechanical Sympathy & Architectural Sympathy -> You don’t have to be an engineer to be be a racing driver, but you do have to have Mechanical Sympathy. +> You don’t have to be an engineer to be a racing driver, but you do have to have Mechanical Sympathy. _-Jackie Stewart, racing driver_ -The term "mechanical sympathy" was originally coined by Jackie Steward to capture a characteristic +The term "mechanical sympathy" was originally coined by Jackie Stewart to capture a characteristic of race car drivers, who needed a deep and intuitive understanding of how a race car worked in order to get the best possible performance out of the vehicle. diff --git a/www/content/essays/codin-dirty.md b/www/content/essays/codin-dirty.md index 56956981e..cf61fa2ca 100644 --- a/www/content/essays/codin-dirty.md +++ b/www/content/essays/codin-dirty.md @@ -1,9 +1,14 @@ +++ title = "Codin' Dirty" +description = """\ + In this article, Carson Gross discusses an alternative approach to software development that challenges the \ + principles outlined in 'Clean Code.' Carson advocates for allowing larger functions in certain cases, preferring \ + integration tests over unit tests, and minimizing the number of classes and interfaces. He shares examples from \ + successful software projects that demonstrate these practices can lead to maintainable, high-quality code.""" date = 2024-11-24 updated = 2024-11-24 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/complexity-budget.md b/www/content/essays/complexity-budget.md index 6010c4c9e..96f5fb6ea 100644 --- a/www/content/essays/complexity-budget.md +++ b/www/content/essays/complexity-budget.md @@ -1,9 +1,13 @@ +++ title = "Complexity Budget" +description = """\ + In this essay, Carson Gross explores the concept of a complexity budget in software development. He discusses how \ + managing complexity across applications is a critical responsibility for architects and developers, while examining \ + strategies for effective complexity management and the challenges that arise when attempting to reduce it.""" date = 2020-10-29 updated = 2024-01-21 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/does-hypermedia-scale.md b/www/content/essays/does-hypermedia-scale.md index 304db83ca..87e444830 100644 --- a/www/content/essays/does-hypermedia-scale.md +++ b/www/content/essays/does-hypermedia-scale.md @@ -1,9 +1,15 @@ +++ title = "Does Hypermedia Scale?" +description = """\ + In this essay, Carson Gross examines whether Hypermedia-Driven Applications (HDAs) can effectively scale across \ + different dimensions of software development, including system nodes, application performance, feature count, \ + feature complexity, and team size. The analysis explores both the strengths and limitations of hypermedia in each \ + context, ultimately demonstrating that HDAs can scale well in most scenarios while acknowledging specific challenges \ + with complex client-side features.""" date = 2023-11-06 updated = 2023-11-06 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ @@ -20,7 +26,7 @@ First of all, let's define the term "scaling" and then the contexts that word ca context, scaling typically means the ability of the software to handle "larger" things. Those things can be: * More nodes in a general [system](https://hypermedia.systems) -* More user requests (scaling your individual applications performance) +* More user requests (scaling your individual application's performance) * More features (scaling your codebase) * More _complex_ features * More developers (scaling your team size) diff --git a/www/content/essays/future.md b/www/content/essays/future.md index eb5f3ec9e..0c1dbb775 100644 --- a/www/content/essays/future.md +++ b/www/content/essays/future.md @@ -1,9 +1,13 @@ +++ title = "The future of htmx" +description = """\ + In this essay, Carson Gross and Alex Petros discuss htmx's future direction and philosophy. They explain how the \ + project aims to emulate jQuery's success through API stability, minimal feature additions, and quarterly releases \ + while continuing to promote hypermedia-driven development and support the broader web development ecosystem.""" date = 2025-01-01 -updated = 2024-01-01 +updated = 2025-01-01 +authors = ["Carson Gross", "Alex Petros"] [taxonomies] -author = ["Carson Gross", "Alex Petros"] tag = ["posts"] +++ diff --git a/www/content/essays/hateoas.md b/www/content/essays/hateoas.md index 27961df57..2a37472a8 100644 --- a/www/content/essays/hateoas.md +++ b/www/content/essays/hateoas.md @@ -1,9 +1,14 @@ +++ title = "HATEOAS" +description = """\ + In this essay, Carson Gross explores HATEOAS (Hypermedia as the Engine of Application State), explaining how it \ + enables REST APIs through hypermedia responses and contrasting it with modern JSON-based APIs. Using clear HTML \ + examples, Carson demonstrates how HATEOAS allows clients to discover available actions dynamically through \ + hypermedia rather than requiring prior knowledge of the API interface.""" date = 2021-10-16 updated = 2022-02-06 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] [extra] show_title = false diff --git a/www/content/essays/how-did-rest-come-to-mean-the-opposite-of-rest.md b/www/content/essays/how-did-rest-come-to-mean-the-opposite-of-rest.md index 3de4773b5..45168b130 100644 --- a/www/content/essays/how-did-rest-come-to-mean-the-opposite-of-rest.md +++ b/www/content/essays/how-did-rest-come-to-mean-the-opposite-of-rest.md @@ -1,9 +1,14 @@ +++ title = "How Did REST Come To Mean The Opposite of REST?" +description = """\ + In this article, Carson Gross explores how the term REST (Representational State Transfer) evolved to mean nearly \ + the opposite of its original definition in modern web development. It traces how REST, originally defined by Roy \ + Fielding to describe the web's architecture of hypermedia-driven interactions, came to be widely misused as a term \ + for JSON-based APIs that lack the key hypermedia constraints that define true REST architectural style.""" date = 2022-07-18 updated = 2022-11-26 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ @@ -49,7 +54,7 @@ Only a few obstinate folks grumble: but these JSON APIs aren't RESTful! In this post, I'd like to give you a [brief, incomplete and mostly wrong](https://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html) history of REST, and how we got to a place where its meaning has been nearly perfectly inverted to mean what REST was -original contrasted with: RPC. +originally contrasted with: RPC. ## Where Did REST Come From? diff --git a/www/content/essays/htmx-sucks.md b/www/content/essays/htmx-sucks.md index d6065ea52..7c1939866 100644 --- a/www/content/essays/htmx-sucks.md +++ b/www/content/essays/htmx-sucks.md @@ -1,9 +1,14 @@ +++ title = "htmx sucks" +description = """\ + This article provides a critical analysis of htmx, a web development library, explaining why the author believes it \ + represents a problematic approach to modern web development due to its outdated coding practices, lack of build \ + tools, absence of TypeScript support, and reliance on HTML-based architecture, while also questioning the \ + professionalism of its creator.""" date = 2024-02-01 updated = 2024-04-01 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/hypermedia-apis-vs-data-apis.md b/www/content/essays/hypermedia-apis-vs-data-apis.md index 6d31233e2..02fc6e2ba 100644 --- a/www/content/essays/hypermedia-apis-vs-data-apis.md +++ b/www/content/essays/hypermedia-apis-vs-data-apis.md @@ -1,9 +1,14 @@ +++ title = "Hypermedia APIs vs. Data APIs" +description = """\ + In this essay, Carson Gross explores the fundamental differences between hypermedia APIs and data APIs, He explains \ + how hypermedia APIs, which return HTML over HTTP, can embrace frequent changes due to their self-describing nature, \ + while data APIs require more stability and versioning to avoid breaking client code. Carson argues that these \ + distinct characteristics should inform different design approaches for each type of API.""" date = 2021-07-17 updated = 2022-04-07 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/hypermedia-clients.md b/www/content/essays/hypermedia-clients.md index 136d9d4f8..58a457c79 100644 --- a/www/content/essays/hypermedia-clients.md +++ b/www/content/essays/hypermedia-clients.md @@ -1,9 +1,14 @@ +++ title = "Hypermedia Clients" +description = """\ + In this essay, Carson Gross explores the critical but often overlooked role of hypermedia clients in REST \ + architectures. He explains why adding hypermedia controls to JSON APIs is insufficient for true RESTful systems \ + without proper client implementation. Carson examines the challenges of building hypermedia clients and argues that \ + web browsers remain the most practical choice for hypermedia-driven applications.""" date = 2023-01-28 updated = 2023-01-29 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/hypermedia-driven-applications.md b/www/content/essays/hypermedia-driven-applications.md index c7d102469..714fa2bb8 100644 --- a/www/content/essays/hypermedia-driven-applications.md +++ b/www/content/essays/hypermedia-driven-applications.md @@ -1,9 +1,13 @@ +++ title = "Hypermedia-Driven Applications" +description = """\ + In this essay, Carson Gross explains the Hypermedia-Driven Application (HDA) architecture, which combines the \ + simplicity of traditional Multi-Page Applications with the enhanced user experience of Single-Page Applications by \ + extending HTML infrastructure through declarative syntax and hypermedia-based server interactions.""" date = 2022-02-06 updated = 2022-10-18 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/hypermedia-friendly-scripting.md b/www/content/essays/hypermedia-friendly-scripting.md index 112bfc2cf..b25c3ccec 100644 --- a/www/content/essays/hypermedia-friendly-scripting.md +++ b/www/content/essays/hypermedia-friendly-scripting.md @@ -1,9 +1,15 @@ +++ title = "Hypermedia-Friendly Scripting" +description = """\ + In this essay, Carson Gross discusses hypermedia-friendly scripting approaches for web applications, explaining how \ + to incorporate JavaScript while maintaining REST architectural principles and HATEOAS (Hypermedia as the Engine of \ + Application State). Carson outlines key guidelines for using scripting to enhance hypermedia-driven applications \ + without undermining their fundamental REST-ful architecture, covering topics like client-side state management, \ + event communication, and the islands architecture pattern.""" date = 2022-11-17 updated = 2022-11-29 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/hypermedia-on-whatever-youd-like.md b/www/content/essays/hypermedia-on-whatever-youd-like.md index abe379457..71bfac6bb 100644 --- a/www/content/essays/hypermedia-on-whatever-youd-like.md +++ b/www/content/essays/hypermedia-on-whatever-youd-like.md @@ -1,8 +1,13 @@ +++ title = "Hypermedia On Whatever you'd Like" +description = """\ + In this essay, Carson Gross explores the concept of 'The HOWL Stack' (Hypermedia On Whatever you'd Like) and argues \ + that using a hypermedia-driven approach for web applications allows developers to choose their preferred server-side \ + technology, freeing them from the pressure to use JavaScript throughout their entire stack while maintaining modern \ + web functionality through HTML and hypermedia enhancements.""" date = 2023-05-23 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/interviews/chris_wanstrath.md b/www/content/essays/interviews/chris_wanstrath.md index 255d8d930..88d993cdc 100644 --- a/www/content/essays/interviews/chris_wanstrath.md +++ b/www/content/essays/interviews/chris_wanstrath.md @@ -1,15 +1,19 @@ +++ title = "An interview with Chris Wanstrath aka @defunkt, Creator of pjax" +description = """\ + This article features an in-depth interview with Chris Wanstrath (defunkt), the co-founder of GitHub and creator of \ + pjax, where he discusses his journey from early web development to creating pjax, an innovative JavaScript library \ + that helped bridge the gap between traditional web navigation and dynamic content loading.""" date = 2025-01-27 updated = 2025-01-27 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ I'm very excited to be able to interview @defunkt, the author of [pjax](https://github.com/defunkt/jquery-pjax), an early hypermedia-oriented javascript library that served as an inspiration for intercooler.js, which later became -htmx. He's done a few other things too, like co-founding github, but in this interview I want to focus on pjax, how it +htmx. He's done a few other things too, like co-founding GitHub, but in this interview I want to focus on pjax, how it came to be, what influenced it and what it in turn influenced. Thank you for agreeing to an interview @defunkt! diff --git a/www/content/essays/interviews/henning_koch.md b/www/content/essays/interviews/henning_koch.md index c326cd6d7..7a502596a 100644 --- a/www/content/essays/interviews/henning_koch.md +++ b/www/content/essays/interviews/henning_koch.md @@ -1,9 +1,14 @@ +++ title = "An interview with Henning Koch, Creator of Unpoly" +description = """\ + In this interview with Henning Koch, creator of Unpoly, he discusses his journey from managing a Rails consultancy \ + to developing this hypermedia-oriented JavaScript library. Koch shares insights on progressive enhancement, the \ + challenges of Single Page Applications, and why hypermedia approaches often deliver better results for typical web \ + applications.""" date = 2022-06-13 updated = 2023-06-13 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ @@ -14,7 +19,7 @@ Thank you for agreeing to an interview! **Q**: To begin with, why don't you give the readers a bit of your background both professionally & technically: -> Sure! I'm currently head of development at [makandra](https://makandra.de/en), a Ruby on Rails consultancy I co-founded back in 2009, after many years of freelancing as a web developer. So my context is working on many different web apps concurrently, and maintaining those for a long time. On a given week we probably touch 10+ projects, for industries ranging from education to automative to cyber security. Unpoly is an extraction from patterns that we saw repeating over and over in client projects. +> Sure! I'm currently head of development at [makandra](https://makandra.de/en), a Ruby on Rails consultancy I co-founded back in 2009, after many years of freelancing as a web developer. So my context is working on many different web apps concurrently, and maintaining those for a long time. On a given week we probably touch 10+ projects, for industries ranging from education to automotive to cybersecurity. Unpoly is an extraction from patterns that we saw repeating over and over in client projects. **Q**: When I created intercooler.js a big part of it was my unwillingness to deal with the popular SPA libraries of the time (Angular & ExtJS, for example). Did Unpoly have a similar history? @@ -30,7 +35,7 @@ a Rails developer too. Did that influence your approach to Unpoly? > > Some recent Rails mottos are "Compress the complexity of modern web apps" and "The one person framework". With my other responsibility at makandra being training young developers, that resonates with me a lot. I really care about maintaining a stack where a single person can be a full-stack developer and deliver good results consistently. > -> Also, as a Rubyist, I have an excessive obsession with the ergonomics and aesthetics of code *as it is invoked*. I stress a lot over how a feature looks when it is used in client code. When a small ideas takes a disproportionate amount of code, this is something I lose sleep over. +> Also, as a Rubyist, I have an excessive obsession with the ergonomics and aesthetics of code *as it is invoked*. I stress a lot over how a feature looks when it is used in client code. When a small idea takes a disproportionate amount of code, this is something I lose sleep over. **Q**: Did you think much about hypermedia, REST, etc. when you were building Unpoly? Do you find that stuff useful? Interesting? diff --git a/www/content/essays/interviews/makinde_adeagbo.md b/www/content/essays/interviews/makinde_adeagbo.md index bd61dda7f..0cc619bae 100644 --- a/www/content/essays/interviews/makinde_adeagbo.md +++ b/www/content/essays/interviews/makinde_adeagbo.md @@ -1,9 +1,13 @@ +++ title = "An interview with Makinde Adeagbo, Creator of Primer" +description = """\ + In this interview with software engineer Makinde Adeagbo, he discusses his role in creating Primer, a \ + hypermedia-oriented JavaScript library used at Facebook in the 2000s, and shares insights about building developer \ + tools, Facebook's evolution, and the cyclical nature of web development approaches.""" date = 2025-01-27 updated = 2025-01-27 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/interviews/mike_amundsen.md b/www/content/essays/interviews/mike_amundsen.md index 3ddfd5bee..ff80819ea 100644 --- a/www/content/essays/interviews/mike_amundsen.md +++ b/www/content/essays/interviews/mike_amundsen.md @@ -1,9 +1,13 @@ +++ title = "An interview with Mike Amundsen, Author of 'RESTful Web APIs'" +description = """\ + In this in-depth interview, Mike Amundsen, a leading expert on REST and hypermedia, discusses the evolution of \ + hypermedia technologies, highlights unsung pioneers like Paul Otlet, and shares insights on the future of hypermedia \ + in enterprise systems and machine-to-machine interactions.""" date = 2025-01-27 updated = 2025-01-27 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ @@ -78,7 +82,7 @@ disagree with in it? > example but it is just that; an example of his approach to information network design. There have been other designs > from the same school (UC Irvine) including Justin Erenkrantz’s Computational > REST ([CREST](https://www.erenkrantz.com/CREST/)) and Rohit Kare’s Asynchronous REST (A-REST). These were efforts that -> got the message of Fielding: “Let’s design networked software systems\! +> got the message of Fielding: “Let’s design networked software systems\!” > > But that is much more abstract work that most real-world developers need to deal with. They have to get code out the > door and up and running quickly and consistently. Fielding’s work, he admitted, was on @@ -137,7 +141,7 @@ older ideas that are worth looking at again? > API-era has, in some ways, distracted us from the power of hypermedia controls as a design element for > service-to-service interactions. > -> While I think Nelson, Beners-Lee and others have done a great job of laying out the possibilities for human-to-machine +> While I think Nelson, Berners-Lee and others have done a great job of laying out the possibilities for human-to-machine > interaction, I think we’ve lost sight of the possibilities hypermedia gives us for machine-to-machine interactions. I am > surprised we don’t have more hypermedia-driven workflow systems available today. > diff --git a/www/content/essays/is-htmx-another-javascript-framework.md b/www/content/essays/is-htmx-another-javascript-framework.md index 88a09db8c..1138f0733 100644 --- a/www/content/essays/is-htmx-another-javascript-framework.md +++ b/www/content/essays/is-htmx-another-javascript-framework.md @@ -1,8 +1,14 @@ +++ title = "Is htmx Just Another JavaScript Framework?" +description = """\ + Alexander Petros give a thoughtful exploration of htmx's relationship to traditional JavaScript frameworks, \ + examining how its HTML-first approach and narrow focus on network requests sets it apart. He argues that while htmx \ + exhibits framework-like qualities in how it shapes application architecture, its deep integration with HTML's native \ + capabilities and lack of dependencies makes it a more sustainable choice for building long-lasting web \ + applications.""" date = 2024-01-10 +authors = ["Alexander Petros"] [taxonomies] -author = ["Alexander Petros"] tag = ["posts"] +++ diff --git a/www/content/essays/locality-of-behaviour.md b/www/content/essays/locality-of-behaviour.md index 209057fe8..4ce239c05 100644 --- a/www/content/essays/locality-of-behaviour.md +++ b/www/content/essays/locality-of-behaviour.md @@ -1,9 +1,14 @@ +++ title = "Locality of Behaviour (LoB)" +description = """\ + Carson Gross explores the Locality of Behaviour (LoB) principle, which emphasizes making the behavior of code units \ + obvious on inspection to enhance maintainability. He discusses the tradeoffs between LoB and other software design \ + principles like DRY and SoC, offering insights on balancing clarity, abstraction, and maintainability in modern \ + development.""" date = 2020-05-29 updated = 2023-01-20 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/lore.md b/www/content/essays/lore.md index 0c758ca4b..c1e722692 100644 --- a/www/content/essays/lore.md +++ b/www/content/essays/lore.md @@ -1,9 +1,14 @@ +++ title = "htmx lore" +description = """\ + Carson Gross explores the fascinating lore of htmx, from its playful community memes like "It's So Over/We're \ + So Back" and "Laser Eye Horse" to humorous controversies such as the "Microsoft Purchase \ + Rumor" and the htmx/intercooler.js feud. This essay dives into the vibrant culture, iconic moments, and \ + lighthearted chaos surrounding htmx.""" date = 2024-12-17 updated = 2024-12-17 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ @@ -13,7 +18,7 @@ tag = ["posts"] For better or [for worse](https://x.com/IroncladDev/status/1866185587616596356), htmx has collected a lot of lore, mainly around [the twitter account](https://twitter.com/htmx_org). -Here are some explainations. +Here are some explanations. ## It's So Over/We're So Back @@ -98,7 +103,7 @@ People often [call htmx a framework](@/essays/is-htmx-another-javascript-framewo ## "man" -A common [one word response](https://x.com/search?q=%22man%22%20from%3Ahtmx_org&src=typed_query&f=live) when i don't feel like +A common [one word response](https://x.com/search?q=%22man%22%20from%3Ahtmx_org&src=typed_query&f=live) when I don't feel like arguing with someone. ## The Le Marquee d'<something> @@ -135,7 +140,7 @@ to htmx come to be enlightened. ## "that's ridiculous" -In [June 2023](https://x.com/htmx_org/status/1807183339222405317), [@srasash](https://twitter.com/srasash) accussed +In [June 2023](https://x.com/htmx_org/status/1807183339222405317), [@srasash](https://twitter.com/srasash) accused htmx of being a government op, the first in many such increasingly ridiculous claims. I typically quote-tweet these claims and point out that ["that's ridiculous"](https://x.com/search?q=%22that%27s%20ridiculous%22%20from%3A%40htmx_org&src=typed_query&f=live) @@ -170,4 +175,4 @@ A common phrase used to [mock people (including ourselves)](https://x.com/search ## Joker/Bane/Skeletor/Thanos, etc. -htmx is a [villian](https://x.com/htmx_org/status/1651698199478796292) in the front-end world, i'm good w/that +htmx is a [villain](https://x.com/htmx_org/status/1651698199478796292) in the front-end world, I'm good w/that diff --git a/www/content/essays/mvc.md b/www/content/essays/mvc.md index f27c7df9f..cf1b9ed47 100644 --- a/www/content/essays/mvc.md +++ b/www/content/essays/mvc.md @@ -1,9 +1,14 @@ +++ title = "Model/View/Controller (MVC)" +description = """\ + Carson Gross give an introduction to the Model/View/Controller (MVC) design pattern and its relevance to modern web \ + development. He explores MVC concepts, its historical adoption in frameworks like Ruby on Rails, and practical \ + examples of its implementation in Python with Flask. Carson explains how separating concerns with MVC can reduce \ + code duplication, support both JSON APIs and hypermedia, and maintain flexibility in application design.""" date = 2024-01-16 updated = 2024-01-16 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/no-build-step.md b/www/content/essays/no-build-step.md index e8fc14f16..4b6dda637 100644 --- a/www/content/essays/no-build-step.md +++ b/www/content/essays/no-build-step.md @@ -1,8 +1,14 @@ +++ title = "Why htmx Does Not Have a Build Step" +description = """\ + In this essay, Alexander Petros explores the reasons why the htmx JavaScript library does not include a build step, \ + detailing the benefits of its simple, dependency-free structure. He highlights the longevity of plain JavaScript, \ + the improved debugging experience, enforced code clarity, and the tradeoffs of avoiding tools like TypeScript or \ + ES6. Alexander also acknowledges the potential limitations of this approach and discusses how these tradeoffs align \ + with htmx's goals of simplicity and developer choice in web development.""" date = 2023-08-19 +authors = ["Alexander Petros"] [taxonomies] -author = ["Alexander Petros"] tag = ["posts"] +++ @@ -15,7 +21,7 @@ The best reason to write a library in plain JavaScript is that it lasts forever. Of course, most people's experience with JavaScript is that it ages like milk. Reopen a node repository after 3 months and you'll find that your project is mired in a flurry of security warnings, backwards-incompatible library "upgrades," and a frontend framework whose cultural peak was the exact moment you started the project and is now widely considered tech debt. Who's to blame for this situation is for someone else to decide, but, in any case, you can eliminate this entire problem class by not having any dependencies beyond the JavaScript runtime. -A popular way to write JavaScript today is compile it from TypeScript (which I will use frequently as an example, because TypeScript is probably the [best reason](https://en.wikipedia.org/wiki/Straw_man#Steelmanning) to use a build system). TypeScript does not run natively in web browsers, so TypeScript code is not protected by [ECMA's](https://developer.mozilla.org/en-US/docs/Glossary/ECMA) fanatical devotion to backwards compatibility. Like any dependency, new major TypeScript versions are not guaranteed to be backwards compatible with the previous ones. They might be! But if they aren't, then you need to do maintenance if you want to use the modern development toolchain. +A popular way to write JavaScript today is to compile it from TypeScript (which I will use frequently as an example, because TypeScript is probably the [best reason](https://en.wikipedia.org/wiki/Straw_man#Steelmanning) to use a build system). TypeScript does not run natively in web browsers, so TypeScript code is not protected by [ECMA's](https://developer.mozilla.org/en-US/docs/Glossary/ECMA) fanatical devotion to backwards compatibility. Like any dependency, new major TypeScript versions are not guaranteed to be backwards compatible with the previous ones. They might be! But if they aren't, then you need to do maintenance if you want to use the modern development toolchain. Maintenance is a cost paid for with labor, and open-source codebases are the projects that can least afford to pay it. Opting not to use a build step drastically minimizes the labor required to keep htmx up-to-date. This experience has been borne out by [intercooler.js](https://intercoolerjs.org), the predecessor to htmx which is maintained indefinitely with (as I understand) very little effort. When htmx 1.0 was released, TypeScript was at version 4.1; when intercooler.js was released, TypeScript was pre-1.0. Would code written in those TypeScript versions compile unmodified in today's TypeScript compiler (version 5.1 at the time of writing)? Maybe, maybe not. @@ -60,6 +66,6 @@ This makes doing certain things with htmx very difficult. The [idiomorph algorit # Final Thoughts This essay might be better titled "Why htmx Doesn't Have a Build Step Right Now." As previously mentioned, circumstances change and these tradeoffs can be revisited at any time! One issue we're exploring at the moment has to do with releases. When htmx cuts releases, it uses a few different shell commands to populate the `dist` directory with minified and compressed versions of `htmx.js` (pedants are welcome to point out that this is obviously, in some sense, a build step). In the future, we might expand that script to auto-generate the [Universal Module Definition](https://github.com/umdjs/umd). Or we might have new distribution needs that require an even more involved setup. Who knows! -One of the core values of htmx is that it gives you *choice* in a web development ecosystem that has for the last decade been dominated by an increasingly complex JavaScript stack. Once you no longer have an enormous codebase of frontend JavaScript, there is far less pressure to adopt JavaScript on the backend. You can write backends in Python, Go, even NodeJS, and it doesn't matter to htmx—every mainstream language has mature solutions for formatting HTML. This is the principle of [Hypermedia On Whatever you'd Like (HOWL)](https://htmx.org/essays/hypermedia-on-whatever-youd-like/). +One of the core values of htmx is that it gives you *choice* in a web development ecosystem that has for the last decade been dominated by an increasingly complex JavaScript stack. Once you no longer have an enormous codebase of frontend JavaScript, there is far less pressure to adopt JavaScript on the backend. You can write backends in Python, Go, even Node.js, and it doesn't matter to htmx—every mainstream language has mature solutions for formatting HTML. This is the principle of [Hypermedia On Whatever you'd Like (HOWL)](https://htmx.org/essays/hypermedia-on-whatever-youd-like/). -Writing JavaScript with no build process is one of the options available to you once you no longer require NextJS or SvelteKit to manage the spiraling complexity of SPA frameworks. That choice makes sense for htmx development today, and it may or may not make sense for your app too. +Writing JavaScript with no build process is one of the options available to you once you no longer require Next.js or SvelteKit to manage the spiraling complexity of SPA frameworks. That choice makes sense for htmx development today, and it may or may not make sense for your app too. diff --git a/www/content/essays/prefer-if-statements.md b/www/content/essays/prefer-if-statements.md index 1f62eacfe..4bc60626c 100644 --- a/www/content/essays/prefer-if-statements.md +++ b/www/content/essays/prefer-if-statements.md @@ -1,9 +1,14 @@ +++ title = "Prefer If Statements To Polymorphism..." +description = """\ + In this collection of tweets, Carson Gross explores unconventional programming principles, including favoring if \ + statements over polymorphism, minimizing abstractions, and prioritizing practical, implementation-driven \ + development. He challenges traditional software design norms, advocating for simplicity, locality, and utility over \ + complexity and abstraction.""" date = 2024-12-07 updated = 2024-12-07 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ @@ -21,7 +26,7 @@ tag = ["posts"] > they should just do something useful man * *[The Minimize Abstractions Principle](https://x.com/htmx_org/status/1843806270559793475)* > The Minimize Abstractions Principle (MAP) is a computer programming principle that states that "a module should - > minimize the number of abstractions it contains, both in API and in implementation. Stop navel gazing nerd. + > minimize the number of abstractions it contains, both in API and in implementation. Stop navel gazing nerd." * *[The Try It Out Substitution Principle](https://x.com/htmx_org/status/1843807054970139139)* > The "Try It Out" Substitution Principle states that you should try something out and, if that doesn't work, think about why, and substitute something else for it instead. > @@ -35,7 +40,7 @@ tag = ["posts"] > > when they exhaust that budget & ask for more, tell them they can have another abstraction when they remove an existing one > - > when they complain, look for classes with the term "Factory", "Lookup" or "Visitor" in their names] + > when they complain, look for classes with the term "Factory", "Lookup" or "Visitor" in their names * *[Fewer Functions](https://x.com/htmx_org/status/1843822378352291914)* > if your function is only called in one place, consider inlining it & reducing the total number of method signatures in your module, to help people better understand it > @@ -43,7 +48,7 @@ tag = ["posts"] * *["God" Object](https://x.com/htmx_org/status/1843823231771521367)* > consider creating "God" objects that wrap a lot of functionality up in a single package > - > consumers of your API don't want to learn 50 different classes to get something done, so give them a few that provide the core functionality of your module with minimal fuss] + > consumers of your API don't want to learn 50 different classes to get something done, so give them a few that provide the core functionality of your module with minimal fuss * *[Copy & Paste Driven Development](https://x.com/htmx_org/status/1843827082687852706)* > copy&paste driven development is a development methodology where, when you need to reuse some code but in a slightly different manner, you copy & paste the code & then modify it to satisfy the new requirements > diff --git a/www/content/essays/rest-copypasta.md b/www/content/essays/rest-copypasta.md index f5a207b54..5789b18f5 100644 --- a/www/content/essays/rest-copypasta.md +++ b/www/content/essays/rest-copypasta.md @@ -1,9 +1,14 @@ +++ title = "REST Copypasta" +description = """\ + These page provides some pre-written critiques of the common misuse of the term 'REST' in modern web development, \ + contrasting it with the true REST architecture defined by Roy Fielding. Copy these ready-made responses to helpfully \ + explain how JSON/RPC is often mislabeled as REST and highlight the role of hypermedia and API specifications in \ + defining REST-ful systems. You will surely not make any enemies or regret posting these responses in any way.""" date = 2023-06-26 updated = 2023-06-26 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] [extra] show_title = false diff --git a/www/content/essays/rest-explained.md b/www/content/essays/rest-explained.md index 3b96f779c..0859054d5 100644 --- a/www/content/essays/rest-explained.md +++ b/www/content/essays/rest-explained.md @@ -1,7 +1,15 @@ +++ title = "REST - Explained For Beginners" +description = """\ + In this essay, Carson Gross presents the core concepts of REST (Representational State Transfer) explained in simple \ + terms for beginners. He breaks down Roy Fielding's dissertation to highlight key principles like the Uniform \ + Interface, Statelessness, Hypermedia (HATEOAS), and more, making REST easy to understand for non-academic web \ + developers.""" date = 2021-07-13 updated = 2022-02-06 +authors = ["Carson Gross"] +[taxonomies] +tag = ["posts"] +++ There is no topic that generates more confusion in web development than the idea of Representational State Transfer, diff --git a/www/content/essays/right-click-view-source.md b/www/content/essays/right-click-view-source.md index 89537cc0c..cebf4dde0 100644 --- a/www/content/essays/right-click-view-source.md +++ b/www/content/essays/right-click-view-source.md @@ -1,9 +1,15 @@ +++ title = "The #ViewSource Affordance" +description = """\ + In this essay, Carson Gross explores the significance of the #ViewSource affordance in preserving the open, \ + collaborative culture of the early web. He examines the impact of digital and technical enclosure on this culture, \ + highlights the importance of developer decisions in maintaining openness, and advocates for prioritizing \ + #ViewSource-friendly practices in modern web development.""" date = 2023-09-21 updated = 2023-09-21 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] +tag = ["posts"] +++ > Not for nothing, Hypercard presaged the web's critical "#ViewSource" affordance, which allowed people to copy, @@ -18,7 +24,7 @@ When people talk about open source software, that conversation is often dominate [the Free Software Foundation's notion of free software](https://www.gnu.org/philosophy/free-sw.html): > “Free software” means software that respects users' freedom and community. Roughly, it means that the users have the -> freedom to run, copy, distribute, study, change and improve the software." +> freedom to run, copy, distribute, study, change and improve the software. This definition of free software has been a useful one and, through advocating for it, the FSF has gifted the world a lot of wonderful open source software. @@ -98,7 +104,7 @@ technical decisions and how those decisions can also contribute to the disappear Inadvertently (for the most part) technical trends and decisions in web development in the last two decades have lead to what we term a "Technical Enclosure" of the web, a processes whereby technical decisions chip away at the #ViewSource -affordance that Cory Doctrow discusses in the opening quote of this article, an affordance that existed as a commons +affordance that Cory Doctorow discusses in the opening quote of this article, an affordance that existed as a commons for early web developers. To see a stark example of the decline of the [#ViewSource](https://en.wikipedia.org/wiki/View-source_URI_scheme) affordance @@ -122,8 +128,8 @@ challenging for even the most seasoned web developer. A new web developer would have almost no chance of deriving any value from doing so. -Now, this is not to criticize the google engineer's technical decisions that lead to this situation _as technical -decisions_: obviously, despite similar appearances, the google homepage of 2023 is far more sophisticated than the one +Now, this is not to criticize the Google engineer's technical decisions that lead to this situation _as technical +decisions_: obviously, despite similar appearances, the Google homepage of 2023 is far more sophisticated than the one available in 2000. The 2023 google homepage is going to be a lot more complicated than the 2000 page and, given the zeitgeist, it is going to diff --git a/www/content/essays/spa-alternative.md b/www/content/essays/spa-alternative.md index f94a07817..cd0ca8f15 100644 --- a/www/content/essays/spa-alternative.md +++ b/www/content/essays/spa-alternative.md @@ -1,9 +1,15 @@ +++ title = "SPA Alternative" +description = """\ + In this essay, Carson Gross explores alternatives to Single Page Applications (SPAs), advocating for an \ + 'HTML-Centric' development approach. He highlights the drawbacks of SPA complexity and the benefits of embracing \ + HTML as the core medium for web development, offering a simpler, more efficient way to build applications without \ + sacrificing interactivity. Carson discusses how tools like htmx enhance HTML's capabilities and encourages \ + developers to reconsider the dominant SPA paradigm with technical bravery.""" date = 2020-10-29 updated = 2022-02-06 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ @@ -74,7 +80,7 @@ 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 +* A request must replace the entire screen, leading to a clunky and sometimes jarring user experience Of course, none of the constraints are inherent in the concept of a hypertext, and the goal of [htmx](@/_index.md) is to remove each of them. diff --git a/www/content/essays/splitting-your-apis.md b/www/content/essays/splitting-your-apis.md index 54f10d074..0c4ade7e4 100644 --- a/www/content/essays/splitting-your-apis.md +++ b/www/content/essays/splitting-your-apis.md @@ -1,9 +1,13 @@ +++ title = "Splitting Your Data & Application APIs: Going Further" +description = """\ + If you split your API into Data and Application APIs, you should consider changing your Application API from JSON to \ + Hypermedia (HTML) and using a hypermedia-oriented library like htmx to reap the benefits of the hypermedia model \ + (simplicity, reliability, and flexibility).""" date = 2021-09-16 updated = 2022-02-06 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/template-fragments.md b/www/content/essays/template-fragments.md index aa834561b..2bfb09691 100644 --- a/www/content/essays/template-fragments.md +++ b/www/content/essays/template-fragments.md @@ -1,9 +1,16 @@ +++ title = "Template Fragments" +description = """\ + In this essay, Carson Gross explores the concept of template fragments, a feature in server-side rendering (SSR) \ + that allows partial rendering of content within templates. He highlights the benefits of using template fragments in \ + hypermedia-driven applications, providing a cleaner and more maintainable approach compared to traditional template \ + decomposition. Carson showcases the use of template fragments in the Chill templating language and discusses how \ + this feature improves the developer experience when working with htmx and other hypermedia-oriented libraries. He \ + also includes examples and known implementations of template fragments in various programming languages.""" date = 2022-08-03 updated = 2023-03-18 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/two-approaches-to-decoupling.md b/www/content/essays/two-approaches-to-decoupling.md index de6c4c0ce..1d1f513d6 100644 --- a/www/content/essays/two-approaches-to-decoupling.md +++ b/www/content/essays/two-approaches-to-decoupling.md @@ -1,9 +1,16 @@ +++ title = "Two Approaches To Decoupling" +description = """\ + Carson Gross explores two different approaches to decoupling in web applications: decoupling at the application \ + level using a JSON Data API and decoupling at the network architecture level using a hypermedia API. He discusses \ + the trade-offs between the two methods, highlighting how a hypermedia API, despite introducing tighter coupling at \ + the application level, offers greater resilience to change at the system level. Carson also touches on the \ + limitations of each approach and discusses strategies like GraphQL and splitting APIs to address specific challenges \ + in web development.""" date = 2022-05-01 updated = 2022-05-01 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ @@ -157,7 +164,7 @@ is to say, at the system level. [Hypermedia systems](https://hypermedia.systems client (in the case of the web, the browser) from the hypermedia server. This is accomplished primarily via the Uniform Interface constraint of REST and, in particular, by using -Hypermedia As The Engine of Application State ([HATOEAS](/essays/hateoas)). +Hypermedia As The Engine of Application State ([HATEOAS](/essays/hateoas)). This style of decoupling allows tighter coupling at the higher application level (which we have seen may be an _inherent_ coupling) while still retaining the benefits of decoupling for the overall system. diff --git a/www/content/essays/vendoring.md b/www/content/essays/vendoring.md index a1c4aa840..8f74433b1 100644 --- a/www/content/essays/vendoring.md +++ b/www/content/essays/vendoring.md @@ -1,9 +1,16 @@ +++ title = "Vendoring" +description = """\ + Carson Gross explores the concept of 'vendoring' in software development, where external project sources are copied \ + directly into a project. He covers the benefits of vendoring, such as improved visibility and control over \ + dependencies, and discusses challenges like transitive dependencies and the culture of dependency in modern software \ + development. He also contrasts vendoring with modern dependency management tools, and considers the potential for \ + vendor-first dependency managers to combine the strengths of both approaches. He encourages a rethinking of \ + dependencies and promotes a more independent approach to software development.""" date = 2025-01-27 updated = 2025-01-27 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ @@ -41,12 +48,12 @@ It turns out there are quite a few: * Your entire project is checked in to your source repository, so no external systems beyond your source control need to be involved when building it -* Vendoring dramaticaly improves dependency *visibility*: you can _see_ all the code your project depends on, so you +* Vendoring dramatically improves dependency *visibility*: you can _see_ all the code your project depends on, so you won't have a situation like we have in htmx, where we feel like we only have a few development dependencies, whe in fact we may have a lot * This also means if you have a good debugger, you can step into the library code as easily as any other code. You can also read it, learn from it and even modify it if necessary. -* From a security perspective, you aren't relying on opaque code. Even if your package manager has a +* From a security perspective, you aren't relying on opaque code. Even if your package manager has an integrity hash system, the actual code may be opaque to you. With vendored code it is checked in and can be analysed automatically or by a security team. * Personally, it has always seemed crazy to me that people will often resolve dependencies at deployment time, right @@ -97,7 +104,7 @@ engineering, there are tradeoffs associated with them. To see some of these tra [`package-lock.json`](https://github.com/bigskysoftware/htmx/blob/master/package-lock.json) file in htmx. NPM generates a `package-lock.json` file that contains the resolved transitive closure of dependencies for a project, with -the concrete versions of those dependencies. This helps ensure that the same dependencies are used unless an user +the concrete versions of those dependencies. This helps ensure that the same dependencies are used unless a user explicitly updates them. If you take a look at the `package-lock.json` for htmx, you will find that the original 13 development dependencies have @@ -185,7 +192,7 @@ There is also a set htmx-adjacent projects that are taking vendoring seriously: * [fixi](https://github.com/bigskysoftware/fixi) - a minimal htmx alternative None of these JavaScript projects are available in NPM, and all of them [recommend](https://github.com/gnat/surreal#-install) -[vendoring](https://github.com/kgscialdone/facet#installation) the [software](https://github.com/bigskysoftware/fixi#instalation) +[vendoring](https://github.com/kgscialdone/facet#installation) the [software](https://github.com/bigskysoftware/fixi#installing) into your own project as the primary installation mechanism. ## Vendor First Dependency Managers? diff --git a/www/content/essays/view-transitions.md b/www/content/essays/view-transitions.md index 35d462d7b..582dba700 100644 --- a/www/content/essays/view-transitions.md +++ b/www/content/essays/view-transitions.md @@ -1,9 +1,16 @@ +++ template = "demo.html" title = "View Transitions" +description = """\ + Carson Gross explores the evolution of web applications and the significance of view transitions in improving user \ + experience. He discusses the limitations of traditional web design, where full-page refreshes create an unpleasant \ + experience, and how modern technologies like CSS transitions and the View Transition API aim to enhance aesthetic \ + smoothness. Carson explains how htmx leverages the View Transition API to bring seamless transitions to \ + hypermedia-driven applications, offering an alternative to single-page applications (SPAs) and highlighting its \ + potential once widely available in HTML.""" date = 2023-04-11 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ @@ -18,7 +25,7 @@ the application, even if it has feature-parity with an SPA version: > delete a contact. This is because every user interaction (link click or form submission) requires a full page > refresh, with a whole new HTML document to process after each action. > -> *–Hypermedia Systems - [Chapter 5](https://hypermedia.systems/book/extending-html-as-hypermedia/)* +> *–Hypermedia Systems - [Chapter 4](https://hypermedia.systems/extending-html-as-hypermedia/)* This jarring "ka-chunk" between webpages, often with a [Flash of Unstyled Content](https://webkit.org/blog/66/the-fouc-problem/) has been with us forever and, while modern browsers have improved the situation somewhat (while, unfortunately, also making diff --git a/www/content/essays/web-security-basics-with-htmx.md b/www/content/essays/web-security-basics-with-htmx.md index 3e7d0bb04..5f797880f 100644 --- a/www/content/essays/web-security-basics-with-htmx.md +++ b/www/content/essays/web-security-basics-with-htmx.md @@ -1,8 +1,15 @@ +++ title = "Web Security Basics (with htmx)" +description = """\ + This guide by Alexander Petros provides essential web security best practices for building applications with htmx, \ + focusing on safe handling of dynamic, user-generated content. It covers fundamental principles such as using only \ + trusted routes, employing auto-escaping template engines, and securing cookies to prevent common vulnerabilities \ + like Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF). Aimed at developers familiar with backend \ + server construction, it emphasizes security techniques that are easy to implement and crucial for protecting user \ + data in dynamic web applications.""" date = 2024-02-06 +authors = ["Alexander Petros"] [taxonomies] -author = ["Alexander Petros"] tag = ["posts"] +++ @@ -53,7 +60,7 @@ The reason for this is simple: htmx inserts the response from that route directl Fortunately, this is a very easy rule to follow. Hypermedia APIs (i.e. HTML) are [specific to the layout of your application](https://htmx.org/essays/hypermedia-apis-vs-data-apis/), so there is almost never any reason you'd *want* to insert someone else's HTML into your page. All you have to do is make sure you only call your own routes (htmx 2 will actually disable calling other domains by default). -Though it's not quite as popular these days, a common SPA pattern was to separate the frontend and backend into different repositories, and sometimes even to serve them from different URLs. This would require using absolute URLs in the frontend, and often, [disabling CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). With htmx (and, to be fair, modern React with NextJS) this is an anti-pattern. +Though it's not quite as popular these days, a common SPA pattern was to separate the frontend and backend into different repositories, and sometimes even to serve them from different URLs. This would require using absolute URLs in the frontend, and often, [disabling CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). With htmx (and, to be fair, modern React with Next.js) this is an anti-pattern. Instead, you simply serve your HTML frontend from the same server (or at least the same domain) as your backend, and everything else falls into place: you can use relative URLs, you'll never have trouble with CORS, and you'll never call anyone else's backend. diff --git a/www/content/essays/webcomponents-work-great.md b/www/content/essays/webcomponents-work-great.md index 9e36013f7..7427aee7b 100644 --- a/www/content/essays/webcomponents-work-great.md +++ b/www/content/essays/webcomponents-work-great.md @@ -1,8 +1,15 @@ +++ title = "Web Components Work Great with htmx" +description = """\ + This essay by Alexander Petros explores how Web Components can be integrated seamlessly with htmx, a library that \ + enables dynamic web pages through HTML. It discusses the flexibility of htmx in handling interactive elements like \ + Web Components alongside traditional server-driven approaches, such as multi-page apps. By using the example of an \ + editable carnival ride table, Alexander demonstrates how Web Components simplify functionality without the need for \ + heavy JavaScript frameworks, highlighting their compatibility with htmx's DOM-based lifecycle. Alexander also \ + addresses potential challenges and how htmx manages them efficiently.""" date = 2024-11-13 +authors = ["Alexander Petros"] [taxonomies] -author = ["Alexander Petros"] tag = ["posts"] +++ @@ -145,7 +152,7 @@ A lot of the problems that JavaScript frameworks have supporting Web Components Web Components [have DOM-based lifecycles](https://dev.to/ryansolid/web-components-are-not-the-future-48bh), so they are difficult for JavaScript frameworks, which often manipulate elements outside of the DOM, to work with. Frameworks have to account for some [bizarre and arguably buggy](https://x.com/Rich_Harris/status/1841467510194843982) APIs that behave differently for native DOM elements than they do for custom ones. -Here at htmx, we agree with with [SvelteJS creator Rich Harris](https://x.com/Rich_Harris/status/1839484645194277111): "web components are [not] useful primitives on which to build web frameworks." +Here at htmx, we agree with [SvelteJS creator Rich Harris](https://x.com/Rich_Harris/status/1839484645194277111): "web components are [not] useful primitives on which to build web frameworks." The good news is that htmx [is not really a JavaScript web framework](@/essays/is-htmx-another-javascript-framework.md). The DOM-based lifecycles of custom elements work great in htmx, because everything in htmx has a DOM-based lifecycle—we get stuff from the server, and we add it to the DOM. diff --git a/www/content/essays/when-to-use-hypermedia.md b/www/content/essays/when-to-use-hypermedia.md index 9f41f3976..b4503ba89 100644 --- a/www/content/essays/when-to-use-hypermedia.md +++ b/www/content/essays/when-to-use-hypermedia.md @@ -1,9 +1,17 @@ +++ title = "When Should You Use Hypermedia?" +description = """\ + This essay by Carson Gross explores when to use hypermedia in web development, highlighting its advantages and \ + trade-offs. Carson discusses scenarios where hypermedia is a good fit, such as text and image-heavy UIs, CRUD \ + applications, and nested UIs with well-defined areas. He also addresses when hypermedia may not be ideal, including \ + situations with frequent UI state updates, offline requirements, or dynamic interdependencies. Using a \ + 'Transitional' approach (as suggested by Rich Harris), Carson advocates for combining hypermedia with other \ + strategies to optimize web application development, emphasizing its practical benefits and alignment with the web's \ + architecture.""" date = 2022-10-23 updated = 2023-02-03 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ diff --git a/www/content/essays/why-gumroad-didnt-choose-htmx.md b/www/content/essays/why-gumroad-didnt-choose-htmx.md index ea96145df..48ecfa709 100644 --- a/www/content/essays/why-gumroad-didnt-choose-htmx.md +++ b/www/content/essays/why-gumroad-didnt-choose-htmx.md @@ -1,9 +1,16 @@ +++ title = "Why Gumroad Didn't Choose htmx" +description = """\ + In this essay, Sahil Lavingia, CEO of Gumroad, explains why the company decided against using htmx for its new \ + project, Helper, in favor of React and Next.js. He shares the challenges faced with htmx, including issues with \ + developer experience, user experience limitations, scalability, and AI tool support. While acknowledging htmx's \ + potential for simpler projects, Lavingia emphasizes how React and Next.js offered better solutions for complex \ + features like real-time collaboration, drag-and-drop functionality, and dynamic forms. Ultimately, Lavingia \ + highlights the importance of selecting technologies that can grow with the project's needs.""" date = 2024-09-30 updated = 2024-09-30 +authors = ["Sahil Lavingia"] [taxonomies] -author = ["Sahil Lavingia"] tag = ["posts"] +++ @@ -66,7 +73,7 @@ Here's why: Gumroad Green -
Source with NextJS - Click Image To View
+
Source with Next.js - Click Image To View
Ultimately, we ended up moving to React/Next.js, which has been a really great fit for building the complex UX we've diff --git a/www/content/essays/why-tend-not-to-use-content-negotiation.md b/www/content/essays/why-tend-not-to-use-content-negotiation.md index c06586bbe..7bfdd4426 100644 --- a/www/content/essays/why-tend-not-to-use-content-negotiation.md +++ b/www/content/essays/why-tend-not-to-use-content-negotiation.md @@ -1,9 +1,16 @@ +++ title = "Why I Tend Not To Use Content Negotiation" +description = """\ + In this essay, Carson Gross explores his preference for separating JSON and hypermedia APIs instead of using content \ + negotiation, a feature in HTTP that allows clients to request different formats (e.g., HTML, JSON). He discusses the \ + limitations of content negotiation in APIs, especially when mixing stable, versioned JSON data APIs with dynamic, \ + UI-driven hypermedia APIs. Carson argues that by splitting these concerns into distinct APIs, developers can better \ + maintain stability for data APIs while allowing flexibility for hypermedia APIs to evolve with user interface needs. \ + He also highlights the challenges content negotiation introduces to API design and scalability.""" date = 2023-11-18 updated = 2023-11-18 +authors = ["Carson Gross"] [taxonomies] -author = ["Carson Gross"] tag = ["posts"] +++ @@ -154,7 +161,7 @@ is making a SoC argument.) ## So What's The Alternative? The alternative is, as I advocate in [Splitting Your APIs](@/essays/splitting-your-apis.md), er, well, splitting your -APIs. This means providing different paths (or sub-domains, or whatever) for your JSON API and your hypermedia (HTML) +APIs. This means providing different paths (or subdomains, or whatever) for your JSON API and your hypermedia (HTML) API. Going back to our contacts API, we might have the following: diff --git a/www/content/essays/you-cant.md b/www/content/essays/you-cant.md index 4c05dc8ee..c73370614 100644 --- a/www/content/essays/you-cant.md +++ b/www/content/essays/you-cant.md @@ -1,9 +1,16 @@ +++ title = "You Can't Build Interactive Web Apps Except as Single Page Applications... And Other Myths" +description = """\ + Tony Alaribe challenges common myths about multi-page applications (MPAs) and explores how modern browser \ + technologies can enable fast, interactive, and offline-capable web applications without relying on single-page \ + application (SPA) frameworks. Alaribe discusses advancements in service workers, caching, and cross-document \ + transitions, offering insights into building efficient MPAs. By debunking myths like slow page transitions and the \ + necessity of JavaScript-heavy frameworks, Alaribe highlights how developers can leverage HTML, CSS, and minimal \ + JavaScript to create robust, user-friendly web apps in 2024.""" date = 2024-09-20 updated = 2024-09-20 +authors = ["Tony Alaribe"] [taxonomies] -author = ["Tony Alaribe"] tag = ["posts"] +++ @@ -144,9 +151,9 @@ help you—I prefer using Google's [Workbox](https://developer.chrome.com/docs/w By following these steps, you instruct the browser to serve cached assets whenever possible, drastically reducing load times and improving the overall performance of your multi-page application. -![Image showing the registered service worker from the chrome browser console.](/img/you-cant/service-worker.png) +![Image showing the registered service worker from the Chrome browser console.](/img/you-cant/service-worker.png) -Image showing the registered service worker from the chrome browser console. +Image showing the registered service worker from the Chrome browser console. ### [`Speculation Rules API`](https://developer.mozilla.org/en-US/docs/Web/API/Speculation_Rules_API): Prerender pages for instant page navigation. @@ -235,7 +242,7 @@ don't have to do everything server-side. Many HTMX and regular MPA users continu Hyperscript where appropriate. In situations where robust interactivity is helpful, you can lean into the component islands architecture using -WebComponents or any javascript framework (react, angular, etc) of your choice. That way, instead of your entire +WebComponents or any javascript framework (React, Angular, etc.) of your choice. That way, instead of your entire application being an SPA, you can leverage those frameworks specifically for the bits of your application that need that interactivity. diff --git a/www/templates/demo.html b/www/templates/demo.html index 363e92fb9..e578772ad 100644 --- a/www/templates/demo.html +++ b/www/templates/demo.html @@ -4,6 +4,14 @@ {% set html_title = "</> htmx ~ Examples ~ " ~ page.title %} {% endblock title %} +{% block description %} + {%- if page.description -%} + {{- page.description | safe -}} + {%- else -%} + {{- super() -}} + {%- endif -%} +{% endblock description %} + {% block content %} {% if page.extra and page.extra.show_title is defined %} {% set show_title = page.extra.show_title %} diff --git a/www/themes/htmx-theme/templates/essay.html b/www/themes/htmx-theme/templates/essay.html index ec8ec7100..bc4dc6af3 100644 --- a/www/themes/htmx-theme/templates/essay.html +++ b/www/themes/htmx-theme/templates/essay.html @@ -30,8 +30,8 @@ {% set page_title = page.title -%} {% if show_title %}

{{ page_title | safe }}

{% endif %} - {% if show_author and page.taxonomies.author %} -
{{ page.taxonomies.author | join(sep=", ") }}
+ {% if show_author and page.authors | length > 0 %} +
{{ page.authors | join(sep=", ") }}
{% endif %} diff --git a/www/themes/htmx-theme/templates/page.html b/www/themes/htmx-theme/templates/page.html index 256374fa1..9d9589332 100644 --- a/www/themes/htmx-theme/templates/page.html +++ b/www/themes/htmx-theme/templates/page.html @@ -12,6 +12,14 @@ {% endif -%} {% endblock title %} +{% block description %} + {%- if page.description -%} + {{- page.description | safe -}} + {%- else -%} + {{- super() -}} + {%- endif -%} +{% endblock description %} + {% block content %} {% if page.extra and page.extra.show_title is defined -%} {% set show_title = page.extra.show_title -%}