On Thursday, September 29, 2016 at 9:46:15 PM UTC+1, Riley Eynon-Lynch wrote: > > We have 7k lines of Elm in production, and we stopped using it because of > this pain in the boundary between Elm & JS. The examples from NRI show lots > of local, elm-internal logic without much API chatter or JS interop. Our > app has tons of API chatter (realtime collaboration is a feature), and we > have 40k lines of JS in our main SPA that any newly-elmed component would > have to talk to. > > We found that of our 7k loc, over 1k was in decoders & encoders! >
I am finding this too, I have spent the last 2 weeks mostly dealing with the REST API and json conversion, but also bearing in mind this is my first attempt at doing this so also dealing with the learning curve. Some further thoughts... I have seen a few posts on Elm around protocol buffers. If you are talking to an API but using Elm over js, then the advantage of talking json as the native tongue of the client seems lost, why bother with json at all? After all its a verbose and stringy data interchage format. So if another pseudo type class called 'decodable' were intrdocued, it would be helpful if it were able to work with different types of encoders/decoders not just for json. Fantastic if one could get easy conversion to and from json, protocol buffers, xml, AMQP message format, and so on. Perhaps there might even be a special native module type that allows new ones to be written. -- 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.
