Attempt at adding Native support for core

[zetashift]

I have no idea what I'm doing :P.

I basically copy pasted the JVM implementation 1:1, and trying to see how far I get from there.
If anything at all can be improved let me know

[armanbilge]

I basically copy pasted the JVM implementation 1:1, and trying to see how far I get from there.

Instead of copying, you can place these sources in the jvm-native folder so that they can be shared :)

[jenshalm]

Welcome, and many thanks for looking into this. However, before you spend any more time on this I'd like to point you to the fairly recent debate in #360, which will make it clear that this is unlikely to get merged in the near future.

The short summary is that we established that increasing the platform support for Laika is valuable only if we also look into developing a CLI application, but the conditions for that are currently not met (not enough interest in the community, too few maintainers for Laika, nobody committed to actually picking up the work for the CLI, which is much more effort than expanding Laika's platform support).

As things stand today, if I would make any change in Laika's platform support, I'd probably think about removing support for Scala.js. There are less than 10(!!) downloads per month, and the support does not only increase the build and release times, there were also several issues I had to deal with specifically to support this platform, which is not a reasonable way to spend my time when there are basically no users.

Nevertheless, I'm curious to know what your personal use case is for Laika on Native?

[armanbilge]

The short summary is that we established that increasing the platform support for Laika is valuable only if we also look into developing a CLI application

Oh, hm, that's not my conclusion :) I believe laika-core on Native would be valuable. But laika-io only makes sense with a CLI application. Quoting myself:

If publishing a CLI application is out-of-scope for Laika, then I think cross-building laika-io for JS/Native is less valuable. The core is already cross-published for JS (and maybe Native someday) which, if desired, can be used directly with fs2-io without going through laika-io.

---

As things stand today, if I would make any change in Laika's platform support, I'd probably think about removing support for Scala.js. There are less than 10(!!) downloads per month, and the support does not only increase the build and release times, there were also several issues I had to deal with specifically to support this platform, which is not a reasonable way to spend my time when there are basically no users.

I'm sorry to hear that.

[jenshalm]

The short summary is that we established that increasing the platform support for Laika is valuable only if we also look into developing a CLI application

Oh, hm, that's not my conclusion :) I believe laika-core on Native would be valuable. But laika-io only makes sense with a CLI application. Quoting myself:

If publishing a CLI application is out-of-scope for Laika, then I think cross-building laika-io for JS/Native is less valuable. The core is already cross-published for JS (and maybe Native someday) which, if desired, can be used directly with fs2-io without going through laika-io.

Sorry, I misunderstood that in a way that to me this logically expands to laika-core as it seems that at least for Scala.js there is no community use case for just supporting this module without expanding it to a CLI application. Where do you see a use case for just having laika-core on Native?

But in any case, my perspective on this remains: I am not considering adding maintenance for Native support to my todo list at this point, so until someone steps up and is willing to do the review and future maintenance for this, this cannot be merged.

[armanbilge]

Where do you see a use case for just having laika-core on Native?

The same use-cases as on JVM (minus the sbt plugin) e.g. server-side rendering of markdown. Unless the big picture here is that Laika itself doesn't really have a use-case outside of an sbt plugin?

---

so until someone steps up and is willing to do the review and future maintenance for this, this cannot be merged

Right, that would be me :) (edit: and taking responsibility for JS as well. and I can help with build/CI too, if you want).

[zetashift]

However, before you spend any more time on this I'd like to point you to the fairly recent debate in #360, which will make it clear that this is unlikely to get merged in the near future.

Heyho! I indeed read that conversation and I completely understand the reasoning you give that a native target isn't easy in several ways and don't want to increase maintenance burden like that. I'm hoping that at some point in the future enough desire is garnered for a Scala Native target.

I put up this (draft) PR because I really like Scala Native and would like to increase its library support. And more specifically Laika, because I'm looking for a static site generator(or atleast markdown parser) with the attributes of being a tiny native executable and written in Scala.

Even if this never gets merged, it is still a great learning exercise for me and I must say the Laika code is very readable!

[jenshalm]

Where do you see a use case for just having laika-core on Native?

The same use-cases as on JVM (minus the sbt plugin) e.g. server-side rendering of markdown. Unless the big picture here is that Laika itself doesn't really have a use-case outside of an sbt plugin?

Yes, sadly that is my impression at this point, judging by download numbers. To drop some of the numbers again (for November):

• sbt plugin - 11,000
• laika-core JVM 2.13 - 100
• laika-core JS 2.13 - 10

That's <1% and <0.1% of downloads respectively.

so until someone steps up and is willing to do the review and future maintenance for this, this cannot be merged

Right, that would be me :)

Ok, that would be an option then. But I'd still like to question whether it is worth it at this point in time and if you really want to add this to the apparently thousands of things you are involved in 🙂 .

[armanbilge]

Yes, sadly that is my impression at this point, judging by download numbers.

Right, I was afraid of that 😕

---

Ok, that would be an option then. But I'd still like to question whether it is worth it at this point in time and if you really want to add this to the apparently thousands of things you are involved in 🙂 .

Considering the above, it's a good question :) if you intend to keep Scala.js since it's already here, then adding Scala Native is probably straightforward. Of course, we have to see how this PR looks before making a final call on that.

Of course if you are seriously considering dropping Scala.js support altogether, then this doesn't make sense.

[jenshalm]

Considering the above, it's a good question :) if you intend to keep Scala.js since it's already here, then adding Scala Native is probably straightforward. Of course, we have to see how this PR looks before making a final call on that.

Of course if you are seriously considering dropping Scala.js support altogether, then this doesn't make sense.

Ok, I'll leave the final call on this mostly to you then. Removing Scala.js support is not very likely at this point. While I do think that the past effort was not really worth it, a trigger for removing it would only be a significant number of future issues that are specific to JS while download numbers are still negligible. Only then I'd seriously think about it (and also probably propose it quite a long time before actually doing it).

Only requirements from my side at this point: If the final PR is binary compatible it can theoretically get merged anytime (meaning we do the shuffle of source folders for the 0.19 branch, too). If it can only be done for 1.0, as discussed, I'd prefer to defer the merging to a later phase of the milestone series.

Also @zetashift my next PR will introduce scalafmt which will also reformat the entire code base. It should be out in the coming 10 days or so, you may want to wait for that to avoid tons of merge conflicts.