The barriers are already built, the recent discussion mostly revolves on how we talk about the current barriers to make things more clear for beginners. Nothing is going to prevent you from using native/kernel code in your own project. You just won't be able to share it on elm-packages (which is still the case today).
torsdag 23. mars 2017 21.15.51 UTC+1 skrev Simon følgende: > > On elm-dev I get the impression that bigger barriers are being built to > towards javascript interop. > > I think building the barriers before the webapi is provided in Elm is the > wrong way around, but that's not the only case where practical needs are at > risk. > > Consider msgpack - a sort of compressed json. It's well specified but > today not much used. No one has written a library for it in Elm, but there > is a well-tested JS one. The encoding is simply calculations, so in the > normal run of things this should be a synchronous operation. If ports > returned Tasks this would not be a huge issue, but they return Commands and > thus force you back around the update loop (and the creation of an extra > Msg, which makes code intent less transparent). > > The work around is a native file along the lines of (or see this NoRedInk > library <https://github.com/eeue56/elm-ffi/blob/master/src/Native/FFI.js> > ): > > ``` > var _user$project$Native_Msgpack = function() { > > function encode(k) { > return msgpack.encode(k.kwd); > } > } > ``` > > It's pretty clear that these practices are frowned upon, but the shift to > 'kernel' sounds like a plan to squeeze the pragmatic programmer's options > further. I hope that's not the case. > > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
