Today, I wondered if the elm compiler could generate static html, which I just tried intuitively like so:
module Test exposing (..)
import Html
main : Html.Html Never
main =
Html.text "test"
I didn’t really expect it to work. I just was like ‘Maybe, who knows, why should it generate javascript when there are no dynamics ?’ - Yes, it created a html file, using javascript to render, including the elm runtime (as ‘expected’ …)
I wonder if this could be made possible somehow in the future ? It just seems so natural to me, to also use elm for modular static html content, with all it’s benefits.
I think it just fits very natural this way. I know there is for example elm-static, but it is using a node.js DOM and feels rather not so natural (‘is this the elm way ?’) to use for me, since it has a lot of boilerplate and structural complexity behind it.
If I see this code snippet, it just feels right to me, to generate static html this way (or similar).
Maybe there could be a built-in custom type like ‘Static’ which could indicate to generate html ? Like ‘Html Static’ instead of ‘Html Never’ …
This is in the domain of what a community tool might care about, but my two cents is that it wouldn’t make sense for the Elm core compiler and tooling to care about this. You could achieve this result of converting a main : Html msg into a static, JS-free HTML file using the existing compiler and ecosystem of tools. If jsdom doesn’t work well, puppeteer is a really great tool that you could try. Sounds like this is an idea that you’re passionate about, so if you do some experiments and find that it would make a good tool, maybe you’re the community member to build it!
The way I think think of these different tools, they each focus on solving one problem well. The better a job they do sticking to that clear approach and vision, the more delightful those tools tend to be. Sometimes that means that another tool is needed because it’s outside of scope for an existing tool.
elmstatic is essentially Jekyll for Elm. That is, it is opinionated about a certain structure of content files that are converted into static HTML pages. If that works well for your problem, then that’s a great tool for you. If your goal is to convert a single main : Html msg into a static HTML file, then that tool would not be a good fit.
But neither would the Elm compiler. The job of the Elm compiler isn’t to build static websites for us. It gives us the building blocks to do that. I think that The Extensible Web Manifesto is a great example of that philosophy. Provide the low-level building blocks, rather than trying to assume very specific use cases. If core tools attempt to build exactly what each specific use case requires, then we end up with tools that 1) are bloated, and/or 2) aren’t able to address use cases they didn’t imagine. So this is not the role I see for the Elm core tooling.
But it’s a nice, simple idea, and maybe others would find it useful. Those are the makings for a good tool, so I would encourage you to try building it if you are passionate about it!
You could achieve this result of converting a main : Html msg into a static, JS-free HTML file using the existing compiler and ecosystem of tools.
I can’t see a good way of doing it this way. The problem I am seeing is: I can’t see a way to access the whole document (including <head> for example) with the elm architecture… So if I would just print my elm/node.js Dom to stdout, wouldn’t it be missing something, which I am in no direct control of ?
I understand your points, but I think it would make a lot of sense for the compiler to care about this.
Have a look at this topic: "Native Code" in 0.19
There is this entry:
Portability. Elm will likely compile to WebAssembly some day. It may target other domains, like servers where there is no JavaScript. It would be hugely valuable if the entire Elm ecosystem works across a boundary like that.
What I am basically thinking about is, is adding another compile target: Html.
If that would be possible, you would even have a basic approach to generate Html in the backend for servers natively.
Since there is no way in Elm to interact with stdout directly, creating specific tools like this, is somehow something, which runs outside of the scope where the Language itself might go. For example, I wonder what would happen to those tools, if Elm would switch to WebAssembly as a compile target ?
I think this is a separate question than the original question of whether Elm should be concerned about rendering HTML with no JS in the specific use case where you have main : Html msg. I’ll set aside the question of whether it would make sense for Elm to provide the ability to include head tags in pure Elm so that the conversation doesn’t go off in too many directions.
Both elmstatic and elm-pages have ways to include <head> tags. Both of those frameworks accomplish that through the use of ports, so really the sky is the limit for what you can encapsulate as a framework author there. If you wanted to, you could use one of those frameworks to build your tool. Or you could see how those codebases implemented it for inspiration for a new tool. The basic building blocks are there already, though, it’s more a matter of taking the time to put them together and encapsulating things in a framework.
I’m not sure I’m understanding how WebAssembly would change the situation. It seems like you’re describing some functionality like Server-Side Rendering now, but I’m not quite sure what use case you have in mind. SSR is another separate topic. Whether or not Elm builds in SSR functionality, I think that’s a separate issue from whether it should render different output if you have a main : Html msg.
My perspective on that particular question is that the Elm compiler is a tool for compiling and outputting Elm code. If an app happens to use this specific feature of Elm of having main : Html msg, I still see Elm’s job as building the Elm code that would generate. If you want the specific problem solved to get pure HTML from an Elm module like that, then Elm already gives us the building blocks we need to accomplish that.
The questions of whether it would make sense for The Elm platform providing a way to define <head> tags in Elm, or do Server-Side Rendering, are interesting topics. But I think they’re separate from the original question. There was some discussion about SSR recently.
Anyway, hope that helps. If you decide to do some work exploring building a framework like that, I’d be happy to answer questions from what I’ve learned building similar features for elm-pages.
A tool of this kind for Elm would be cleary a cool thing, as long the language it self doesn’t support ‘compile-to-html’. Maybe I will get into it !
However I realized that elm is (yet) not the right tool for my purpose. Therefore I went with Python and Yattag to generate Html in a clean and simple way. You can read about my purpose here - Maybe you can understand my issue with elm in this case better then. Greetings