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.
