I've updated a few of my projects to 0.18 over the last couple weeks. The new HTTP library is much better than the one before. Working with Authentication Tokens, decoding errors etc is much easier now.
I also welcome the continuous work to remove things which are difficult for beginners and make code less readable, like the backtick syntax and the prime notation.
I mostly work with backend code, and I wanted to learn some JS but found the ecosystem hard to swallow. Elm offers a very practical, and quick to get started experience for writing reliable frontend. For a quick win with UI work, also check out the Elm-MDL library. https://debois.github.io/elm-mdl/
---
Coincidentally, I was watching MPJ's FunFunFunction today, where he talks about JS libraries that coerce HTTP statuses into JS errors, and he managed to articulate some of my frustrations with elm-lang/http. The library tries to be helpful by returning a `BadStatus (Response String)` error if the status is not a 20x code. An error is what I want sometimes, but far from always. The result is also a string, while most of the API's I interact with return JSON for errors.
Http does allow you to get the raw data and treat it as you will. It also isn't that much code. Check out the custom requests section of the documentation.
At work we developed internal tool in Elm + elm-mdl for listening to specific events and notifying developer on their status change. It takes about 5 minutes to understand what is going on in application by just reading Model/Update. One person can refactor almost whole app and be sure he did not break a thing. Most issues we got were in ports (JavaScript). Also the same page is running as Chrome Extension and Firefox Extension.
I can say that development performance was 3x than the same developers in JS. Plus you don't have to write unit tests and deal with grunt/gulp/npm packages nonsense.
We got only one runtime exception - our state was saved in localStorage and pushed into Elm.embed when page was opened. If this format changes in Elm/localStorage - Elm fails to start. It would be nice to get some promise rejected when you do Elm.embed() and it fails to initialize. But we can write our own Json.decoders and parse state inside application - in such case we can even write data migrators for user data.
Next stop for us will be to rewrite some views into Elm and integrate them into huge our JS project.
I'm glad Evan took out some of the Haskellish syntax that non-Haskellers find confusing, like the x' variable names and backtick syntax.
The decision to write something with backticks or the pipe operator seemed to be a matter of personal taste, and I like a system where these less-important decisions are already made.
I've been waiting for 0.18 in anticipation because I had heard we might get server rendering.
Instead a bunch of language and syntax that I enjoyed was removed from the language, but I get better bug reports? The export button is broken unless I click "resume" which I find pretty odd.
I have to say I'm really disappointed, every release they just remove language features.
What has been removed is just syntactic sugar that can easily be acheived in other ways. I think it's a good thing that Elm's core is kept as clean and simple as possible. There are enough other languages with a kitchen sink philosophy.
[+] [-] zalmoxes|9 years ago|reply
I also welcome the continuous work to remove things which are difficult for beginners and make code less readable, like the backtick syntax and the prime notation. I mostly work with backend code, and I wanted to learn some JS but found the ecosystem hard to swallow. Elm offers a very practical, and quick to get started experience for writing reliable frontend. For a quick win with UI work, also check out the Elm-MDL library. https://debois.github.io/elm-mdl/
---
Coincidentally, I was watching MPJ's FunFunFunction today, where he talks about JS libraries that coerce HTTP statuses into JS errors, and he managed to articulate some of my frustrations with elm-lang/http. The library tries to be helpful by returning a `BadStatus (Response String)` error if the status is not a 20x code. An error is what I want sometimes, but far from always. The result is also a string, while most of the API's I interact with return JSON for errors.
https://www.youtube.com/watch?v=gRsyY0kzXfw&feature=youtu.be...
[+] [-] Skinney|9 years ago|reply
[+] [-] gladimdim|9 years ago|reply
I can say that development performance was 3x than the same developers in JS. Plus you don't have to write unit tests and deal with grunt/gulp/npm packages nonsense.
We got only one runtime exception - our state was saved in localStorage and pushed into Elm.embed when page was opened. If this format changes in Elm/localStorage - Elm fails to start. It would be nice to get some promise rejected when you do Elm.embed() and it fails to initialize. But we can write our own Json.decoders and parse state inside application - in such case we can even write data migrators for user data.
Next stop for us will be to rewrite some views into Elm and integrate them into huge our JS project.
[+] [-] omouse|9 years ago|reply
[+] [-] twoquestions|9 years ago|reply
The decision to write something with backticks or the pipe operator seemed to be a matter of personal taste, and I like a system where these less-important decisions are already made.
[+] [-] ronjouch|9 years ago|reply
[+] [-] omouse|9 years ago|reply
The x-prime looked like the elm equivalent of mysql_real_escape from PHP.
I've only been using the pipe syntax and this makes things simpler; backticks are special syntax, pipe syntax is just another function.
[+] [-] leshow|9 years ago|reply
Instead a bunch of language and syntax that I enjoyed was removed from the language, but I get better bug reports? The export button is broken unless I click "resume" which I find pretty odd.
I have to say I'm really disappointed, every release they just remove language features.
[+] [-] erokar|9 years ago|reply
[+] [-] ORioN63|9 years ago|reply
[+] [-] worldsayshi|9 years ago|reply