DEV Community: Devin Weaver

Dealing with relative paths in JavaScript URL parsing

Devin Weaver — Fri, 27 Jun 2025 21:02:44 +0000

Hey friends! 👋 Let's talk about a neat trick for handling URLs in our apps, especially when dealing with relative paths.
You know, those paths that look like /app/route.

Here's the deal: The URL constructor in JavaScript usually needs a full URI, including the schema (like https:// or ftp://).
But, we often work with relative paths that don't have all that extra info.

Now, we could add a fake domain like https://example.com/ to make it work, but that feels a bit... well, fake! 😅

Here's where it gets interesting: There's this cool thing called the thismessage:/ schema. It's like a special code that tells the URL parser, "Hey, just focus on the path part, don't worry about domains and stuff." It's perfect for our relative paths!

The smart folks at W3C created this schema specifically for situations like ours. It's like a magic wand 🪄 that lets us parse relative paths without any extra baggage.

Here's how we use it:

We add thismessage:/ to our relative path.
We parse it using the URL constructor.
We do whatever we need to do with the URL object.
When we're done, we can easily remove the thismessage: part to get back our original relative path.

const fullURI = 'https://example.com/app/route?query=params';
const relativeURI = '/app/route?query=params';

new URL(fullURI); // OK
new URL(relativeURI); // THROWS exception!

new URL(fullURI, 'thismessage:/'); // OK
new URL(relativeURI, 'thismessage:/'); // OK

It's like putting on a special hat to get through a door, and then taking it off once we're inside! 🎩

And it is reversible in cases when you need to preserve the URI
but not the schema/hostname portions:

const url = new URL('thismessage:/app/route');

// will auto URL encode correctly
url.searchParams.set('query', someString);

url.href.substring(12); // => "/app/route?query=params"

This approach is actually backed by some official internet rules (RFC2557 §5 & §12, for the curious cats out there 🐱). These rules say that when you can't resolve a relative URI any other way, you should treat it as if it started with thismessage:/.

There you have it! A friendly, standards-compliant way to work with relative paths in our URL handling. It's like having a Swiss Army knife for URLs – versatile and handy!

I hope this explanation makes the concept clearer and more fun to understand. Happy coding, everyone! 🚀💻

The Convergence of Literary Code: How AI Code Generation Accidentally Embodies Literate Programming Ideals

Devin Weaver — Thu, 29 May 2025 11:50:00 +0000

I had the thought the other day that the process of AI assisted discovery and generation was similar to what I understood as “Literate Programming”. Though at the time I did not have a means to articulate that similarity myself. And so what self respecting writer could write about AI without using AI?

I dove into using Claude 3.7 Sonnet to have a conversation about this idea. I first had to give it some context:

Prompt: Compile a list of concepts for the philosophy of “literate programming”

It did some web searching and then as usual spit out a summarization of the topic. With some knowledge context in hand I then took it a step further to redirect the focus to the topic:

Prompt: With that understanding, make a comparison of literate programming and the use of ai prompting to generate code

And here is where I was concerned; as it generated a bunch of lists highlighting one concept versus another concept. It pitted them against each other instead of comparing similarities.

Response: While literate programming treats programming as literature with emphasis on human understanding and exposition, AI prompting treats programming as problem-solving automation. Literate programming seeks to elevate the craft through careful explanation and style, while AI prompting seeks to democratize and accelerate code production. The former prioritizes the journey of understanding, while the latter prioritizes the destination of working code.

This isn’t what I had in mind; time for me to coach the AI:

Prompt: Given how LLMs are alliteration predictors and when generating code do so in a form of human-computer dialogue with essay like responses, are there any similarities to how literate programming is focused on understanding and ai code generation comes with prose and chain of thought conversations?

And then it happened, somehow the pattern recognition saw what I was thinking.

Response: This is a fascinating observation that reveals some striking philosophical parallels between literate programming and AI code generation, despite their different origins and mechanisms.

And there I had it. I was able to use the detailed similarities comparison it generated to drive the creation of an essay. To which I will now place here for your enjoyment. This was generated by AI, read and verified by me, and I align with the core message of this essay.

The Convergence of Literary Code: How AI Code Generation Accidentally Embodies Literate Programming Ideals

When Donald Knuth introduced literate programming in 1984, he envisioned a radical departure from conventional software development. The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style . This paradigm represents a move away from writing computer programs in the manner and order imposed by the compiler, and instead gives programmers macros to develop programs in the order demanded by the logic and flow of their thoughts .

Four decades later, large language models have emerged as powerful code generation tools, operating through human-computer dialogue with essay-like responses. While these systems were not designed with Knuth's literary vision in mind, they exhibit remarkable philosophical parallels to literate programming principles—suggesting that human-readable, explanation-rich code presentation may be a natural evolution in programming methodology.

The Literary Foundation of Code

Knuth's core insight was that programmers should think of programs as works of literature . Literate programming is a programming paradigm in which a computer program is given as an explanation of how it works in a natural language, such as English, interspersed with snippets of macros and traditional source code . The fundamental principle treats a program as a piece of literature, addressed to human beings rather than to a computer .

This approach combines a programming language with a documentation language, making programs more robust, more portable, more easily maintained, and arguably more fun to write . The methodology emphasizes the organization of source code into small sections and the production of a book quality program listing , creating what amounts to hypertext documents that prioritize human understanding over machine efficiency.

The Conversational Nature of AI Code Generation

Large language models, functioning as sophisticated pattern predictors, generate code within inherently conversational contexts. When prompted to solve programming problems, these systems naturally produce essay-like responses that combine natural language explanation with code snippets—a format that mirrors literate programming's integration of exposition and implementation.

This conversational approach creates a human-computer dialogue where code emerges through iterative explanation and refinement. The AI's responses typically follow a chain-of-thought progression, building solutions through logical exposition rather than jumping directly to implementation details. This process echoes literate programming's emphasis on top-down exposition and development in the order demanded by the logic and flow of their thoughts .

Philosophical Convergences

Exposition-Driven Development

Both approaches prioritize explanation as a primary concern. Literate programming treats the programmer as an essayist, whose main concern is with exposition and excellence of style , while AI code generation naturally embeds code within explanatory contexts that aid human understanding. The AI's responses demonstrate a similar commitment to making code comprehensible through prose.

Natural Language Integration

Knuth's vision of natural language explanations interspersed with code snippets finds unexpected realization in AI-generated responses. Both approaches seamlessly blend programming logic with human-readable explanation, creating unified presentations that serve both functional and educational purposes.

Human-Centric Presentation

Literate programming emphasizes human readability as a primary concern , treating programs as literature addressed to human beings rather than to a computer . Similarly, AI code generation prioritizes human understanding through conversational interfaces, presenting solutions in formats optimized for human comprehension rather than machine efficiency.

Flexible Organization

Both methodologies move away from compiler-imposed structure. Literate programming allows development in the order demanded by the logic and flow of their thoughts , while AI responses follow conversational logic and problem-solving progression rather than strict programming constraints.

Fundamental Distinctions

Despite these convergences, crucial differences separate the two approaches:

Intentionality and Craftsmanship

Literate programming requires deliberate human craftsmanship and commitment to excellence of style . The programmer consciously constructs both code and exposition as literary art. AI generation, while producing explanatory responses, lacks the intentional literary quality that defines Knuth's vision.

Philosophical Purpose

Literate programming aims to elevate programming to literary art, emphasizing book quality program listing and treating code as works of literature . AI code generation serves functional problem-solving within conversational interfaces, prioritizing utility over literary excellence.

Knowledge Preservation

Literate programming preserves human thought processes and reasoning within code structure, creating lasting documentation of decision-making. AI responses, while explanatory, represent algorithmic pattern matching rather than genuine human insight preservation.

The Accidental Embodiment

The convergence reveals how LLMs accidentally embody some literate programming ideals without the philosophical commitment to programs as literature. AI systems achieve functional literacy—making code accessible through dialogue—while literate programming pursues artistic literacy through deliberate literary methodology.

This parallel suggests that human-readable, explanation-rich code presentation may be an inevitable evolution in programming, whether achieved through conscious literary practice or emergent conversational AI capabilities. Both approaches recognize that code serves not just machines but human understanding, though they pursue this goal through different philosophical frameworks.

Implications for Programming Practice

The unexpected alignment between these paradigms highlights the enduring relevance of Knuth's insights. While literate programming has never taken off and remains a curiosity, hidden in a dark corner, and ignored , its core principles—exposition, human readability, and natural language integration—find new expression through AI-mediated development.

This convergence suggests that the future of programming may naturally evolve toward more literate practices, not through adoption of Knuth's specific methodology, but through tools that inherently prioritize human understanding and explanation. The dialogue between human and AI in code generation creates a new form of literate programming—one that achieves exposition and accessibility through conversation rather than conscious literary craft.

In this light, AI code generation represents not a departure from programming tradition, but an unexpected fulfillment of literate programming's vision: code that speaks to humans in human terms, embedded within explanatory contexts that make programming more accessible and understandable. The essayist programmer that Knuth envisioned may have found expression not in human literary discipline, but in the conversational nature of artificial intelligence itself.

Idea conceived by Devin Weaver. Content generated by The Assistant — kagi.com

Why Ember.js is designed for Enterprise Software Development

Devin Weaver — Mon, 25 Sep 2023 17:46:00 +0000

By: Devin Weaver

Introduction

Enterprises require robust and reliable software solutions to stay competitive. The choice of a development framework plays a pivotal role in determining the success of these software projects. Among the various options available, Ember.js stands out as a powerful and comprehensive framework that is ideally suited for enterprise-level software development. This essay aims to elucidate why Ember.js is a more appropriate choice than its competitors for developing enterprise software.

I. Strong Conventions

Ember.js is well known for its strong conventions, which provide a clear and structured path for developers to follow. In the enterprise world, where collaboration and scalability are paramount, these conventions offer several benefits. They ensure that team members understand and adhere to best practices consistently, reducing the likelihood of code discrepancies and fostering maintainability. Competing frameworks often lack such rigor, leading to a more chaotic development process and making Ember.js a superior choice for enterprise projects.

II. Stability and Long-Term Support

Enterprise software needs to be reliable and stable, as it forms the backbone of critical business operations. Ember.js is distinguished by its commitment to stability and long-term support. The Ember project follows a strict release cycle with LTS (Long-Term Support) versions, guaranteeing that businesses can rely on a consistent and dependable framework for years. In contrast, many competitors are known for frequent breaking changes and a lack of commitment to backward compatibility, causing headaches for enterprise developers.

III. Extensive Ecosystem

Ember.js boasts a rich ecosystem of add-ons, libraries, and tools, which significantly accelerates the development process. Enterprises can leverage these resources to expedite the creation of complex features, reducing time-to-market. Moreover, Ember's convention over configuration (CoC) approach ensures that many common application level problems have built-in solutions, saving developers from reinventing the wheel. This extensive ecosystem fosters productivity and sets Ember.js apart from competitors that may require extensive custom solutions for similar functionality.

IV. Robust Testing Capabilities

Quality assurance is critical for enterprise software, and Ember.js excels in this aspect. The framework provides a built-in testing suite, methodologies for CI pipelines, and a slew of supporting add-ons (like ember-exam), which all help to streamline the testing process. This ensures that software remains reliable and bug-free even as it evolves. Competing frameworks often lack such integrated testing tools, requiring additional third-party solutions, which can be cumbersome and less effective for enterprise-scale projects.

V. Community

The Ember community has been consistent in their dedication to supporting enterprise-scale solutions. They focus efforts into accessibility, testing, conventions, and support for third-party integrations. Not only are they welcoming to new developers but are also supportive of experienced developers. They hold to inclusive values and provide public transparency to their future plans by means of a defined RFC process. Many of those in the community continue to show a dedication and enthusiasm for helping others.

Conclusion

In the realm of enterprise software development, selecting the right framework is a critical decision that can impact the success of a project and the future of a business. Ember.js emerges as the superior choice among competitors due to its strong conventions, stability, extensive ecosystem, robust testing capabilities, and support for modern web development trends. Its commitment to providing a reliable and efficient platform makes it the optimal choice for enterprises looking to develop scalable, maintainable, and feature-rich software solutions. Ember.js is not just a framework; it is a powerful ally in the pursuit of enterprise excellence.

State Machines work for logic too

Devin Weaver — Sun, 09 Aug 2020 18:33:35 +0000

Original Article

The other day I found myself in a very peculiar situation. I was writing a very specific bookmarklet where the code I was writing was intentionally terse. It also meant I had to do everything in browser only JavaScript. No CDNs or NPM modules or babel compilation. Luckily the target was the most up-to-date modern browsers (Chrome, FireFox).

In this template I found that I needed to construct a bunch of URLs based on changing data provided to the program. In any normal situation I would use some kind of URL builder library. Something very much like URI Template. This would allow me to define several templates and then run them with the changing data to get expanded URLs for the program.

I looked and found most all implementations of RFC 6570 I found were huge. And they all implemented many features of the RFC I knew I didn't need to use. Since I was constrained to a small source file and no libs I felt copy pasting was not a good option.

My adventure began with me attempting to write my own mini implementation of RFC 6570 cherry-picking the features I knew I wanted and ignoring the rest of the spec. Specifically I wanted to support simple replacement, path and dot prefixes, query params, and optionally fragments and multiple variables (comma separated).

makeUrl('https://tritarget.org{/path}');
makeUrl('https://foo{.domain}.org{/path}');
makeUrl('https://tritarget.org{/path}{?foo,bar,baz}');

I thought about RegExp and knew that would be too many problems. Then I thought JavaScript comes with its own URL building API Unfortunately that API was more focused on parsing then it was building and my initial attempts to make a bunch of mutations to the object really made the code ugly and had difficulty capturing all the edge cases. I finally settled on making a mini template parser and URL compiler. I know, definitely a bad idea but it's my little world YOLO!

When I've experimented with making my own micro parsers in the past I had a lot of boolean switches to track the states while I scanned a string. I also had to mange building up the resulting AST manually. With my simple syntax I wanted I knew that instead of parsing things into an AST like normal I could cut out the middle man and simply make a list of OP Codes. The compiler would be liner and non-contextual.

It also meant that since the parser would tokenize to a flat list of OP Codes I could get away with using a generator function and a finite state machine.

The Parser

The idea behind this is that each character can produce an event that the state machine can react to. For example say we define the following character map:

const EOL = Symbol('EOL');
const TOKENS = {
  [EOL]: 'END_INPUT',
  '{': 'OPEN_BRACE',
  '}': 'CLOSE_BRACE',
  '/': 'OPERATION',
  '+': 'OPERATION',
  '?': 'OPERATION',
  '&': 'OPERATION',
  '#': 'OPERATION',
  '.': 'OPERATION',
  ',': 'SPLIT'
};

for (let char of [...input, EOL]) {
  let eventName = TOKENS[char] || 'TEXT';
  …
}

Walking through the example foo.com{/bar,baz} would mean we would kick off a series of events: TEXT, TEXT, TEXT, OPERATION, TEXT, TEXT, TEXT, OPEN_BRACE, OPERATION, TEXT, TEXT, TEXT, SPLIT, TEXT, TEXT, TEXT, CLOSE_BRACE, END_INPUT.

Looking at the UML State Diagram above we can follow those events and see how they would affect a running state machine:

And finally if we take into account the actions defined in the UML State Diagram we can see the OP Codes being built.

append — adds the character into the OP Code's value property
flush — yield (or push onto an array) the current OP Code and prepare a new one
assignModifier — set the OP Code's modifier property
setTextOpCode — set the OP Code's code property to TEXT
setReplaceOpCode — set the OP Code's code property to REPLACE
setModifiedReplaceOpCode — set the OP Code's code property to RAWREPLACE, PREFIXREPLACE, or QPREPLACE depending on the OP Code's modifier value
setParseError — set the current error message to something specific about the syntax error
setEOLError — set the current error message to something specific about a premature end to the input
throwError — throw an error with the stored error message

[
  { code: 'TEXT', value: 'foo.com' },
  { code: 'PREFIXREPLACE', modifier: '/', value: 'bar' },
  { code: 'PREFIXREPLACE', modifier: '/', value: 'baz' },
  { code: 'TEXT', value: '' }
]

Modeling the machine

Using the UML State Diagram we can model this in object notation like the following:

const lexer = {
  initial: 'text',
  states: {
    text: {
      entry: 'setTextOpCode',
      on: {
        TEXT: { action: 'append' },
        OPERATION: { action: 'append' },
        SPLIT: { action: 'append' },
        OPEN_BRACE: { target: 'replacement', action: 'flush' },
        CLOSE_BRACE: { target: 'error', action: 'setParseError' },
        END_INPUT: { target: 'done', action: 'flush' }
      }
    },
    replacement: {
      entry: 'setReplaceOpCode',
      on: {
        TEXT: { target: 'variable', action: 'append' },
        OPERATION: { target: 'operation', action: 'assignModifier' },
        SPLIT: { target: 'error', action: 'setParseError' },
        OPEN_BRACE: { target: 'error', action: 'setParseError' },
        CLOSE_BRACE: { target: 'error', action: 'setParseError' },
        END_INPUT: { target: 'error', action: 'setEOLError' }
      }
    },
    operation: {
      entry: 'setModifiedReplaceOpCode',
      on: {
        TEXT: { target: 'variable', action: 'append' },
        OPERATION: { target: 'error', action: 'setParseError' },
        SPLIT: { target: 'error', action: 'setParseError' },
        OPEN_BRACE: { target: 'error', action: 'setParseError' },
        CLOSE_BRACE: { target: 'error', action: 'setParseError' },
        END_INPUT: { target: 'error', action: 'setEOLError' }
      }
    },
    variable: {
      on: {
        TEXT: { action: 'append' },
        OPERATION: { target: 'error', action: 'setParseError' },
        SPLIT: { action: 'flush' },
        OPEN_BRACE: { target: 'error', action: 'setParseError' },
        CLOSE_BRACE: { target: 'text', action: 'flush' },
        END_INPUT: { target: 'error', action: 'setEOLError' }
      }
    },
    done: { type: 'final' },
    error: {
      type: 'final',
      entry: 'throwError'
    }
  }
};

This format looks similar to XState notation but because I wrote this for a bookmarklet I wanted something much smaller. I really only needed events and actions and so was able to implement this with minimal vanilla code.

let opCode = { code: 'TEXT', modifier: null, value: '' };
let state = lexer.initial;
let pos = 0;
for (let char of [...input, EOL]) {
  let error;
  let eventName = TOKENS[char] || 'TEXT';
  let event = lexer.states[state].on[eventName] || {};
  state = event.target || state;
  pos++;
  for (let action of [event.action, lexer.states[state].entry]) {
    … perform the named action as described above …
  }
}

We set up some scoped state, our work in progress OP Code object and track the character position (for error messages). The beauty is that the act of transitioning between states in the state machine is just a matter of sending a mapped event for each character as it scans the string. How those events are reacted to depends on the current state the machine is in. The logic involved practically writes itself.

Feel free to view the full source for this utility.