Sometimes new folks wonder, "should I be writing native code?"
A great example is the question "Should I wrap D3 for Elm?" This was not permitted, and now we have elm-plot which is entirely in Elm and does things in a way that makes sense for Elm. When charts are a view function, we can have a totally separate library for animation. Each can be simple and used together or separately or whatever. And everything can work nicely within the Elm Architecture!
So it takes longer, but I think the end result will be so much better!
So why does the question persist?
I think the question "should I be writing native code?" persists because of poor framing and communication on my part.
From my perspective, this means "Should I be writing x86?" For folks from other backgrounds, it means "Should I be writing JS?" or "Should I be wrapping JS libraries?" When I chose the term "native" however many years ago (probably before elm-get even!) I did not appreciate how it would sound from other perspectives.
Renaming "native" to "kernel"
One part of the plan is to rename Native.* to Elm.Kernel.*
Check out the description of a kernel
. That is exactly the role JS needs to have in the Elm ecosystem. A minimal set of code that lets developers have access to things like device drivers (mouse, keyboard, geolocation, etc.) without giving full access to the machine.
Like I say in this 2015 post, the core benefits of this are reliability and portability. The main value of a language is in the ecosystem, and restricting kernel code means (1) there are no runtime errors in the entire ecosystem and (2) the entire ecosystem can come along to platforms besides JS without major changes.
I hope the name "kernel" will suggest all these things more clearly.
Ending the "Native Whitelist"
The native whitelist
is kind of a mess. "Why this package and not that other one?" Basically, we were learning what the limits should be, so there is a lot of historical noise in there.
I think the idea of "kernel" code would be even clearer if only projects in @elm-lang and @elm-explorations can have kernel code. That means no more native whitelist.
The @elm-lang organization will be for high quality code that can be recommended as the default package to use for a particular problem.
The @elm-explorations organization will be for code that may one day be included in @elm-lang. Based on the current native whitelist, that would include these:
Affordances may need to be made for other packages though. For example, I know that elm-graphics is used in educational settings, so it would need to survive even if it should not ultimately have kernel code in it.
How does @elm-explorations work?
For things to get into @elm-lang, I go through the API and make sure it is up to a certain standard. This takes quite a lot of time and research, so it must be balanced with other priorities.
The four projects listed above (for WebGL, new arrays, and benchmarking) all have coordinated with me to plan out the long term life of these projects and to go through the API. When you are serious about adding kernel code, this coordination is required. In those four cases, the packages were quite far along by the time we did any coordination, and the authors were able to make a clear and compelling case for the coordination being worthwhile.
I tried to talk about how this works in this talk
, but there is no simple recipe. It's not like "the secret" where if you visualize it, it will happen. Maybe the API just sucks. Maybe it's great, but a fundamental premise of the library is off. Maybe it's great, but it's not higher priority than other things going on. Etc.
Having Elm expose the entire Web Platform is the long-term goal. The process outlined here will be slower than other methods, but when the priority is quality, I think this is the best path.
My focus right now is getting 0.19 ready to go. It has many features that are very important to Elm's long-term health, and it'll make sense to cover more Web Platform after it is out.
Anyway, just wanted to outline some thoughts on this topic. Hopefully this message is helpful for folks who find themselves answering the question "should I be writing native code?"