chrono VS askama

The problem is that this effects higher languages too, because they often build on libc. And on some OSes, they don't have a choice, because the system call interface is unstable and/or undocumented).

For example in rust, multiple time libraries were found to be unsound if `std::env::set_env` was ever called from a multi-threaded program. See:

https://github.com/time-rs/time/issues/293 and https://github.com/chronotope/chrono/issues/499

https://github.com/rust-lang/rust/issues/27970

https://github.com/rust-lang/rust/issues/90308

> I think library authors should be more relentless and break compatibility every few years. We just need some conventions to not do so very often.

I indeed did this years ago---I'm the original author of Chrono [1]---and it wasn't well received [2] [3] [4]. To be fair, I knew it was a clear violation of semantic versioning but I didn't see any point of obeying that until we've reached 1.0 so I went ahead. People complained a lot and I had to yank the problematic release. By then I realized many enough people religiously expect semantic versioning (for good reasons though) and it's wiser to avoid useless conflict.

[1] https://github.com/chronotope/chrono

[2] https://github.com/chronotope/chrono/issues/146#issuecomment...

[3] https://github.com/chronotope/chrono/issues/156

[4] https://github.com/chronotope/chrono/blob/main/CHANGELOG.md#...

On that note, it would also be good to configure cargo-deny so that a CI pipeline and any maintainer can easily audit the current dependency versions. Sometimes CVEs require a new major semver (looking at you, time 0.1.x and thus chrono 0.4.x), so it's not enough to rely on people installing the tool with semver-compatible updates. Automatically auditing dependencies is really important, and given how easy cargo-deny makes it, I don't think many projects have any excuse not to configure it.

The example has been randomly taken from the [Chrono][https://github.com/chronotope/chrono/blob/main/src/offset/utc.rs] crate.

libc isn't "just a wrapper". Is a massive legacy codebase filled with hacks, UBs and bugs: https://github.com/chronotope/chrono/issues/499

Would love to have people test this, you can leave feedback here: https://github.com/chronotope/chrono/issues/674.

Security issues? I'm looking at the open issues, but haven't noticed any that seem to be security related (no security related labels either). What am I missing here?

I have inlined the CSS here, and you can use Rust-based tooling like Lightning CSS to minify and bundle CSS here. You might also want to create a Rust build script to generate the HTML from a template, using the askama crate (works a little like Jinja).

This adds askama itself as well as the Responder trait implementation for the askama::Template type. askama expects your files to be in a subfolder of the project root called templates by default, so let's create the folder and then create an index.html file with the following HTML code in:

You can also use HTML templating with crates like askama, tera and maud! This can be combined with the power of lightweight JavaScript libraries like htmx to speed up time to production. You can read more about this on our other article about using HTMX with Rust which you can find here.. We also collaborated with Stefan Baumgartner on an article for serving HTML with Askama!

This is such a great project, thank you for sharing! It seems like you're getting the usual dump of negativity around HTMX... but as usual, not much coming from anyone who's actually tried to build something small/medium-sized. I keep hearing that this stack "would" fall apart in a bigger project, but I never hear any concrete, empirical descriptions of issues that actually do arise.

I'll offer one here... using HTMX usually means you're going to be writing HTML templates, and HTML templating languages don't have much IDE support. I really miss goto-definition etc. when I'm writing Jinja templates.

That being said, I've personally found Rust/HTMX to be a magnificent combo. I personally find writing backend endpoints in Rust to be no more cumbersome than any other language (after becoming comfortable with Rust)... and there's massive gains from the incredible tooling and type system.

I wonder if you've considered using Askama for your templates? It has a Axum integration that cleans up some of the boilerplate around template rendering. There's also an open PR for block fragments [1], which will make componentization of HTML fragments much easier, as discussed in this essay on the HTMX site [2].

We need more projects like this to demonstrate how useful, highly-interactive apps are made with HTMX. I'd encourage skeptics to try the same before writing it off.

[1] https://github.com/djc/askama/pull/824

This templating languge / engine is heavily inspired by Askama, but brings more rust into your template code. The project is still in early stages and is likely filled with bugs but I wanted to get something out there to get some feedback on.

Askama

Rust allows me to mainly only run the application to confirm things work from a business perspective.

For people starting out building stuff in rust - understand that there is a distinction of async code and libraries and can lead to confusing compiler errors if you don't realize there is a distinction. It's simple in hindsight but did cause me to waste hours barking up the wrong trees at first. Other wise just learn about `match` and Result/Option types asap, they're fundamental.

https://github.com/http-rs/tide tide is great to create an http server / routes

https://github.com/djc/askama I use this to template out HTML and it checks all my boxes, dynamic data, passing in functions, control flow.

https://github.com/launchbadge/sqlx sql interface for a variety of backend, async safe.

https://github.com/seanmonstar/reqwest http client to make requests

Rust is amazing, don't let the initial few speed bumps discourage you - building real things with rust is no more challenging today than any other modern language stack.

I also Suggest using https://crates.io/crates/askama for Templates. even though it can be hard to get use to and they are compile time only It allows you to use Rust functions directly within the Template code. Which can make your life easier.

It was a bug in askama that was fixed. The solution is to use a newer version that contains the fix, but they have not released a new version of askama since fixing the bug, so 0.11.1 still contains the bug. It seems like 0.12 has been a long time coming but should finally be coming soon: https://github.com/djc/askama/issues/722

A good example is Askama, which should look good to folk from the python / django / jinja world: https://github.com/djc/askama