Thanks for sharing your impressions. Is there a particular question you're hoping to have answered or a proposed or attempted solution that you'd like to discuss?
On Thu, Mar 23, 2017 at 1:15 PM, Simon <[email protected]> wrote: > 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. > -- 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.
