Pattern-based XML Literals Prototype: Client-Side VB.NET Running in the Browser (sorta)

Posted on by

At last, the final video in this series on pattern-based XML literals. That culmination of all my machinations! Last time I showed you all some example web controls—classes that know how to render their behavior using the standard web primitives of HTML, CSS, and JavaScript. The next logical conclusion is knowing how to render VB.NET itself to JavaScript. Check out this video as I run through three examples.

This isn’t anything radical (outside of the common use of the word meaning cool, in which case yes, it is!). This is the same technique developers all over the world use every day with LINQ and Entity Framework. Leveraging expression trees to write code in VB.NET that is then transformed into SQL and executed on another machine. I’m using those same capabilities to let me write glue code with the same convenience.

And to be clear, this is the exact same pattern I used for my Xamarin post last month. I haven’t changed it to support this new use. It’s just sufficiently flexible that it could enable this “out of the box”, so to speak. You see, because the XML pattern can instance and initialize arbitrary types, when those types make use of other types like System.Linq.Expressions.Expression that rich information is available to the compiler so things like the natural ability to convert to lambdas to expression trees just “falls out”, as we say.

An interesting bit of trivia: Originally, I did plan on (and I am proposing) extending the currently limited set of language constructs supported by expression tree conversion. However, I did not have to extend it nearly as much as planned. 1) Statement (Sub -> Action) lambdas are already convertible to expression trees in a very few cases, 2) I was surprised to learn that assignment is one of those cases if and only if the target of the assignment is a property. I’ll add that to “The List”. So, for this demo I just relaxed the restriction that syntactically the lambda had to be a single line lambda just to further clarify for viewers that this is an assignment, not a comparison. But even without that, the ingredients are all there.

The product of the whole is much greater than the sum of the parts

This is the power of orthogonality in language design. Every feature doesn’t have to be “big” if a number of smaller seemingly less sensational features can work together to produce a great result.

  • Top-level code has been independently requested throughout the years; it’s not a “big” feature to design or implement nor a massively disruptive addition to the language.
  • XML literals were added to the language over ten years ago with a narrow focus on providing a declarative syntax for using the XLinq API; it’s not a radical suggestion to generalize this useful albeit niche feature to bring that declarative productivity to other types.
  • Expression trees have also been around for a decade and members of the community have independently suggested extending the languages to support more of constructs on multiple occasions throughout the years.  

Each of these is a mere evolutionary step of 10, rather than a revolution step of 100 but 10 x 10 x 10 is 1,000! And if you think about adding JSON literals to the mix there might be even greater rewards!

What’s next?

Somewhere out there in the VB web development community is the author or authors of the next built-for-VB web framework a la DotNetNuke (originally written in VB.NET) or Suave (built for F#). My question to those community members is:

  • If you had a language with the richness of capabilities and tooling like VB.NET—things like Async/Await, string interpolation, and LINQ
  • And that language was homoiconic—you could easily get a data structure representing the code written in that language to manipulate and even translate as you see fit
  • And that language could natively describe the two most important data structures on the modern web, the DOM (via XML literals) and JSON (via JSON literals)
  • What could you do with that?

I’m personally very excited to find out!

Summary

For a few years now I’ve been wrestling with the growing complexity of modern development. It’s pretty obvious that on top of HTML, CSS, often SQL, sometimes RegEx, managing two general purpose imperative programming languages on the client and server respectively is less than ideal. JavaScript developers who want to use JavaScript on the client and server can use Node.js. VB.NET developers who want to use VB.NET on the client and server need a solution. For me it’s a big productivity boost. But for a new VB.NET developer deciding whether to start prototyping their idea in WinForms where the just have to learn one language or the web where they have to learn 3 languages, 4 frameworks, 2 package managers, … you can see why a lot of people start in WinForms even now. I love WinForms, I want to love web development too! Pattern-based XML literals will be a powerful first step in reigning in some of the complexity and I hope this post/video gave you a glimpse into how.

I’m certain I’ll probably do a one-off post showing more on this topic in the future but this wraps up the series about this prototype. I’ll decompress my design notes on GitHub ASAP and post an update on this blog when that’s done. I absolutely want to discuss a whole bunch of interesting design questions about a hypothetical VB.NET web app framework built using the techniques I’ve shown in these last two posts, but I want to be clear that that effort is orthogonal to this feature. To that end I’ll decompress a separate set of thoughts about it specifically in the post after my next one.

Until then, as always, thanks for reading, thanks for watching, please share this post, and let me know your thoughts in the comments below and/or on Twitter.

Regards,

-ADG

P.S. I really wanted to post this back to back with my last post but due to several surprised visits, I’ve had out of town house guests every week of this month. As much as I wanted to be a terrible host and neglect my friends and family to tweak my expression tree -> JavaScript visitors I failed to do so. Yesterday and today I was finally able to carve out a little time to record, edit, and upload the video and this post before even more out of town visitors arrive. Special thanks to my younger sister who is patiently waiting in another room for me to hit Publish so we can go get some breakfast.

7 thoughts on “Pattern-based XML Literals Prototype: Client-Side VB.NET Running in the Browser (sorta)”

  1. This is very interesting. The thought of supporting VB in web client programming is exciting although seemingly far off.

    Please can you provide more clarification about what you meant by “…but I want to be clear that that effort is orthogonal to this feature.”

    I was hopeful that Blazor would support VB.NET everywhere but Dan Roth’s comment at https://github.com/aspnet/Blazor/issues/171 erased that hope:

    “The Razor syntax (.cshtml) used to author the component rendering logic is C# based, and there is no plans to change that, but all of the rest of your app logic I believe could be written in VB.”

    What is interesting to me is that JavaScript and C# are quite similar syntactically and one would hope that supporting both C# and VB.NET would much broaden the appeal of WebAssembly and Blazor on the Microsoft Development Platform but it’s clear that the powers that be care only about C-style languages.

    Like

    • “Orthogonal” is a term often thrown around by language designers. It actually means something specific in mathematics but we just use it as jargon for “a separate issue”, usually to say that we can solve one thing without figuring out or doing anything about another or that we can deal with them separately.

      So, the design of LINQ expression trees is orthogonal to whether query comprehensions support extension methods. Both of them work together to create a great end experience but neither feature has anything to do with the other.

      In this case, I am proposing an open-ended feature that /could/ let enterprising VB library authors do an unspecified set of things. I’ve prototyped a few examples to demonstrate the soundness of the idea but it’s not necessary to make decisions or commitments to any of those examples in order to move the feature forward. They can happen in parallel, after, or never, and any design decisions about them, branding, dependencies on other libraries, etc, are beyond the scope of the proposal. Please note, that doesn’t mean I’m uninterested in the ideas. To the contrary, I’m more excited by them than I’ve been in a long while. It’s just that as a matter of discipline you have to deal with them separately.

      The Razor syntax is C# based. That’s a 100% true. And I don’t care. The web is big enough for have multiple languages and view engines with multiple different styles.

      So, if you look here: https://stackoverflow.com/questions/1451319/asp-net-mvc-view-engine-comparison

      There’s a list of many view engines that have been made for ASP.NET MVC. I think they’re all pre-ASP.NET Core but that doesn’t matter. They all balance trade-offs differently. Some support C# or VB or F#, some don’t. F# has an entire list of strategies for targeting ASP.NET and the web without Razor. Those ideas are built on F#’s strengths and its design philosophy (functional).

      IMO, Razor isn’t interesting for VB. Something built for VB, that plays to its strengths, and that respects is various design philosophies are interesting for VB, or at least to me.

      I’ll take a look at the Blazor stuff eventually. If it’s like the rest of the ASP.NET Core stuff there will be re-usable composable extendable logic in there. I really tried to emphasize in these posts that all the web stuff I’ve shown really is just the released bits of ASP.NET Core 2. I didn’t do anything unnatural to it (like modify its source). It IS an ASP.NET Core 2 app. It’s not that VB can’t target or run on ASP.NET Core. There’s no bouncer at the door saying “I see a call to CInt in the IL, you shall not pass”. VB lacks a proper view engine and I don’t think Razor is the best solution to that lack.

      Liked by 1 person

      • Hi Anthony, I didn’t receive notification for your response. Thanks though.

        Do you have any roadmap for this ( no pressure 🙂 )?

        Like

    • I haven’t looked at them but hopefully there’s some reusable stuff there. This post is purely to show that the proposed language feature would allow someone (it could be me, it could be you, it could be multiple others) to make and consume frameworks that do cool stuff. The specifics of how to do that stuff is up to the library author(s).

      Like

Comments are closed.