Paul HudsonIn November, I released Inferno: an open-source collection of Metal shaders for SwiftUI developers, making it easy to create gorgeous special effects in your iOS apps. https://github.com/twostraws/Inferno
Two months later, I released Vortex: a high-performance particle effect system for SwiftUI, so you can bring effects such as confetti, fireworks, fire, and more into your apps. https://github.com/twostraws/Vortex
Today, another two months later, I just released my third and final open-source project, at least for now. It's called Ignite, and it's a Swift static website generator. Your entire site is written as Swift code, then compiled to HTML, JavaScript, and CSS. https://github.com/twostraws/Ignite
Why is Ignite different from other Swift website frameworks?
- Your sites automatically adapt to mobile, iPad, and desktop.
- You get modern web components in Swift – accordions, carousels, dropdowns, and more just work.
- Accessibility is baked into your HTML out of the box.
You can build a whole website using Swift if you want, or bring in Markdown and have those files become pages – it builds on Apple's fantastic swift-markdown library for lightning fast Markdown parsing. Just like Jekyll in Ruby, you can select layouts right in your Markdown.
It has a delightful, SwiftUI-like API, and where possible I've used similar names for elements and modifiers – get started by cloning the starter template. But it's built for the web: not replacing CSS/JavaScript, but building on top of them so you get great results fast.
I've gone out of my way to document all the code as best as I can, and there's a new sample website that demonstrates a wide variety of controls alongside the code it takes to produce each piece of output: https://ignitesamples.hackingwithswift.com
Ignite is open source and available today – I'm grateful to the folks at @tryswiftconf for giving me the chance to announce it. There are *so many* small ways anyone can get involved, and I would really love to see folks helping no matter how small the contribution.
In particular:
- Write a small code sample demonstrating using one element.
- Write just one test, proving that a given Ignite element configuration produces the correct HTML output.
- Submit fixes for typos, unclear comments, and more.
It's all welcome! 🙌
If you're not sure about making a pull request, I'm happy to help! And once you've managed it once, I promise the next once is easier. There are *lots* of opportunities to get involved, so please do ✨
Frederic Barthelemy@twostraws I'm super interested in this project! Burnt out on package.json and friends after 10 years of it.
If we have questions about the project, how would you recommend one asks? Is Mastodon the right place, or a github issue? Somewhere else?
@twostraws I've filed a few feature requests! Happy to contribute implementations if you agree with them!
@fbartho An environment() modifier would be *epic* and most appreciated – I'd love to see this implemented, and would really appreciate a PR from you for it! Gosh, if we could nail that, then we could perhaps use property wrappers to access things like site/content data, rather than relying on the publishing context being passed around.
@twostraws I’ll take a look at `environment()` — probably on Monday or Tuesday! (Though I could be fooling myself in thinking I’ll be able to avoid trying it tomorrow)