44 ms·

Elm in Production: 25K Lines Later

449 points by Albert_Camus 9y ago

advanderveer 9y ago
What an excellent article: from tech to business, from the human aspect to practical code examples. Worth a read, even if you're not considering Elm.
- akuji1993 9y ago
  Not into Elm at all right now and also kind of not convinced about functional programming, yet. But the article was definitely worth a read. I need to slowly open up for FP, I guess.
  - moomin 9y ago
    I'll make an observation: I write C# for a living. The great thing about that is that it has a truly great debugger. But, as you rapidly discover, it's easier to debug some code than others. For one thing, you want to be able to go back to the start of the function and re-run it. That means that methods that mutate internal state are hard to debug. Also, it's even better if you can follow the chain of reasoning without rerunning the code. This means having a variable for each assignment, rather than overwriting an existing one. Finally, when processing large data lists, it's easier to debug if you have separate variables for logical steps. e.g. Get the employees of Company X (variable) that are managers (variable) and sum their salaries (variable). Trying to debug round a for loop is an exercise in frustration. What all these things have in common is: it's easier to reason about the values in a program than the program counter, and that destroying information makes it harder too. And that, to a great extent, is why FP is useful. Even really basic FP in C# or Java.
    - moogly 9y ago
      Dumb question: Have you tried IntelliTrace in VS Enterprise (sadly only available there)? It tries to solve many of the issues you're mentioning. You can even start a remote IntelliTrace debugging session in production.
      - moomin 9y ago
        Not a VS enterprise shop, sadly. Don't think I've ever worked for anyone prepared to pay for it! It does sound enormously cool. Does it also handle one of my favourite problems: when a method fails because a constructor parameter was wrong, it's pretty hard to rewind. With that said, VS Pro still has one of the best debuggers on any platform. To the extent that I think C# developers sometimes cut corners because the debugger helps so much.
anon335dtzbvc 9y ago
"JSON-based RESTful API as its back end" what language do you use for the backend, Haskell?
- iamwil 9y ago
  You can use anything that can expose an HTTP port. It doesn't have to be Haskell.
endgame 9y ago
I'm really looking forward to the day when all these new-to-Elm people start hitting the complexity ceiling of their language and convince the maintainers to add just a little more power. Example: Haskell's typeclasses have a high power-to-weight ratio, and Elm has to work around their absence (e.g., writing a fresh map function for each data type). Once there's a critical mass of frontend types who understand the power of FP, convincing people to try FP won't be the difficult step any more, and Elm won't need to try so hard to be un-intimidating.
- chriseidhof 9y ago
  Every added feature also adds complexity (and to be fair, in some cases, removes complexity). I love type classes, but I discovered in playing with Elm and specifically, TEA (The Elm Architecture) that the simplicity is also really nice even if you're comfortable doing type-level programming. There's something about Elm's simplicity that really works.
  - endgame 9y ago
    Agreed, but Elm is hurting for some way to deal with this stuff. Currently, the API reference lies by claiming things like (==) : a -> a -> Bool, because it lacks a generic mechanism to let the programmer think the necessary thoughts. (The story for comparison functions like (>) is similar.) Now maybe Elm should stay simple and not jump all the way to multi-parameter type classes with functional dependencies, but it is already forced to pay some of the complexity burden to decide which types admit equality testing, comparison and so on.
    - ryanplant-au 9y ago
      Can you elaborate on what you mean when you say that (==) : a -> a -> Bool is a lie? I don't have enough experience with more powerful type systems to know what the more accurate claim would be. Do you mean that it should really be Eq a => a -> a -> Bool, because not all types can be checked for equality?
      - 9y ago
ToJans 9y ago
First: > Elm has an incredibly powerful type system Near the end of the article: >Want to decode some JSON? Hard, especially if the JSON is heavily nested and it must be decoded to custom types defined in your application. IMHO the lack of typeclasses/traits is really hurting Elm. Take haskell f.e. {-# LANGUAGE DeriveGeneric #-} import GHC.Generics data Person = Person { name :: Text , age :: Int } deriving (Generic, Show) instance ToJSON Person instance FromJSON Person While I understand Evan's aversion against complexity, it makes me a bit wary about using ElmLang in production. I am currently using TypeScript, but if I would need a more powerful type system, I would probably switch to Haskell/PureScript or OCaml/BuckleScript instead.
- vim_wannabe 9y ago
  In Rust you can also just make your struct deserializable, use a JSON lib to deserialize a string and get the corresponding object in a Result type. The amount of work you need to do in Elm instead is huge.
- kccqzy 9y ago
  That doesn't handle custom JSON schemas at all. I don't know much about Elm but at work in Haskell we mostly write FromJSON instances manually. It's probably the same amount of code as the data type definition.
  - ToJans 9y ago
    For custom JSON schemas nothing tops F#'s type providers [0] IMO. [0] https://github.com/jet/JsonSchemaProvider https://github.com/jet/JsonSchemaProvider
    - jlouis 9y ago
      This is the way to go, if you are tied to JSON for some reason. A far better solution is to get rid of JSON if most of your stack is a typed stack and then convert to JSON as late as possible. Custom JSON which people invent as they go along is just going to present your system with pain over time.
acobster 9y ago
Great article! I have no experience with Elm but I'm much more likely to try it out now. I'm curious to hear your thoughts on this though: http://reasonablypolymorphic.com/blog/elm-is-wrong http://reasonablypolymorphic.com/blog/elm-is-wrong
- walrus 9y ago
  The core complaint is the lack of typeclasses. If your coding style relies heavily on generics, maybe Elm isn't for you.
  - Skinney 9y ago
    Why? Elm has generics.
iamwil 9y ago
Having started using Elm for side projects over 3 years ago, the article is pretty much spot on. Programming in Elm had been a delight, especially when you let go of OOP and embrace functional concepts and practices. On one hand, you lose mental tools that you've relied on, but you gain the other tools you didn't even know existed before. Where I really disliked about Elm is when I had to encode or decode JSON. It's a giant royal pain in the ass. Also, when you find you have to break out to JS often for libraries you don't want to write yourself, it's not a good fit--as I found out when write a toy interactive notebook to render markdown in Elm. But for most SPA that just manipulate form data and communicate with the server, it's a pretty great fit.
- kristianp 9y ago
  Isn't decoding JSON a big part of an SPA though? How do you deal with data from the server?
  - antouank 9y ago
    Once you handle a couple of complicated cases, you're ready to solve any JSON decoding within minutes. It's just a small learning curve to go through. Also, once you get the hang of it, you can use it as your safety layer for incoming data. To guard the app from any invalid response. I've even used GraphQL for one of my projects, decoding worked fine as well.
  - enalicho 9y ago
    There exist multiple tools to aid you with writing decoders: - json-to-elm http://json2elm.com http://json2elm.com - swagger-elm https://github.com/ahultgren/swagger-elm/ https://github.com/ahultgren/swagger-elm/ - elm-graphql https://github.com/jahewson/elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql https://github.com/jamesmacaulay/elm-graphql - elm-export https://hackage.haskell.org/package/elm-export https://hackage.haskell.org/package/elm-export Once you've got the hang of it, it's not that hard either. Just time consuming. That's where json2elm comes in :)
PostThisTooFast 9y ago
They're using a decades-old E-mail client in production today? Impressive.
dmjio 9y ago
If decoding json in Elm is considered hard, I'd recommend checking out miso (https://github.com/dmjio/miso https://github.com/dmjio/miso), a Haskell re-implementation of the Elm arch. It has access to mature json libraries like aeson for that sort of thing, along with mature lens libraries for updating your model. Here's an example of decoding json with GHC.Generics using typeclasses. https://github.com/dmjio/miso/blob/master/examples/xhr/Main.hs#L130-L131 https://github.com/dmjio/miso/blob/master/examples/xhr/Main....
- StreamBright 9y ago
  This looks really promising. Do you use it in production anywhere? Do you have any comparison of features with Elm?
- aaron-lebo 9y ago
  This is very cool. The example apps are relatively slow to load compared to the equivalent in some other frameworks (my favorite is Mithril for an idea of how small/fast these can get). Was wondering whether it might be a slow server, but the app.js for the TodoMVC appears to be over a megabyte (1.21 MB, have a 4000 line Mithril app which is 500k uncompressed). What's up with that?
  - StreamBright 9y ago
    Can you give exact numbers and a testing method of how you tested and determined it is slow?
    - aaron-lebo 9y ago
      The router example on Github loads ~1.5 MB of JS files. Mithril's entire framework is 8kb gzipped (including a router).
      - mbrock 9y ago
        ghcjs is a pretty heavyweight environment. It's actually translating the compiled core IR from GHC into JavaScript, and including a port of GHC's runtime system. It can run basically any Haskell library. That includes the ability to run multithreaded Haskell code -- the JS RTS includes a scheduler. You also get Software Transactional Memory. Lazy evaluation works just as usual -- and so on. The tradeoffs become worth it when you have a sufficiently valuable base of Haskell code that you want to run in the browser, and when your users aren't very constrained by page load time. Say, if you have some complicated tricky logic that you don't want to rewrite in another language, but you want to use it in your web app.
antouank 9y ago
After doing a couple of contracts on Elm projects for several months, and returning now back to a React-Redux stack project, I cannot emphasize enough how much better working with Elm is. In every single aspect. I just wish that it will get mainstream as soon as possible. His article is spot on, and agrees with what I've seen, and most others that used Elm. Just look it up.
- BoiledCabbage 9y ago
  > I cannot emphasize enough how much better working with Elm is. >In every single aspect. I just wish that it will get mainstream as soon as possible. I completely agree - I will be a huge benefit to the industry when elm is as common as js. The concepts it introduces, the benefits it shows are all huge. I've been programming a long time, and elm shattered my views of the relationship between a coder and his/her compiler. It went from being that thing you have to "pass" to see your code work, to instead a faithful companion. Like having a trusted dog with you in the woods - an extra set of senses to help you out on your way. Elm is not perfect (no language is) -but being perfect isn't the goal. A practical transition story, huge productivity gains and extremely maintainable code.
  - antouank 9y ago
    Not perfect, but definitely a much better tool for that work (big front-end apps). JS was not meant for that, it's been stretched far from what it was (quickly) designed for. And sure, when more people join Elm, bad-written libraries or silly paradigms will crop up, but I'm confident it won't be as bad as the JS landscape is today. Time will tell I guess. -- Now back to stitching those JS libraries to write some code that might work. Bills have to be paid :)
  - jnbiche 9y ago
    > I've been programming a long time, and elm shattered my views of the relationship between a coder and his/her compiler. I love Elm as much as the next guy, but be aware that you can get many, if not most, of these same benefits while working in JS if you use Flow.js or Typescript. I prefer Flow because the community is more oriented toward functional programming vs OOP in Typescript, but they're both capable static analyzers for JS.
deleted 9y ago
[deleted]
delegate 9y ago
Anyone familiar with both Elm and Clojurescript ? Clojurescript's 're-frame' lib implements something similar to the Elm architecture and is quite pleasant to work with. How does the Elm experience compare to the Clojurescript experience ?
- mjaniczek 9y ago
  Simple: writing code in Elm is compiler-driven development. As the article said: > Just start by changing your type definition and the compiler errors will help you find everywhere that needs updating. This is how most of Elm development gets done. I change the types and let the compiler tell me what actual code needs changing. Clojurescript, on the other hand, doesn't have this "assistant", unless you're using Typed Clojure or Schema (it's been a year or two since I tried that, so can't speak from current experience). The Elm Architecture is worth pursuing even in dynamically typed languages though :)
- hellofunk 9y ago
  Similarities: 1) Re-frame and Elm are both backed by a virtual dom (Re-frame leverages React behind the scenes, Elm uses virtual-dom) 2) Both impose a single app state 3) Both require user events and outgoing state mutation to be explicitly defined somewhere outside of the context of a view 4) Both operate on a sort of "game loop" style of processing events and calling view functions 5) All data is immutable in both languages (though Clojurescript provides explicit mutable structures if desired, which require special syntax so any mutation is evident) Differences: 1) Elm's model is pure FP -- data is passed to a function, and then it calls other functions. An individual view function in Elm cannot independently subscribe to any kind of data event, either a state change or a socket message, etc; it must receive the data it needs as an argument to the function only. Depending on who you talk to, this is either limiting or properly restrictive. It does mean that a branch of your Elm user interface should generally correspond to a single branch of your app state, or that view functions in complex interfaces must take quite a lot of arguments; this is a pattern for which re-frame explicitly offers a workaround (though you can also do it the Elm way in re-frame if you want). In general, these differences lead to more re-usable components in re-frame than in Elm. 2) Elm has no real asynchronous library for high-level concurrency. Most Clojurescript projects (at least large SPAs) often leverage core.async as an abstraction for large UIs that handle many independent processes simultaneously. Core.async makes clojurescript particularly versatile for accomplishing things in a single-threaded environment as if it were modelled with multiple threads. 3) Elm has its own compilation story that is separate from the JS ecosystem. The Elm devs are working on dead code elimination. Clojurescript projects are all built on Closure, which provides DCE, compression, and global inlining which can provide some projects notable speedups. The Closure libraries also give Clojurescript cross-browser abstractions for hundreds of common tasks in front-end development that have been battle-tested by Google in all of their web services, so it can greatly reduce development and debugging time for complex apps that run everywhere. 4) Elm controls JS interop much differently than Clojurescript. The tradeoff is that in Clojurescript you will inevitably spend more time debugging runtime errors, while in Elm you will spend more time developing your JS interop code and testing cross-browser compatibility. 5) There are many UI libraries available for re-frame because it can wrap existing JS tools (including wrapping UI libraries built for React). There are fewer for Elm, and it's more common to roll your own UI in Elm. There are pros and cons here. I've worked on two large projects in Clojurescript, one which was all custom UI components and another that leveraged polished libraries in the wild. The former took much much longer to make but looked more unique. Having the choice to go either way is a big benefit since project goals widely vary. If you are primarily a developer/coder and not a web/graphic designer, you may be frustrated at UI design in Elm. If you work with a designer, this is not a problem. But if you work alone, having access to a lot of UI tools can free up your time and efforts quite a bit, and Clojurescript has an edge here. 6) Types: Elm has static types, while Clojurescript offers clojure.spec (which is optional though widely used). Spec is a runtime contract system so you can guarantee that all args passed to functions or setup in data structures meet specified criteria; not just types of the args, but also any other predicates, such as a valid range for an integer, etc. For example, an Elm union type would be a Clojure set, where each element could be a specific data structure with other specs attached to it. However, Elm has proper static types, which are caught at compile time, not runtime. There are benefits of both styles. If you want to tightly catch very specific data aberrations that flow through an app, clojure.spec is easy to use for that purpose; but if you want more general checks before the program runs, Elm would be preferable. 7) Performance: All of Clojurescript libraries that wrap React (including Re-frame, vanilla Reagent, and Om) offer an interesting runtime optimization that I've not seen in other languages, and is not available in React itself. If the data that a view function requires (either via its arguments or subscription) has not changed from the prior render frame, then the entire view function is skipped without running, since its output would not be any different. What this means is vast sections of your app's code don't even need to run on each render frame, and this is not trivial. In a small app, it would make no difference, but in complex SPAs this can be very significant. Elm offers a library, Html.Lazy, that attempts something similar, though my impression is that most Elm projects do not use it since it can be tricky to explicitly add this behavior; in Clojurescript, it is built in automatically. In Re-frame, they go an extra step by de-duplicating any queries or subscriptions so that multiple views which use the same data context do not query, fetch or calculate the required data more than once, which is then passed to all requested functions. If you are working on an app that processes lots of data frequently, this can be the single selling point of using Clojurescript, as it frees up the CPU to deal with only those things that are guaranteed to require processing. Clojure's syntax is very tight and concise, while Elm's language is elegant but more verbose. I have found that there is approximately a 2.5X increase in code size in Elm when trying the same ideas out in both languages. All other things being equal, you can probably get a re-frame app going very quickly; if you need to prototype something or get to an MVP as soon as possible, it is really hard to beat Clojurescript compared to any other compile-to-JS language. If however you are going for application purity and a reduction in runtime debugging, Elm (or Purescript or some other statically-typed languages) would be a better fit. Ultimately, Clojurescript is a general purpose language, while Elm has a very specific use-case; if you fit into the Elm model, it can be nice. If you need to reach outside that model, it is a challenge.
therealmarv 9y ago
When JSON decoding is hard this is not a minor thing when looking at my RESTful APIs. This is a major trade off. How to deal with it ideally?
- Albert_Camus 9y ago
  Author here. JSON decoding is hard relative to what it is like in JavaScript. In your JS code you can just call JSON.parse() and get the corresponding JavaScript object. In Elm, decoding is not nearly as easy as it is in JS because every field must be explicitly converted to an Elm value. Depending on the complexity of your conversion from JSON to Elm value (e.g. whether you are just decoding to primitive values or to custom types defined in your program), there may also be a bit of a learning curve. As I stated in the post, there is a benefit in doing all of this: your Elm application will effectively type-check your JSON and reject it if it is malformed.
  - Existenceblinks 9y ago
    > JSON decoding is hard relative to what it is like in JavaScript I'm not making a joke but this is a valid point. And if it had ELMON (Elm object notation), things would be more straight forward.
    - mavelikara 9y ago
      No, that is not a joke. If one tried to convert an Applet to HTML5 and came across a server backend that returned serialized Java objects, parsing that into JS would have been significantly harder than the two lines with ObjectInputStream it would take in Java.
- enalicho 9y ago
  Right now, there exist multiple tools for dealing with JSON: - json-to-elm http://json2elm.com http://json2elm.com - swagger-elm https://github.com/ahultgren/swagger-elm/ https://github.com/ahultgren/swagger-elm/ - elm-graphql https://github.com/jahewson/elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql https://github.com/jamesmacaulay/elm-graphql - elm-export https://hackage.haskell.org/package/elm-export https://hackage.haskell.org/package/elm-export It's worth noting that JSON decoding is not _hard_ as such, but it's harder than other parts of the language. It is more time consuming. Tools like these can help reduce the amount of time you spend hand writing decoders.
niels 9y ago
When I last tried Elm, I didn't find any really good UI libraries. Also there weren't any good solutions for i18n. Has the situation changed?
- ocharles 9y ago
  It depends what you mean by "good UI libraries", but there is http://elm-ui.info/ http://elm-ui.info/ for one. Perhaps that helps?
- hellofunk 9y ago
  Depends on your needs. If you are targeting desktop, there are a couple of UI libraries for Elm. However, they are buggy when you try to test them out on a mobile tablet. I have found that most Elm developers create their own UIs since wider access to JS UI toolkits is not easy. That does mean that you need to enjoy general web design or work with a designer, or be willing to put in extra time when working in Elm.
  - niels 9y ago
    Yep, Agree. I specifically used elm-mdl and elm-ui. Elm-mdl were not well maintained and elm-ui, while nice, is desktop only.
dmitriid 9y ago
> making very heavy use of Ajax calls to a JSON-based RESTful API and then > Want to decode some JSON? Hard, especially if the JSON is heavily nested and it must be decoded to custom types defined in your application. Doing this will require an understanding of how JSON decoding works in Elm and will usually result in quite a bit of code (our application contains over 900 lines of JSON decoders alone). What a great pragmatic language
- amimetic 9y ago
  In exchange you get incredible validation of your JSON and precise error messages about missing fields etc. And you don't have to write that bit by hand: http://eeue56.github.io/json-to-elm/ http://eeue56.github.io/json-to-elm/ will generate the decoder for you for straightforward cases and give you a great starting point for more complex cases. You also get proper ADTs to manage state: not asked/loading/loaded/error something that is tedious and error prone in Javascript.
  - dmitriid 9y ago
    Yup. There are a bazillion libraries now trying to pretend to make it look like it's easy to deal with JSON in Elm. An online converter is definitely not something I would advertise for a "production-ready highly productive amazing pragmatic language to be used in a serious company"
    - dmitriid 9y ago
      For god's sake, Elm is the only language I know that has _an entire book written on how to handle JSON_: https://www.brianthicks.com/post/2017/01/06/announcing-the-json-survival-kit/ https://www.brianthicks.com/post/2017/01/06/announcing-the-j... It's introduction is: "You know how it takes so much effort to produce even the simplest of programs when JSON parsing is involved? Wouldn’t it be nice if you could breeze right on by that step and get on with writing your business logic? This is what you’ll get with The JSON Survival Kit, a short ebook on JSON decoding in Elm." Wut
steinuil 9y ago
I've used Elm for a while and I don't really see what's the problem about JSON decoders/encoders. Sure, they're verbose and annoying to write if you have a particularly intricate JSON structure, but I don't really see a better alternative for decoding and encoding JSON in a type-safe way, and with Elm's constraints on ease of learning. More freedom on type-level programming would help, but that would certainly complicate the type system, and the only language I know that lets you fold over arbitrary record types is Ur/Web, which has a richer type system than even Haskell, and I don't see Elm adding things to its type system (other than type classes, hopefully), given that other interesting features were already removed because very few people used them.
nnq 9y ago
> One simple example is that of a three-way state What follows after this line is the most artificially complicated description of a problem I've ever seen... basically an excuse for the solution OP then goes on to suggest! Actually the more functional way to think of the artificially complicated problem OP describes here would be to have 2 data holders, a `myTagsData` and `myEditedTagsData` data, and when the user edits around `myEditedTags` is updated/synced, and when "Save" is clicked `myTagsData` gets replaced with `myEditedTagsData`... and we simply re-render based on new data in the context of a simple one way flow (hint: use React or something similar to not re-invent the wheel). Yea, sure, you can avoid state at all costs but you can also learn to properly manage state! There are places where one or the other is a good fit... but doing the former in order to avoid the latter is just "mental masturbation" imho... and the kind of things that disgusts some smart people and keeps them away from functional programming actually :(
fiatjaf 9y ago
I think JSON decoding is great in Elm. Actually, that may be the best part of that language.
bandrami 9y ago
I wonder if its successor framework will be called pine.
- mLuby 9y ago
  2019: JSON decoding in Mahogany-lang is hard…
unabst 9y ago
Quick question. > Want to measure the height of an element on the page at the moment a user clicks on it? Hard, in order to do this we had to make heavy use of event bubbling and writing JSON decoders for the native event.target object that is produced by an onclick event. What would be considered best practice? Is it best practice to re-implement this sort of thing? Seems one could easily find vanilla JS code and encapsulate it, or add a helper lib?
deleted 9y ago
[deleted]
noshbrinken 9y ago
Something I find incredibly off-putting about Elm is the evangelical and generally unbalanced tone taken by many prominent members of the Elm community. I almost never come across Elm advocates accepting a valid criticism of the language. The response almost always amounts to "you don't understand" or "yes, but". They spend a lot of time celebrating the compiler's humanistic virtues but seem less clearly humanist in their relation to original thinking or diversity of thought. So much of Elm community dialogue (in talks, in articles, in the Elm slack which I follow daily) is simply those with more experience initiating those with lesser experience into the "Elm way" of doing things. For this reason, Elm feels more like a framework with a domain specific language than a fully qualified programming language. And while it might seem like a gentle introduction to functional programming techniques, I'm not confidant that it really teaches people the concepts themselves nor gives them enough room to think critically about how to apply them. Instead, the task is to internalize and apply the "Elm way". The inability to even acknowledge the unprecedented labor required simply to parse a JSON response is a perfect example of the cultish mentality emerging in this community.
- KirinDave 9y ago
  > less clearly humanist in their relation to original thinking or diversity of thought So what you're frustrated with is that a group of likeminded individuals celebrates their common point of interest and doesn't make room for you to nay-say them? > So much of Elm community dialogue (in talks, in articles, in the Elm slack which I follow daily) is simply those with more experience initiating those with lesser experience into the "Elm way" of doing things This could be said of a lot of PL environments. How many Python tutorials stop midstride to browbeat you about how great Python's way of doing things is? Sure feels like a lot to me. > The inability to even acknowledge the unprecedented labor required simply to parse a JSON response is a perfect example of the cultish mentality emerging in this community. Right but... what do you want? Acknowledgement? My friend, literally everyone here is agreeing it's harder than JSON.parse. No one argues it is "easier." I can't find a handy example in this thread of anyone saying, "Yeah this is great." There are tools to ease this pain, and there are ways to call external JS code that does this. At the end of the day though, validating data structures on the wire both structurally and for content is a lot of work. Most Javascript projects don't do it. Hell, most typescript projects just say, 'Well if it breaks it breaks.'. By pure coincidence this redacted typescript snippet is up on my other screen: function validateTaskArgs(cdata: any, ldata: any): [boolean, IDomainObject1, IDomainObject2] { if (cdata === null || ldata === null) { return [false, null, null] } const cdkeys = ["key1", "key2", "key3"] const ldkeys = ["key1", "key2", "key3", "key4"] const checkKeys = (keyset: string[], obj: any) => { const result = keyset.reduce( (p, c) => { return p && !!obj[c]}, true) return result } return [ checkKeys(cdkeys, cdata) && checkKeys(ldkeys, ldata), cdata as IDomainObject1, ldata as IDomainObject2 ] } This ugly bit of custom logic just to validate a pair of objects in a larger json datastructure, and even that has bugs. This can't deal with a bunch of problems, but it's just too much pain to actually string together the logic in a composable way in typescript, so I accept this kind of drudgery. But earlier I actually linked a much more sophisticated piece of purescript that's about the same size and not only is easier to read and is self-describing (the code to build the objects IS the spec), but it uses those properties to report console errors. You can see it here: https://gist.github.com/KirinDave/9af0fc90d005164743198692f380d4d9 https://gist.github.com/KirinDave/9af0fc90d005164743198692f3... If you want to make Elm better at JSON, that's the sort of stuff you wanna ask for. And folks will rightly be resistant. Because the programming concepts that make that work (free applicative, in this case) are not things the elm target audience has learned about, yet. Elm's leadership is acutely aware of how big a stack of new concepts they're putting on everyone's plate, and they're cautious about offering more.

449 points by Albert_Camus 9y ago

What an excellent article: from tech to business, from the human aspect to practical code examples. Worth a read, even if you're not considering Elm.

akuji1993 9y ago
Not into Elm at all right now and also kind of not convinced about functional programming, yet. But the article was definitely worth a read. I need to slowly open up for FP, I guess.
- moomin 9y ago
  I'll make an observation: I write C# for a living. The great thing about that is that it has a truly great debugger. But, as you rapidly discover, it's easier to debug some code than others. For one thing, you want to be able to go back to the start of the function and re-run it. That means that methods that mutate internal state are hard to debug. Also, it's even better if you can follow the chain of reasoning without rerunning the code. This means having a variable for each assignment, rather than overwriting an existing one. Finally, when processing large data lists, it's easier to debug if you have separate variables for logical steps. e.g. Get the employees of Company X (variable) that are managers (variable) and sum their salaries (variable). Trying to debug round a for loop is an exercise in frustration. What all these things have in common is: it's easier to reason about the values in a program than the program counter, and that destroying information makes it harder too. And that, to a great extent, is why FP is useful. Even really basic FP in C# or Java.
  - moogly 9y ago
    Dumb question: Have you tried IntelliTrace in VS Enterprise (sadly only available there)? It tries to solve many of the issues you're mentioning. You can even start a remote IntelliTrace debugging session in production.
    - moomin 9y ago
      Not a VS enterprise shop, sadly. Don't think I've ever worked for anyone prepared to pay for it! It does sound enormously cool. Does it also handle one of my favourite problems: when a method fails because a constructor parameter was wrong, it's pretty hard to rewind. With that said, VS Pro still has one of the best debuggers on any platform. To the extent that I think C# developers sometimes cut corners because the debugger helps so much.

anon335dtzbvc 9y ago

"JSON-based RESTful API as its back end" what language do you use for the backend, Haskell?

iamwil 9y ago
You can use anything that can expose an HTTP port. It doesn't have to be Haskell.

endgame 9y ago

I'm really looking forward to the day when all these new-to-Elm people start hitting the complexity ceiling of their language and convince the maintainers to add just a little more power. Example: Haskell's typeclasses have a high power-to-weight ratio, and Elm has to work around their absence (e.g., writing a fresh map function for each data type). Once there's a critical mass of frontend types who understand the power of FP, convincing people to try FP won't be the difficult step any more, and Elm won't need to try so hard to be un-intimidating.

chriseidhof 9y ago
Every added feature also adds complexity (and to be fair, in some cases, removes complexity). I love type classes, but I discovered in playing with Elm and specifically, TEA (The Elm Architecture) that the simplicity is also really nice even if you're comfortable doing type-level programming. There's something about Elm's simplicity that really works.
- endgame 9y ago
  Agreed, but Elm is hurting for some way to deal with this stuff. Currently, the API reference lies by claiming things like (==) : a -> a -> Bool, because it lacks a generic mechanism to let the programmer think the necessary thoughts. (The story for comparison functions like (>) is similar.) Now maybe Elm should stay simple and not jump all the way to multi-parameter type classes with functional dependencies, but it is already forced to pay some of the complexity burden to decide which types admit equality testing, comparison and so on.
  - ryanplant-au 9y ago
    Can you elaborate on what you mean when you say that (==) : a -> a -> Bool is a lie? I don't have enough experience with more powerful type systems to know what the more accurate claim would be. Do you mean that it should really be Eq a => a -> a -> Bool, because not all types can be checked for equality?
    - 9y ago

ToJans 9y ago

First: > Elm has an incredibly powerful type system Near the end of the article: >Want to decode some JSON? Hard, especially if the JSON is heavily nested and it must be decoded to custom types defined in your application. IMHO the lack of typeclasses/traits is really hurting Elm. Take haskell f.e. {-# LANGUAGE DeriveGeneric #-} import GHC.Generics data Person = Person { name :: Text , age :: Int } deriving (Generic, Show) instance ToJSON Person instance FromJSON Person While I understand Evan's aversion against complexity, it makes me a bit wary about using ElmLang in production. I am currently using TypeScript, but if I would need a more powerful type system, I would probably switch to Haskell/PureScript or OCaml/BuckleScript instead.

vim_wannabe 9y ago
In Rust you can also just make your struct deserializable, use a JSON lib to deserialize a string and get the corresponding object in a Result type. The amount of work you need to do in Elm instead is huge.
kccqzy 9y ago
That doesn't handle custom JSON schemas at all. I don't know much about Elm but at work in Haskell we mostly write FromJSON instances manually. It's probably the same amount of code as the data type definition.
- ToJans 9y ago
  For custom JSON schemas nothing tops F#'s type providers [0] IMO. [0] https://github.com/jet/JsonSchemaProvider https://github.com/jet/JsonSchemaProvider
  - jlouis 9y ago
    This is the way to go, if you are tied to JSON for some reason. A far better solution is to get rid of JSON if most of your stack is a typed stack and then convert to JSON as late as possible. Custom JSON which people invent as they go along is just going to present your system with pain over time.

acobster 9y ago

Great article! I have no experience with Elm but I'm much more likely to try it out now. I'm curious to hear your thoughts on this though: http://reasonablypolymorphic.com/blog/elm-is-wrong http://reasonablypolymorphic.com/blog/elm-is-wrong

walrus 9y ago
The core complaint is the lack of typeclasses. If your coding style relies heavily on generics, maybe Elm isn't for you.
- Skinney 9y ago
  Why? Elm has generics.

iamwil 9y ago

Having started using Elm for side projects over 3 years ago, the article is pretty much spot on. Programming in Elm had been a delight, especially when you let go of OOP and embrace functional concepts and practices. On one hand, you lose mental tools that you've relied on, but you gain the other tools you didn't even know existed before. Where I really disliked about Elm is when I had to encode or decode JSON. It's a giant royal pain in the ass. Also, when you find you have to break out to JS often for libraries you don't want to write yourself, it's not a good fit--as I found out when write a toy interactive notebook to render markdown in Elm. But for most SPA that just manipulate form data and communicate with the server, it's a pretty great fit.

kristianp 9y ago
Isn't decoding JSON a big part of an SPA though? How do you deal with data from the server?
- antouank 9y ago
  Once you handle a couple of complicated cases, you're ready to solve any JSON decoding within minutes. It's just a small learning curve to go through. Also, once you get the hang of it, you can use it as your safety layer for incoming data. To guard the app from any invalid response. I've even used GraphQL for one of my projects, decoding worked fine as well.
- enalicho 9y ago
  There exist multiple tools to aid you with writing decoders: - json-to-elm http://json2elm.com http://json2elm.com - swagger-elm https://github.com/ahultgren/swagger-elm/ https://github.com/ahultgren/swagger-elm/ - elm-graphql https://github.com/jahewson/elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql https://github.com/jamesmacaulay/elm-graphql - elm-export https://hackage.haskell.org/package/elm-export https://hackage.haskell.org/package/elm-export Once you've got the hang of it, it's not that hard either. Just time consuming. That's where json2elm comes in :)

PostThisTooFast 9y ago

They're using a decades-old E-mail client in production today? Impressive.

dmjio 9y ago

If decoding json in Elm is considered hard, I'd recommend checking out miso (https://github.com/dmjio/miso https://github.com/dmjio/miso), a Haskell re-implementation of the Elm arch. It has access to mature json libraries like aeson for that sort of thing, along with mature lens libraries for updating your model. Here's an example of decoding json with GHC.Generics using typeclasses. https://github.com/dmjio/miso/blob/master/examples/xhr/Main.hs#L130-L131 https://github.com/dmjio/miso/blob/master/examples/xhr/Main....

StreamBright 9y ago
This looks really promising. Do you use it in production anywhere? Do you have any comparison of features with Elm?
aaron-lebo 9y ago
This is very cool. The example apps are relatively slow to load compared to the equivalent in some other frameworks (my favorite is Mithril for an idea of how small/fast these can get). Was wondering whether it might be a slow server, but the app.js for the TodoMVC appears to be over a megabyte (1.21 MB, have a 4000 line Mithril app which is 500k uncompressed). What's up with that?
- StreamBright 9y ago
  Can you give exact numbers and a testing method of how you tested and determined it is slow?
  - aaron-lebo 9y ago
    The router example on Github loads ~1.5 MB of JS files. Mithril's entire framework is 8kb gzipped (including a router).
    - mbrock 9y ago
      ghcjs is a pretty heavyweight environment. It's actually translating the compiled core IR from GHC into JavaScript, and including a port of GHC's runtime system. It can run basically any Haskell library. That includes the ability to run multithreaded Haskell code -- the JS RTS includes a scheduler. You also get Software Transactional Memory. Lazy evaluation works just as usual -- and so on. The tradeoffs become worth it when you have a sufficiently valuable base of Haskell code that you want to run in the browser, and when your users aren't very constrained by page load time. Say, if you have some complicated tricky logic that you don't want to rewrite in another language, but you want to use it in your web app.

antouank 9y ago

After doing a couple of contracts on Elm projects for several months, and returning now back to a React-Redux stack project, I cannot emphasize enough how much better working with Elm is. In every single aspect. I just wish that it will get mainstream as soon as possible. His article is spot on, and agrees with what I've seen, and most others that used Elm. Just look it up.

BoiledCabbage 9y ago
> I cannot emphasize enough how much better working with Elm is. >In every single aspect. I just wish that it will get mainstream as soon as possible. I completely agree - I will be a huge benefit to the industry when elm is as common as js. The concepts it introduces, the benefits it shows are all huge. I've been programming a long time, and elm shattered my views of the relationship between a coder and his/her compiler. It went from being that thing you have to "pass" to see your code work, to instead a faithful companion. Like having a trusted dog with you in the woods - an extra set of senses to help you out on your way. Elm is not perfect (no language is) -but being perfect isn't the goal. A practical transition story, huge productivity gains and extremely maintainable code.
- antouank 9y ago
  Not perfect, but definitely a much better tool for that work (big front-end apps). JS was not meant for that, it's been stretched far from what it was (quickly) designed for. And sure, when more people join Elm, bad-written libraries or silly paradigms will crop up, but I'm confident it won't be as bad as the JS landscape is today. Time will tell I guess. -- Now back to stitching those JS libraries to write some code that might work. Bills have to be paid :)
- jnbiche 9y ago
  > I've been programming a long time, and elm shattered my views of the relationship between a coder and his/her compiler. I love Elm as much as the next guy, but be aware that you can get many, if not most, of these same benefits while working in JS if you use Flow.js or Typescript. I prefer Flow because the community is more oriented toward functional programming vs OOP in Typescript, but they're both capable static analyzers for JS.

deleted 9y ago

[deleted]

delegate 9y ago

Anyone familiar with both Elm and Clojurescript ? Clojurescript's 're-frame' lib implements something similar to the Elm architecture and is quite pleasant to work with. How does the Elm experience compare to the Clojurescript experience ?

mjaniczek 9y ago
Simple: writing code in Elm is compiler-driven development. As the article said: > Just start by changing your type definition and the compiler errors will help you find everywhere that needs updating. This is how most of Elm development gets done. I change the types and let the compiler tell me what actual code needs changing. Clojurescript, on the other hand, doesn't have this "assistant", unless you're using Typed Clojure or Schema (it's been a year or two since I tried that, so can't speak from current experience). The Elm Architecture is worth pursuing even in dynamically typed languages though :)
hellofunk 9y ago
Similarities: 1) Re-frame and Elm are both backed by a virtual dom (Re-frame leverages React behind the scenes, Elm uses virtual-dom) 2) Both impose a single app state 3) Both require user events and outgoing state mutation to be explicitly defined somewhere outside of the context of a view 4) Both operate on a sort of "game loop" style of processing events and calling view functions 5) All data is immutable in both languages (though Clojurescript provides explicit mutable structures if desired, which require special syntax so any mutation is evident) Differences: 1) Elm's model is pure FP -- data is passed to a function, and then it calls other functions. An individual view function in Elm cannot independently subscribe to any kind of data event, either a state change or a socket message, etc; it must receive the data it needs as an argument to the function only. Depending on who you talk to, this is either limiting or properly restrictive. It does mean that a branch of your Elm user interface should generally correspond to a single branch of your app state, or that view functions in complex interfaces must take quite a lot of arguments; this is a pattern for which re-frame explicitly offers a workaround (though you can also do it the Elm way in re-frame if you want). In general, these differences lead to more re-usable components in re-frame than in Elm. 2) Elm has no real asynchronous library for high-level concurrency. Most Clojurescript projects (at least large SPAs) often leverage core.async as an abstraction for large UIs that handle many independent processes simultaneously. Core.async makes clojurescript particularly versatile for accomplishing things in a single-threaded environment as if it were modelled with multiple threads. 3) Elm has its own compilation story that is separate from the JS ecosystem. The Elm devs are working on dead code elimination. Clojurescript projects are all built on Closure, which provides DCE, compression, and global inlining which can provide some projects notable speedups. The Closure libraries also give Clojurescript cross-browser abstractions for hundreds of common tasks in front-end development that have been battle-tested by Google in all of their web services, so it can greatly reduce development and debugging time for complex apps that run everywhere. 4) Elm controls JS interop much differently than Clojurescript. The tradeoff is that in Clojurescript you will inevitably spend more time debugging runtime errors, while in Elm you will spend more time developing your JS interop code and testing cross-browser compatibility. 5) There are many UI libraries available for re-frame because it can wrap existing JS tools (including wrapping UI libraries built for React). There are fewer for Elm, and it's more common to roll your own UI in Elm. There are pros and cons here. I've worked on two large projects in Clojurescript, one which was all custom UI components and another that leveraged polished libraries in the wild. The former took much much longer to make but looked more unique. Having the choice to go either way is a big benefit since project goals widely vary. If you are primarily a developer/coder and not a web/graphic designer, you may be frustrated at UI design in Elm. If you work with a designer, this is not a problem. But if you work alone, having access to a lot of UI tools can free up your time and efforts quite a bit, and Clojurescript has an edge here. 6) Types: Elm has static types, while Clojurescript offers clojure.spec (which is optional though widely used). Spec is a runtime contract system so you can guarantee that all args passed to functions or setup in data structures meet specified criteria; not just types of the args, but also any other predicates, such as a valid range for an integer, etc. For example, an Elm union type would be a Clojure set, where each element could be a specific data structure with other specs attached to it. However, Elm has proper static types, which are caught at compile time, not runtime. There are benefits of both styles. If you want to tightly catch very specific data aberrations that flow through an app, clojure.spec is easy to use for that purpose; but if you want more general checks before the program runs, Elm would be preferable. 7) Performance: All of Clojurescript libraries that wrap React (including Re-frame, vanilla Reagent, and Om) offer an interesting runtime optimization that I've not seen in other languages, and is not available in React itself. If the data that a view function requires (either via its arguments or subscription) has not changed from the prior render frame, then the entire view function is skipped without running, since its output would not be any different. What this means is vast sections of your app's code don't even need to run on each render frame, and this is not trivial. In a small app, it would make no difference, but in complex SPAs this can be very significant. Elm offers a library, Html.Lazy, that attempts something similar, though my impression is that most Elm projects do not use it since it can be tricky to explicitly add this behavior; in Clojurescript, it is built in automatically. In Re-frame, they go an extra step by de-duplicating any queries or subscriptions so that multiple views which use the same data context do not query, fetch or calculate the required data more than once, which is then passed to all requested functions. If you are working on an app that processes lots of data frequently, this can be the single selling point of using Clojurescript, as it frees up the CPU to deal with only those things that are guaranteed to require processing. Clojure's syntax is very tight and concise, while Elm's language is elegant but more verbose. I have found that there is approximately a 2.5X increase in code size in Elm when trying the same ideas out in both languages. All other things being equal, you can probably get a re-frame app going very quickly; if you need to prototype something or get to an MVP as soon as possible, it is really hard to beat Clojurescript compared to any other compile-to-JS language. If however you are going for application purity and a reduction in runtime debugging, Elm (or Purescript or some other statically-typed languages) would be a better fit. Ultimately, Clojurescript is a general purpose language, while Elm has a very specific use-case; if you fit into the Elm model, it can be nice. If you need to reach outside that model, it is a challenge.

therealmarv 9y ago

When JSON decoding is hard this is not a minor thing when looking at my RESTful APIs. This is a major trade off. How to deal with it ideally?

Albert_Camus 9y ago
Author here. JSON decoding is hard relative to what it is like in JavaScript. In your JS code you can just call JSON.parse() and get the corresponding JavaScript object. In Elm, decoding is not nearly as easy as it is in JS because every field must be explicitly converted to an Elm value. Depending on the complexity of your conversion from JSON to Elm value (e.g. whether you are just decoding to primitive values or to custom types defined in your program), there may also be a bit of a learning curve. As I stated in the post, there is a benefit in doing all of this: your Elm application will effectively type-check your JSON and reject it if it is malformed.
- Existenceblinks 9y ago
  > JSON decoding is hard relative to what it is like in JavaScript I'm not making a joke but this is a valid point. And if it had ELMON (Elm object notation), things would be more straight forward.
  - mavelikara 9y ago
    No, that is not a joke. If one tried to convert an Applet to HTML5 and came across a server backend that returned serialized Java objects, parsing that into JS would have been significantly harder than the two lines with ObjectInputStream it would take in Java.
enalicho 9y ago
Right now, there exist multiple tools for dealing with JSON: - json-to-elm http://json2elm.com http://json2elm.com - swagger-elm https://github.com/ahultgren/swagger-elm/ https://github.com/ahultgren/swagger-elm/ - elm-graphql https://github.com/jahewson/elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql https://github.com/jamesmacaulay/elm-graphql - elm-export https://hackage.haskell.org/package/elm-export https://hackage.haskell.org/package/elm-export It's worth noting that JSON decoding is not _hard_ as such, but it's harder than other parts of the language. It is more time consuming. Tools like these can help reduce the amount of time you spend hand writing decoders.

niels 9y ago

When I last tried Elm, I didn't find any really good UI libraries. Also there weren't any good solutions for i18n. Has the situation changed?

ocharles 9y ago
It depends what you mean by "good UI libraries", but there is http://elm-ui.info/ http://elm-ui.info/ for one. Perhaps that helps?
hellofunk 9y ago
Depends on your needs. If you are targeting desktop, there are a couple of UI libraries for Elm. However, they are buggy when you try to test them out on a mobile tablet. I have found that most Elm developers create their own UIs since wider access to JS UI toolkits is not easy. That does mean that you need to enjoy general web design or work with a designer, or be willing to put in extra time when working in Elm.
- niels 9y ago
  Yep, Agree. I specifically used elm-mdl and elm-ui. Elm-mdl were not well maintained and elm-ui, while nice, is desktop only.

dmitriid 9y ago

> making very heavy use of Ajax calls to a JSON-based RESTful API and then > Want to decode some JSON? Hard, especially if the JSON is heavily nested and it must be decoded to custom types defined in your application. Doing this will require an understanding of how JSON decoding works in Elm and will usually result in quite a bit of code (our application contains over 900 lines of JSON decoders alone). What a great pragmatic language

amimetic 9y ago
In exchange you get incredible validation of your JSON and precise error messages about missing fields etc. And you don't have to write that bit by hand: http://eeue56.github.io/json-to-elm/ http://eeue56.github.io/json-to-elm/ will generate the decoder for you for straightforward cases and give you a great starting point for more complex cases. You also get proper ADTs to manage state: not asked/loading/loaded/error something that is tedious and error prone in Javascript.
- dmitriid 9y ago
  Yup. There are a bazillion libraries now trying to pretend to make it look like it's easy to deal with JSON in Elm. An online converter is definitely not something I would advertise for a "production-ready highly productive amazing pragmatic language to be used in a serious company"
  - dmitriid 9y ago
    For god's sake, Elm is the only language I know that has _an entire book written on how to handle JSON_: https://www.brianthicks.com/post/2017/01/06/announcing-the-json-survival-kit/ https://www.brianthicks.com/post/2017/01/06/announcing-the-j... It's introduction is: "You know how it takes so much effort to produce even the simplest of programs when JSON parsing is involved? Wouldn’t it be nice if you could breeze right on by that step and get on with writing your business logic? This is what you’ll get with The JSON Survival Kit, a short ebook on JSON decoding in Elm." Wut

steinuil 9y ago

I've used Elm for a while and I don't really see what's the problem about JSON decoders/encoders. Sure, they're verbose and annoying to write if you have a particularly intricate JSON structure, but I don't really see a better alternative for decoding and encoding JSON in a type-safe way, and with Elm's constraints on ease of learning. More freedom on type-level programming would help, but that would certainly complicate the type system, and the only language I know that lets you fold over arbitrary record types is Ur/Web, which has a richer type system than even Haskell, and I don't see Elm adding things to its type system (other than type classes, hopefully), given that other interesting features were already removed because very few people used them.

nnq 9y ago

> One simple example is that of a three-way state What follows after this line is the most artificially complicated description of a problem I've ever seen... basically an excuse for the solution OP then goes on to suggest! Actually the more functional way to think of the artificially complicated problem OP describes here would be to have 2 data holders, a `myTagsData` and `myEditedTagsData` data, and when the user edits around `myEditedTags` is updated/synced, and when "Save" is clicked `myTagsData` gets replaced with `myEditedTagsData`... and we simply re-render based on new data in the context of a simple one way flow (hint: use React or something similar to not re-invent the wheel). Yea, sure, you can avoid state at all costs but you can also learn to properly manage state! There are places where one or the other is a good fit... but doing the former in order to avoid the latter is just "mental masturbation" imho... and the kind of things that disgusts some smart people and keeps them away from functional programming actually :(

fiatjaf 9y ago

I think JSON decoding is great in Elm. Actually, that may be the best part of that language.

bandrami 9y ago

I wonder if its successor framework will be called pine.

mLuby 9y ago
2019: JSON decoding in Mahogany-lang is hard…

unabst 9y ago

Quick question. > Want to measure the height of an element on the page at the moment a user clicks on it? Hard, in order to do this we had to make heavy use of event bubbling and writing JSON decoders for the native event.target object that is produced by an onclick event. What would be considered best practice? Is it best practice to re-implement this sort of thing? Seems one could easily find vanilla JS code and encapsulate it, or add a helper lib?

deleted 9y ago

[deleted]

noshbrinken 9y ago

Something I find incredibly off-putting about Elm is the evangelical and generally unbalanced tone taken by many prominent members of the Elm community. I almost never come across Elm advocates accepting a valid criticism of the language. The response almost always amounts to "you don't understand" or "yes, but". They spend a lot of time celebrating the compiler's humanistic virtues but seem less clearly humanist in their relation to original thinking or diversity of thought. So much of Elm community dialogue (in talks, in articles, in the Elm slack which I follow daily) is simply those with more experience initiating those with lesser experience into the "Elm way" of doing things. For this reason, Elm feels more like a framework with a domain specific language than a fully qualified programming language. And while it might seem like a gentle introduction to functional programming techniques, I'm not confidant that it really teaches people the concepts themselves nor gives them enough room to think critically about how to apply them. Instead, the task is to internalize and apply the "Elm way". The inability to even acknowledge the unprecedented labor required simply to parse a JSON response is a perfect example of the cultish mentality emerging in this community.

KirinDave 9y ago
> less clearly humanist in their relation to original thinking or diversity of thought So what you're frustrated with is that a group of likeminded individuals celebrates their common point of interest and doesn't make room for you to nay-say them? > So much of Elm community dialogue (in talks, in articles, in the Elm slack which I follow daily) is simply those with more experience initiating those with lesser experience into the "Elm way" of doing things This could be said of a lot of PL environments. How many Python tutorials stop midstride to browbeat you about how great Python's way of doing things is? Sure feels like a lot to me. > The inability to even acknowledge the unprecedented labor required simply to parse a JSON response is a perfect example of the cultish mentality emerging in this community. Right but... what do you want? Acknowledgement? My friend, literally everyone here is agreeing it's harder than JSON.parse. No one argues it is "easier." I can't find a handy example in this thread of anyone saying, "Yeah this is great." There are tools to ease this pain, and there are ways to call external JS code that does this. At the end of the day though, validating data structures on the wire both structurally and for content is a lot of work. Most Javascript projects don't do it. Hell, most typescript projects just say, 'Well if it breaks it breaks.'. By pure coincidence this redacted typescript snippet is up on my other screen: function validateTaskArgs(cdata: any, ldata: any): [boolean, IDomainObject1, IDomainObject2] { if (cdata === null || ldata === null) { return [false, null, null] } const cdkeys = ["key1", "key2", "key3"] const ldkeys = ["key1", "key2", "key3", "key4"] const checkKeys = (keyset: string[], obj: any) => { const result = keyset.reduce( (p, c) => { return p && !!obj[c]}, true) return result } return [ checkKeys(cdkeys, cdata) && checkKeys(ldkeys, ldata), cdata as IDomainObject1, ldata as IDomainObject2 ] } This ugly bit of custom logic just to validate a pair of objects in a larger json datastructure, and even that has bugs. This can't deal with a bunch of problems, but it's just too much pain to actually string together the logic in a composable way in typescript, so I accept this kind of drudgery. But earlier I actually linked a much more sophisticated piece of purescript that's about the same size and not only is easier to read and is self-describing (the code to build the objects IS the spec), but it uses those properties to report console errors. You can see it here: https://gist.github.com/KirinDave/9af0fc90d005164743198692f380d4d9 https://gist.github.com/KirinDave/9af0fc90d005164743198692f3... If you want to make Elm better at JSON, that's the sort of stuff you wanna ask for. And folks will rightly be resistant. Because the programming concepts that make that work (free applicative, in this case) are not things the elm target audience has learned about, yet. Elm's leadership is acutely aware of how big a stack of new concepts they're putting on everyone's plate, and they're cautious about offering more.