Inception Discussion

[librasteve]

PLEASE DO CHIME IN WITH YOUR THOUGHTS

My personal idea for this module is:

To have a raku module that does this set of things around HTMX (see htmx.org):

• write web pages in an "Elm-like style" in raku
  • export all HTML tag names as raku subs
  • provide HTML tag attrs as raku attrs
  • maybe with error checking but this can come later
• support HTMX on the same level as HTML
  • the idea being that with HTMX we can write a somewhat dynamic site without needing a framework
  • usual caveats about HTMX not suitable for web apps like Google Maps or very high scale deployments
• do something sensible with CSS
  • initially mirror the CSS approach used in the source of the htmx.org site
  • open to consider other options (tailwind, bootstrap...??)
• provide a script that can be hooked to directory changes to rebuild the html
  • eg. mypage.rakuhtmx => mypage.html (with the htmx script included)

Here is my take on "Elm-like style" from here

Note that this module conceptually is aligned just to Elm import Html and import Html.Attributes and deliberately excludes the more dynamic bits of Elm which is why this example is chosen as representative. Why not - well dynamic behaviours come from HTMX!

module HomePage exposing (main)

import Html exposing (..)
import Html.Attributes exposing (..)

view model =
    div [ class "jumbotron" ]
        [ h1 [] [ text "Welcome to Dunder Mifflin!" ]
        , p []
            [ text "Dunder Mifflin Inc. (stock symbol "
            , strong [] [ text "DMI" ]
            , text <|
                """ 
                ) is a micro-cap regional paper and office 
                supply distributor with an emphasis on servicing 
                small-business clients.
                """
            ]
        ]

main =
    view "dummy model"

So in raku source code style, that would be something like:

use HTML::Functional;

my $page = HTMX.new;

$page.body =

    div (:class<jumbotron>,
        [
        h1 "Welcome to Dunder Mifflin!",

        p  "Dunder Mifflin Inc. (stock symbol {strong 'DMI'}" ~
            q:to/END/;
                is a micro-cap regional paper and office 
                supply distributor with an emphasis on servicing 
                small-business clients.
            END
        ] );

Hopefully the syntactic intent of using standard raku quoting, sub & attribute constructs is clear - even if I butchered the example a bit.

There would be decent defaults for header and so on to avoid having to do the boilerplate incantations.

[librasteve]

Sometime back, I wrote these blog posts that chose a slightly different, but relevant approach:

• Doing Some Funky HTML Sh*t with Raku
• Can Raku replace HTML?

would be cool to use @codesections ¶ proposal

[librasteve]

I am realising that the big hole here is setting up the htmx server side, maybe with Hummingbord or Cro

Here's an example of that done with Flask that maybe we can steal https://github.com/markusbnet/flask-htmx-demo

[wayland]

So, despite my lack of Tuits (including round ones), I've spent the day thinking about HTMX (though not specifically for Raku). I've realised the way I think make sense for my context is:

• Write my site interface in XML (at a moderately high level of abstraction)
• Use XSLT to transform that into WebComponents and HTMX
• Let the browser deal with things from there

Note that that's specifically the interface, not the content. Not sure if that'll help, but wanted to mention it. HTH!

[wayland]

Oh, and for HTMX and XSLT, see https://v1.htmx.org/extensions/client-side-templates/ (XSLT example is near bottom of page, though it's probably not how I'd do it).

[wayland]

Absolutely did not make myself clear. The point of writing the interface in XML and then transforming via XSLT is that, if we want to replace a given Web Component, then all we have to adjust is the XSLT that transforms it into the WebComponent, and voila, it's changed across the whole site -- it makes it easier for us to change WebComponent frameworks, which increases the level of backwards compatibility.

HTH,

[librasteve]

@wayland - thanks for your very interesting input

my initial thoughts are that we should aim for a tree, something like:

• htmx
  • _ (ie base)
  • write html / htmx in raku
  • patterns to keep swaps local [1]
  • deploy script [2]
    • front end
    • back end
  • servers
  • file store
  • database
  • web framework
    • Cro
    • HB
  • transformers
    • eg store as XML
  • extensions [3]
  • client-side
    • moustache (that's my favourite btw)
    • xlst

... and so on

[1] this is my next todo [2] hopefully we can figure out a pluggable deploy script [3] something like back ends for front ends

... anyway this is a very lavish vision - and starting to feel like Cro is the best framework since it has transformers and database built right in

... now I said that looks like Cro context is a good pattern for (template format agnostic) hydration of parameters as per https://wordpress.com/post/rakujourney.wordpress.com/432

[wayland]

Hi!

I'd recommend not adding XSLT just for me (though add it if you like it), because my vision of a web frontend is more like:

• All components built out of only HTML and CSS where possible (the latest CSS has enough power to do at least a full menuing system with dropdowns and everything
• Write XML/HTML in XML/HTML, not in Raku (though with the right Slang, we could embed XML in Raku, and have it syntax-checked for us by the Raku compiler) <-- I think this is the point where we differ the most

HTH some.

[librasteve]

I am closing this since this project is now somewhat down the road and past inception - please feel free to comment on existing Issues or to raise new Issues if you have any contributions or feedback.