Taliesin

Taliesin is a frontend web framework. It is intended to be the standard application framework of the BadOS operating system, but it can also be used outside of BadOS.

Philosophy

Taliesin has the following priorities:

Product

• Immediate utility
  • over perfect solutions that may never ship
• Addressing a need
  • over making money
• Simple, text-based UI
  • over complex information architecture
• Focused workflows
  • over multitasking
• Standardized UX
  • over branding and individuality
• Contentment with what can be done simply
  • over risk-taking and pushing the limits of what's possible

Code

• Confidence in code
  • over magic that "just works"
• Test-loving code
  • not just "testable code"
• Self-sufficient code
  • that doesn't need a mountain of dependencies
• A stable platform
  • enabling long-lived, evolving applications
• Minimal hardware and software requirements
  • over the latest technology
• A framework you could write yourself
  • but be glad you don't have to

Why???

I ask myself that question a lot, too! I observe the interminable parade of new technologies, each more dubiously valuable than the last, and wonder, "why? Why??? WHYYYYY."

Maybe we're searching for the Holy Grail. Maybe we want to believe these technologies will be the silver bullet that makes programming easy. Maybe we're just chasing what's new and hip. Or maybe we're seeing real problems with the way we produce software, but we keep coming up with fantastically wrongheaded solutions.

The recent history of software-development tooling, especially in the JavaScript world, has been characterized by additive solutions to small problems. When we see something that's not working quite as smoothly as it could, we add a new tool to our tech stack to patch the problem.

The downside of this approach is that each tool we add has to be understood and maintained. New concepts and dependencies add complexity to our systems. To overcome this complexity requires arcane knowledge and overwhelming force.

• Arcane knowledge means understanding the full stack of tools you're using. To be an excellent Rails programmer, you can't be content to know just the Rails APIs, you have to understand Ruby syntax and semantics and maybe be able to imagine how you'd implement parts of Rails yourself. Occasionally you'll need to understand how Ruby itself is implemented—how else could you decide intelligently between MRI and JRuby, or understand the behavior of your "multithreaded" program?
• Overwhelming force usually means turning things off and then turning them on again. When we don't understand what's causing our problem, sometimes the only way to fix it is to start over from a known good state—which often means going back to square one.

Of course, there's a third option for dealing with complexity: create a new layer of tooling to simplify it. Brilliant! No one's tried that before.

I now believe that there are very few problems that can be solved by the addition of new entities to a system. Rather, when we encounter a problem, our first step should be to ask what it would take to remove the cause of the problem. Rather than constantly acquiring new tools that ultimately just weigh us down, we should pare down our tools and our skills and simplify our products and processes.