Top-Level Code Prototype: Scenario D

In Scenario A I talked about the 1-line program—a single statement that prints the value of some expression to the console.

The next logical mental exercise (for me at least) is, “Gee, what if you get tired of typing Console.WriteLine all the time. Wouldn’t it be great if a program could be a single expression and the printing could all be handled auto-magically?”. I said it was a mental exercise, not a practical one 😊

Outside of making expression evaluator bots really simple that idea isn’t actually great at all, but patterns I came up with to approach it are useful for applications of other project types and many many lines of code. The Process looks something like this:

  1. “What if a source file could be just a single expression?”
  2. “You know what’s an expression in VB? XML!”
  3. XHTML 5 is XML”
  4. <stuff>
  5. This video of me demostraing a VB ASP.NET Core 2.0 MVC app with an XML literal-based “View Engine”:

Special shout-out to book author, former VB MVP, and current Microsoftie on the WinForms team, Klaus Löffelmann for doing the heavy lifting on creating the ASP.NET Core 2.0 Web API project sample I used to make this demo. It really distilled things to the bare minimum which was a huge help to me conceptually and also a great time saver!

What about “Razor”?

Here’s the thing about “Razor” (Is it a code-name, do I need quotes?). It’s an alternate view engine to ASP.NET Web Forms that aims for a particular aesthetic. That aesthetic has value but is definitely designed around C# (not dissimilar from the way Web Forms was designed around VB and Classic ASP). The Razor that is part of ASP.NET MVC 5 supports VB but the experience isn’t a bespoke VB experience. I’m pretty sure it doesn’t support VB XML literals at all (and I understand why) and that whole Code / End Code block syntax, while… well-intended does show the seams a little. And when we talk about ASP.NET Core there’s no vbhtml at all. I’m really not saying this to knock Razor at all. I think it’s cool. And as a guy who spent 5 years spelunking two parsers, I appreciate the challenges of building and maintaining a component that understands the nuances of code while the user is typing—a  problem that is even harder when the language itself is hosting another language nested in it (XML)—while also wanting to provide a great tooling experience. (I appreciate in part because I was working on Roslyn when the ASP.NET team was working on Razor and Web Matrix and they weren’t shy about telling us about the challenges 😉). And new language versions present new conflicts if new features don’t play in the way your view engine was coded to support: I mean, can you imagine what Razor would do if VB added JSON literals?

But, we (VB programmers) are in luck. Because Microsoft already owns an incredibly well-tested, well-oiled, well-maintained component that knows the ins and outs of the VB language and seamlessly transitions between VB, and XML, and interpolated strings, infinitely nested with an incredibly rich IDE experience just deeply integrated into it. It’s always maintained, it can’t fall out of sync with new features, and it’s basically free. It’s called Roslyn; we should use it!

Once again, as I did in Scenario B, I’m asking “What if we invert the problem?” and instead of getting VB into the views, we get views into the VB. Or better yet use what’s already in VB to make something idiomatic and aesthetically pleasing just for us at a comparatively much lower cost?

WWFSD—What Would F# Do?

Over the years since its introduction I’ve been continually impressed with the grace, creativity, self-reliance, and pioneering spirit with which the F# community has approached being unique members of the broader .NET community. It’s incredibly easy to assume that there’s only one way to approach programming and that it’s whatever the newest way Microsoft has released or whatever way C# is doing it because it’s intrinsically good for everyone and the best anyone can come up with for all situations (until the next thing comes out). F# is very good at remaining rooted in its own identity while looking for solutions to the same scenarios that C# or VB coders face but in a way that is complementary to and often strengthened by F#’s unique capabilities.

For example, Razor doesn’t support F# either but when I hear F# aficionados talk about web programming they aren’t talking about Razor, they’re talking about homegrown solutions like Suave and Fable and Giraffe and CloudButt and other made up names that are built with F#’s differences (read: strengths) in mind.

It is my sincere wish that we, the VB community, learn from their many examples and that one day we too have a catalogue of colorful names on a web page somewhere built by us for us. This is my opening contribution to what I hope will be an ongoing conversation.


I’ve still got one more scenario to post and then I’ll do the full write-up on GitHub the ins-and-outs of the proposed top-level code feature that made this video possible. Web programming is just one potentially application of it that I thought up but there’s another guy who’s been thinking on this topic a lot longer than I have, VBAndCs. I really wanted this scenario to be a surprise but VBAndCs saw it all coming in my comments section all the way back in Scenario B.

I have another planned prototype in my head that would go even further on this scenario that I hope to put out later and I’m really looking forward to seeing what awesome tailor-made experiences passionate folks in the VB-Web community like VBAndCs can build given the right language tools.

Share your feedback with me, share the video with your friends. And as always, thanks and see ya later!



7 thoughts on “Top-Level Code Prototype: Scenario D

  1. I like this effort…and the link to VBAandCs tools as well. I hope it sparks some interest for contributions from other VB aficionados out there.


    • Thanks BPech (I am VbAndCs). I listed some of the challenges in my reply, and share your hope that VB community help me to overcome. Some issues are difficult to solve without Roslyn experts like Anthony, but others can be solved by hardworking developers, such as writing new tag helpers valid for use with vbxml code, so we can have a full functional new VB.NET View engine. In my experiment with Vazor and ZML, I added some new tags to shorten some Razor expressions (such as `Foo` instead of `@{ ViewData[“Title”] = “Foo”; }`. There are many things we can do to make designing web views faster and easier. But first, we need the intellisense support for html5 tags in vbxml code, and for z: tags in .zml files opened with html editor.


      • Sorry, the zml expression for title is not displayed because it is considered an html code! I will encode it here. It is: <z:tiltle>Foo</z:tiltle>


  2. Nice work Anthony. I am honored to be mentioned here (as VbAndCs).
    Thankfully, you achieved my wish to write a pure vbxml code without the need of a class\function decoration. It’s great 🙂
    I am working on VB Views for about three months now. XML literals are promising but I faced many challenges. Allow me to summarize them here:
    1. The intellisense support for XSD schema stopped working since VS 2015, so, there is no easy way to write HTML5 tags without auto completion. This issue is not related to XML literals only, but also XML and HTML documents. I reported this here:

    2. Embedding a value in XML literal is easy, but in ASP.NET we need also to generate html from for loops, and use if statements. This will need to call some functions to generate those sub xml literals, which can be done inline by using lambdas. The problem with that approach is that it makes the code longer. But with your brilliant Top-Level Code Prototype, it is possible to write the code directly to be added in implicit function. I suggested to use the “ as a quote for this purpose. I am looking forward to see this in a new scenario soon. More details about this here:

    3. There are some limitations of using XML literals, like refusing many texts encloding the `&` such as `©` . Encoding the `&` will not solve this. The only workaround is to use any replacement text for the & like __amp__; and restore it when getting the string representation of the XML literal.
    I reported such things in this topic and my replies on it:

    4. It is not easy to ignore Razor tag helpers nor reinvent them for xml literals. In my first implementation for Vb Razor( I used a simple view engine to render the vbxml code. But I soon abandoned this, and created Vazor which uses a virtual file provider to deliver a cshtml content to Razor. This allows me to write vbxml code containing Razor tag helpers, so VB evaluates VB code, and Razor evaluates tag helpers. You can find two sample projects in Vazor repo (, one for MVC views, and the other for Razors pages.
    But I faced some difficulties with some tag helpers especially inside for loops, so, I created ZML: an XML tag syntax to represent programming statements such as loops and if statements. First I used ZML inside xml literals to represent Razor directives and solve some for loops issues. I am using this in the eShopOnWeb sample project in Vazor repo, but note that I only converted pages in the Pages folder, and still working on the rest.
    Then I realized that ZML can be used alone to create language-independent views, which can be compiled at startup to cshtml files, so no need to the virtual file provider (and Vazor) any more. I created ZML repo for that purpose ( and it contains a full working version of the eShopOnWeb project, with a C# and a VB.NET versions, both using the same .zml view files!
    Still, the big issue in Vazor and ZML is the lack of intellisense support, which makes them useless because no one except me can use them easily in production!
    So, I need to get back the xsd intellisnse support, and it will be great if Roslyn has a mechanism to apply VS.NET built-in editors on some string and xml literals (marked with some attributes or something).

    I think you are very near from these areas, and your great Top-Level Code Prototype can help to achieve many of them.


  3. Pingback: Top-Level Code Prototype: Scenario E | Anthony's blog

  4. Pingback: Pattern-Based XML Literals Prototype: Introduction | Anthony's blog

  5. Pingback: Pattern-Based XML Literals Prototype: ASP.NET Core Revisited | Anthony's blog

Comments are closed.