Haxe.io's future

[skial]

The Haxe roundups have steadily been getting less frequent, from a weekly post to bi-monthly, then monthly and now more or less whenever I get time. The change was largely down to "discovering" content, which was around the time twitter got purchased (3 years ago?) and the first user exodus happened and everyone was finding new platforms. Throw in life stuff into the mix, the roundups obv got pushed further down my priority list.

the future?

I think for the foreseeable future, no new roundups will be published to the haxe.io website. The website was never completed and has had lots of rewrites over the last 11 years that never got published.

Instead of using a home made static site generator and being 90%+ Haxe powered, I think its time to take this time to redesign the website, using commonly available tooling.

when this going be done by?

Lets try and aim for 2026 :+1: ... :shrug: January. :shrug:

The roundup needs to get back onto my weekly schedule and I plan to get back to publishing the roundups monthly.

next steps

I've got a couple months worth of emails, content and issues to go through. I will also post an outline and my thoughts on what work needs doing to the site.

until then

Until Haxe.io is back up and running again, if you haven’t already, go join the Haxe Discord server, they regularly host Haxe roundup roundups.

All the people behind the Haxe Discord servers success should be proud of what they've created & fostered, it is a great community resource. :clap:

[m0rkeulv]

may i suggest that round up 731 get published with some of this information on top? It would be nice if the average visitor (that probably don't follow links to github issues) knew the lack of updates is temporarily and does not mean the page is dead.

[skial]

Thats a good point @m0rkeulv you're right the average user wont come to the github issues 👍 I'll try and make time to do that, hopefully this week, or I'll just link to this issue from the front page which would be quicker... plus update rss & socials.

[jobf]

Thanks for keeping it going @skial 11 years is a long time!

If you want the community to help in any way, don't be afraid to ask.

[SeiferTim]

@skial I stole the idea from you for my https://github.com/stlgamedev/STLGameDevRoundUp please feel free to steal as much code or logic as you want from me!

[skial]

Thank you @SeiferTim 🙏 I'll have a good browse to get an idea of how it works. And thank you @jobf, I've had a couple other people say the same to me 😬

[l0go]

Adding on to what @jobf said, I would be very willing to help if needed. Thanks so much for keeping this going for so long!

[ConfidantCommunications]

@skial Glad to hear things are still good!

[skial]

Thank you @l0go & @ConfidantCommunications. @l0go I'm def going to need any help you and others are willing to offer. 👍

[skial]

Haxe.io next steps

TL;DR

Aim to keep it simple. Everything should build off the markdown & data files. HTML & CSS should be kept lightweight, no unnecessary JS or cookies/tracking.

I've been out of the web dev circle for a few years now and out of coding for nearly a year, any advice would be of great help.

Current Setup

• Hosting via S3 & CloudFront
• DNS via Route 53
• The "builder" is a custom server/client electron app, comprising of:
  • md plugins/rendering
  • custom md
    • Uses simple link reference definitions as a custom version of front matter.
    • Uses the h5 header & text "In case you missed it" to indicate collapsible sections.
  • custom templating

  • I think it was based on the original idea of html <template>, before shadow dom was added.

  • csp/sri
  • critical css
  • screenshots
  • sitemap
  • minify css & fonts
  • verify various html elements exist & are formatted correctly
• various scripts to further minify & move/copy files to final locations

Goals

• The markdown and data files (various json/csv) are the source of truth & everything else should be built on-top of or generated from these.
• Keep it a static site, avoid server side features as best as possible.
• Progressive enhancement/mobile first.
  • The site should render without needing javascript. One of my many pet peeves of the modern internet. 👴
• Useful frontpage.

Future Goals

• Search
• Data extraction
• Automatically submit links to wayback machine
• Effective way to label content that has used generative AI
• Newsletter.
  • But I'm not entirely sure how useful this would be?
• Automate repo tasks, checkout & borrow from https://github.com/stlgamedev/STLGameDevRoundUp

Nice to haves

• Reduce the use of AWS, as haxe.io can likely can be run for free somewhere.

Previous Attempts

• Various unpushed https://github.com/skial/haxe.io branches.
• https://github.com/skial/haxe.io-builder currently private 🔒
  • A bare-bones implementation of an md render server with an early spaCy proxy implementation, with the plan of NodeJS & Python externs being fully typed etc.
• https://github.com/skial/serve_md
  • Rust tool that processes markdown via pulldown_cmark lib, in addition it handles the custom link reference definitions as front matter and custom collapsible headers.

Changes

• Use an off the shelf static site generator, I'm currently favouring 11ty/eleventy, as its well documented & for its use of markdown-it under the hood, which is the same library used in the custom "builder" app. WebC which replaces my custom elements <template>ing system. Bundle for critical css & more. Plus there are various plugins, which cover csp, minifying, seo and more.
• I'm considering having the content/md files in a separate repo from the website repo, possibly reusing the https://github.com/skial/haxe.io-builder repo.
  • Should the "old" content be preprocessed to remove custom use of linked reference definitions & h5 collapsible headers?
• Use https://pagefind.app for search.
• Use Cloudflare Pages for hosting, CDN & DNS.

[l0go]

Everything sounds good to me. 11ty is great; HaxeFlixel, Ceramic, and I believe FeathersUI all use it. Unless anything super fancy is going on, I don't see a reason to separate into multiple repositories. 11ty doesn't really add that much complexity.

[skial]

Thanks @l0go for the feedback, and I didn’t realise they all used 11ty, I'll check them all out.