I’m trying to infer the exact requirements for this idea.
The first requirement I can gather is:
We need to store the landing page’s .html file in ipfs with meta tags.
The second requirement is a little less clearly defined:
We don’t want the user to have to download something outside their browser.
So, something that requires a build, e.g. elm-pages gets a lot harder to do.
Here are some requirements that one might want, but I’m not sure we’re aiming for:
Do we want to have pre-rendered page content? This might lead to better SEO and UX, since the time to first render is smaller.
Do we want to purge css? By knowing which styles an application uses in advance, the tailwind css files can be reduced by a lot. Note that for this we’d need a tailwind build process somewhere.
Do we want to have static sites only, or also dynamic sites? The fission landing page and swag page both have quite some custom interactivity. This way we e.g. don’t reload the whole page when clicking on links, provide form errors in a matching style or don’t have to load another page when submitting a form.
With these requirements in the back of my mind, I’m thinking of following design:
We have these artifacts:
- The fission drive (it’s already built) and everything that allows us to read and write to it from an Elm application (the webnative/webnative sdk?)
- The landing page builder (built by us):
- The aforementioned html file, the landing page itself:
- Webcomponents for interactive elements in the landing page:
Though most elements in the landing page are static, some will require interactivity. For these, we’ll use webcomponents. They can be written in elm and be used for things like:
- wrapping forms, so they don’t reload on submission
- custom form input elements which show styled error messages when validation fails
The webcomponents can just be added as script tags added by our landing page builder’s virtual-dom-to-html renderer.
I’d specifically not recommend elm-pages for following reasons:
- Elm-pages requires a build process outside the browser. Deep down in it’s dependencies is puppeteer, essentially a headless chromium for running a browser window with the Elm page running inside, waiting for the first render to finish and grabbing all html. It’s possible but infeasible to run this within the browser.
- Elm-pages is not built for this: It cares about developer experience. But we don’t want any developers, we want to use it as a tool.
- Elm-pages has lots of feature we don’t need for this:
- a preconfigured webpack for elm and content files
- ‘StaticHttp’: The ability to run http requests to fetch data for the pages at build time. We don’t really want a build process. If we want the user to fetch data from http before publishing the page, we’d just do this in the builder. I should note, however, that the landing page uses StaticHttp to fetch the latest blog posts.
- generating a metadata.json (with a required configuration) so that the app can be added as PWAs on mobile devices.
Let me know what you think. Does this help?