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.

Conclusion

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!

Regards,

-ADG