I understand your dissatisfaction with the communication,I think forum posts lose a lot of intent but I'm not sure of the specifics.
I would also like to inquire if you have tried the port solutions as an alternative or posted about your specific cases where you have determined that native is the best solution to the slack. There's a ton of motivation to not have native modules with regards to the future and current optimization in addition to some other benefits. It is a definite trade off though. If you're looking for a more traditional FFI but less safe solution, I recommend you check out the ReasonML project.
We currently have only one case where native is the most practical way to accomplish what we need. You can read the full discussion of that with Robin here. Other use cases were mentioned in the linked reddit thread, and more could be found in other searches.
Regarding optimization, native modules are still usable by Elm package contributors, and are also subject to optimization. So I doubt optimization is a blocker to using them.
I don't have a problem with removing native access. But the timing was when the API is still known to be missing important cases. And Evan's post about it reads like a punitive decision. Between this and the community issues (which have the same root cause), the risk for us in using Elm has gone up.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I understand your dissatisfaction with the communication,I think forum posts lose a lot of intent but I'm not sure of the specifics.
I would also like to inquire if you have tried the port solutions as an alternative or posted about your specific cases where you have determined that native is the best solution to the slack. There's a ton of motivation to not have native modules with regards to the future and current optimization in addition to some other benefits. It is a definite trade off though. If you're looking for a more traditional FFI but less safe solution, I recommend you check out the ReasonML project.
We currently have only one case where native is the most practical way to accomplish what we need. You can read the full discussion of that with Robin here. Other use cases were mentioned in the linked reddit thread, and more could be found in other searches.
Regarding optimization, native modules are still usable by Elm package contributors, and are also subject to optimization. So I doubt optimization is a blocker to using them.
I don't have a problem with removing native access. But the timing was when the API is still known to be missing important cases. And Evan's post about it reads like a punitive decision. Between this and the community issues (which have the same root cause), the risk for us in using Elm has gone up.