I’ve been working with web development for a few years, and have picked up on quite a few inconsistencies and complications with the tools available out there. Lots of people have tried fixing the problems, but it seems in the end they all wind up building on top of a broken foundation, and it comes crumbling down; everyone leaves the “fix” and either returns to the classic methods of web dev or seeks a new remedy for their problems. You’d think, in this case, that the best thing to do would be to start all over and build up a more robust foundation, but with the massive adoption these common “broken” technologies, convincing all the developers and designers out there to adopt a new paradigm and trash the decades of accomplishments we’ve already achieved is nigh impossible. Heck, I’ve seen people try to build new languages and browsers designed specifically for them, but even those efforts have remained fruitless. It would seem we’re stuck with the traditional combination of HTML and CSS for the rest of eternity, gradually revising features until we get something that’s still only marginally better.
That’s why I made Vanguard. I had the idea to create a sort of website-compiler, with 3-4 languages designed for templates, styling, content markup, and configuration, but after I got started with the first language — the one originally going to be used for content markup — I realized I had something special here. I expanded upon the idea and stuck to the idea of flexibility, extensibility, and robustness, and ended up with a very minimal yet practical language, which I named Vanguard. It takes up way less space for markup and styling than HTML and CSS yet provides a ton of functionality that neither language could ever dream of possessing, like property inheritance heirarchies and no explicit end tags (yay! not really functionality, but still a grand feature). I am currently still in the process of defining the language — which is going on over here, by the way — and will soon move on to writing a compiler for the language; if you want to contribute anything, I’m usually on IRC at irc.awfulnet.org in the #vanguard channel as cdh473.
Another goal of mine was to devise a compact language which could easily be interpreted directly by a browser — in case a hobbyist programmer or something came along and wanted to help out a bit — without any historical artifacts carried over from the previous technologies. Of course, the basic application of the language will be quite familiar to those who are already accustomed to HTML and CSS, but the clean-up work that’s been taken care of as well as the new paradigms available in the language, in my opinion, vastly improve the experience.
I chose a syntax similar to s-expressions for multiple reasons. The first was that, in my experience with other languages based on them (such as Lisp and its variants), they provide unrivaled flexibility; code can quite easily be dealt with by other code, and it allows some really neat tricks. With Vanguard, type declarations allowed me to combine multiple [partial] expressions and apply them as new types, which allows some tidy markup choices; it also helps to further separate content from the layout: the document writer can place his/her declarations in a separate file and use them inside the actual document, changing them externally as necessary. The second, more minor (yet still nice) reason was that it, paired with whitespace syntax, totally removed the necessity for ‘end tags’ as in HTML. Now, if you want to create an inline expression, you just enclose the content with the ‘]’, so you really end up typing a lot less than you would in HTML.
Whitespace syntax can be found in languages like Python, where it is essentially required; other languages, such as C and Java, do not require it, yet they still encourage the use of proper whitespace formatting. Vanguard does not force one to use its whitespace syntax, but rather rewards those who make use of it. If I, for instance, write with explicit expression ends (‘]’), I end up with harder-to-read markup (that is still legible, mind you), but no real advantage. If I were to make extensive use of whitespace syntax and properly format my document for it, I get very neat, clean markup that is easy to work with, as it does not have bizarre, unnatural-looking expression ends. This should encourage people to use the special syntax as much as possible, while evading the issue of complaints such as those of Python’s forced whitespace syntax, I mean, whitespace syntax isn’t even in the language after expansion! This brings me to my next point:
Vanguard’s core.
In my efforts to devise a minimal language, I faced the issue of figuring out how to add all these cool, extra features, as well as how to add later features atop such a tiny base language. I decided I would set aside a subset of the bare minimum functionality, define a solid standard for it, never to change it (drastically), and construct everything else in what became the expander. I also separated the types from the core and put them into a sort of class with the expander, being in their own type library and whatnot. I’m certain that this separation would allow use of Vanguard in other areas as well, such as domain-specific content markup and something akin to what XML does.
After all of the work put into Vanguard, I am very confident in its future and will continue to evolve it as a language, putting it to the test in my own projects and (hopefully) watching others use it for theirs. If you have any suggestions or questions, leave me a comment below.