Framework for Tomorrow’s Web

I am trying something new here. Instead of blabbering and shaking wrinkled fists like a cranky old man, I’ll turn my lemon into something with a bit more kinetic oomph. Like a two-by-four. Kidding! Kidding…

If you’re like me, you’re fascinated with Web frameworks. You’ve dabbled in all of them, finding likes and quirks, but ultimately walking away wanting more. If you’re like me, you’ve kept a mental wishlist of what tomorrow’s Web framework should be like. Here’s mine, in no particular order:

• Framework for Tomorrow’s Web (FTW for short) Speaks Web natively. No extra work is needed by a developer to take advantage of the full HTTP spec potential. GETs are idempotent. POSTs are free of abuse. Etags are meaningful. Did I mention they just work?
• FTW is intentionally and unapologetically stateless. On the other end of a request, there is a representation of a resource whose change is strictly a function of time. Personalization and other shnazzy Web 2.Poo junk are accomplished by client-side composition.
• FTW is architected outside of a single server boundaries. Parallelism and massive scalability are part of the deal. Spreading your application across several nodes does not require redesign or even changing a line of code. Perhaps even, the framework does it automatically, expanding or contracting its physical machine span as a reaction to traffic.
• Just like we grew out mallocs and frees, with FTW, we no longer worry about caching. Caching is effective and completely behind the scenes. FTW developer does not know anything about dependencies, re-syncing, or sliding expiration scales. Caching just happens. No tinkering is necessary.
• FTW respects the markup. If asked to produce xHTML, it outputs minimalist semantic markup that is free of presentational dribble. It may actually prevent the developer from tossing crap onto the representation.
• In FTW, you develop using a a strongly, dynamically typed language. Ok, this one is not really a tomorrow’s feature by most accounts, but we .NET folks are still calling them futures.
• The framework consists of two integral parts: the server-side and the client-side. The client-side part is treated with the same respect as the server-side. They’re equals, except one manages content, and the other manages presentation. In this respect, FTW is not a hodge-podge of multiple technologies that spans several disparate projects.
• Layers of abstraction are drawn along, not across the separation of concern. In fact, FTW manages separation of concerns. It is developed to support best practices, unified into an intuitive, thorough methodology. You know, the one that doesn’t begin with ‘spose you want to build a Web form.
• Finally, the FTW‘s architects realize that Web is most naturally modeled as a graph. Instead of messing with tables and rows, the developer creates representations and establishes relationships between them, never departing from hypermedia to another the data abstraction. Dare I predict the end of reign for tabular data, my SQL homeboys? Meh. We’ll see.

I could probably list more items, but these seem to capture the spirit. Speaking of spirits, it’s Friday night. Enough writing. Thank you for reading. Y’all come back now, ya hear?