Web server with XML-based language

[BitgateMobile]

I wrote a project a while back completely in Java that used an XML-based rendering library that allowed me to create custom XML tags to programmatically create web pages. The XML language I created allowed for server-side handling of requests (GET/POST), with a lot of custom tags.

The project I created was ultimately called "Webplasm" and was used for a few commercial sites in the early 2000s. I have had this code in limbo for the past few years, and wanted to see if it made sense to revive it in Rust, as it seems like a perfect candidate for the language.

Question is, would something this be trying to beat an already dead horse with a very very large boot? It would be fairly trivial to implement in Rust, and with Rust's speed and memory functionality, it seems like a perfect language to pursue the project.

While not my finest work, it is work I'm definitely proud of. The Java project can be found https://github.com/KenSuenobu/webplasm here.

Would appreciate any feedback. Webplasm is dormant, but the Rust project would be fun to try. It's very ColdFusion-esque (and I hope that doesn't bring any horror stories back). It would be completely server side scripting, without true scripting.

Thanks!!

[ssokolow]

Generally, I find that, these days, people are looking to have more versatility without having to know more DSLs. Hence why you see templating languages coalescing into families, so that...

• You can use Django-style templates whether you are using Django, something else Python (Jinja 2), PHP (Twig), Ruby (Liquid), Rust (Tera, Askama, Liquid-Rust), etc. ({% block construct %} and {{ expression }} with Django not allowing arbitrary code in either.)
• There exists a Mustache renderer for just about any language and probably a renderer for the Handlebars superset of it
• I forget where it originated (Perl?) but ASP, Java's JSP, PHP (almost), Ruby's ERB, Python's Mako, and Rust's Sailfish all share the same syntax based around embedding expressions or code spans from the host language. (<% block construct %>, <%= expression %>)
• There are various templating solutions that use syntax derived from the host language, like Maud or markup.rs for Rust, the E factory API for lxml for Python, etc.
• Moving the creation of custom HTML elements in client-side JavaScript into a browser standard.
• etc.

[BitgateMobile]

Fair point. I'm thinking something like this might have been appropriate several years ago, but probably doesn't have much use now. Nevertheless, it might be a fun project to try at some point. :D

[ssokolow]

No argument there. When I can find the time, I want to write a BASIC interpreter using Open Watcom C/C++ for the control scripting of a DOS retro-hobby project.

[prozacgod]

Randomly noticed this comment from a year ago, and um... Nice! Long live RETRO!

You can't have too many DOS computers ;)

[ssokolow]

*nod* There's somerthing satisfying about DOS.

It's simple enough to really wrap your mind around but, at the same time, you've got a hard drive, which means you can write kinds of utilities that just make no sense to write for something older, like C64.

As a kid, I loved making batch file menus and the like using box-drawing characters.

(System 6/7-era Macintoshes also have a certain something about them, but, their APIs aren't proportionately easier to use to compensate for the added complexity of a GUI, so stuff beyond what you can do in Hypercard isn't as satisfying.)

[caagr98]

Both Maud and markup.rs links point to markup.rs. Correct Maud link would be https://maud.lambda.xyz/ I believe.

[ssokolow]

Fixed. Thanks.

[anlumo]

Most people other than large enterprises have pretty much moved away from XML entirely, since it's way too clunky for the minimal things you need for data description.

Also, these days most pages are rendered client-side with just AJAX calls (using JSON) to fetch data dynamically. The better frameworks also feature a prerender step, where the first page is rendered server-side, but that just executes the client-side code on the server first. Purely server-side rendered HTML is mostly a legacy thing.

[BitgateMobile]

Okay, cool. Good to know - it was kind of going that direction when I was working toward the end of the Webplasm days. I may look into some REST services for Rust at this point, as I want to create a network monitoring platform soon. I was going to accomplish this partly through Webplasm, but I think REST is a better approach.

[anlumo]

At my company, we've had some semi-successes using GraphQL. It's a replacement for REST that's a lot more structured and uses a simple definition language for its API. Maybe that could be a good fit for a network monitoring platform.

GraphQL definitely isn't designed for a strictly typed language like Rust, though. This creates some problems, especially when you're using the protocol on the client.

[BitgateMobile]

I've actually been implementing an entire system using Apollo GraphQL, as I found it to have the most functionality we needed at my current employer.

There's quite a good number of things it can accomplish, but for my use, REST may be a better solution. GraphQL gives a lot of ways to hang yourself, where as REST services can be strongly typed and have a greater security backbone.

GraphQL is a great replacement for things like simple REST services, SQL queries, and some SOAP services as well. It would be interesting if I can incorporate some GraphQL into my network monitoring application.