Can you elaborate on that?  The Web Components HTML spec should have nothing of the sort.  Things communicate 'to' something by setting attributes and properties (as you can do now in elm) and gets information back by receiving standard events (which you can 'kind of' do in Elm currently).  I think the main issue currently is that elm does not fit 'into' a web component well just yet as it has no method to send an event nor does it have a subscription ability on receiving property/attribute setters.  Those two things would make it pretty perfectly composable.

On Wednesday, March 22, 2017 at 12:34:29 PM UTC-6, Maxwell Gurewitz wrote:

One thing I don't understand at all is why web components are being pushed in the community when they suffer from all of the same problems and lack of guarantees as Native/Kernal code (lack of type safety, lack of determinacy, lack of versioning guarantees provided by elm-package) while requiring polyfills and a whole new build system (bower).

On Tuesday, March 21, 2017 at 1:01:50 PM UTC-7, Evan Czaplicki wrote:

Sometimes new folks wonder, "should I be writing native code?"

The answer is no and I have elaborated on why in this 2015 post.

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.

Note: Another example of "kernel" code comes from JavaScript itself. When you write JavaScript, you are not able to distribute C++ that extends and modifies Chrome. This is about security, reliability, and basic sanity. JavaScript doesn't have pointers. JavaScript doesn't have memory shared between different threads. "But the web could move forward faster if I had access to those things." Sometimes it's more complicated than that.

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:

• elm-community/linear-algebra
• elm-community/webgl
  
• Skinney/elm-array-exploration
• BrianHicks/elm-benchmark
  

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.

Final Thoughts

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?"