On Fri, Jul 8, 2016 at 9:28 PM, Evan Czaplicki <eva...@gmail.com> wrote:
> What about the other stories? > I have tried to use Elm in a work context and I'm becoming one of those sad failure stories that can be used with the "caveat emptor" label. > I have seen people *try* other paths. They don't work though. So I'd love > for there to be other paths, but I have not heard of another one. > Of course they don't work. The main reason for this is the lack of an Elm component architecture that would allow people to create reusable components that can be bundled in libraries. If someone wants to implement a 1996 webpage in Elm, they can do that with the current technologies. If someone wants to implement a 2016 webpage in Elm... tough luck! They will have to reinvent multiple wheels and few people have either the time, energy or the know-how to do that. *Do you have a story of someone implementing a simple user form in Elm and enjoying both the experience and the result?* I'm not talking about something exotic or completely out of the ordinary here. Just some textfields for First Name, Last Name, username, password. A switch for gender and an Address subform with a filter/search dropdown for State/Country. This is trivial in Html/CSS/JS land with the help of (take your pick: Bootstrap, SemanticUI, AUI, etc.) When I discovered Elm it promised to offer a nicer interface to creating web apps and isolate people from the insanity of HTML/CSS/JS. I don't know enough HTML/CSS/JS and so this was tremendously attractive to me. Graphics.* elements were a huge step in the right direction (API wise) and people loved them but they were abandoned without an alternative. And now we live in a world where the best path for approaching Elm is embedding it into a React component. :( Elm should have been the alternative to React. You should have been writing articles about how to port React components to Elm components. elm-make/reactor could have replaced the entire insanity of the JS build tools. Sadly we do not live in that world. We could have, but we don't. There have been people who have tried to approach this (e.g. elm-mdl) but they were explicitly or implicitly dismissed. You seam to have buried your head in the sand and ignore the issue of components considering that it is solved with The Elm Architecture. It is not solved and the countless questions about communication within a components hierarchy are a proof of that. The More About Modularity <http://guide.elm-lang.org/architecture/modularity/more.html> page from the guide that's just promising "more soon" is a testament to how bad things are. I remember when this section had "Nesting" and "Communication" which were things people are truly interested in. The process that prevented this section from reaching completion is the very essence of the biggest problem with Elm right now. Who, beside you Evan, understands The Elm Architecture *well enough* to write that section to your satisfaction ? It looks like the answer is *no one*. How about getting rid of Signals and leaving empty the Effect Mangers section of the guide? You know, the one that was suppose to deal with their replacement. You do tell them that the exotic stuff that they might have used Signals to implement can be implemented easier with the Effects Managers BUT give no clue about how they could go about doing that. But I'm glad that developers that have already added few hundred kb of the React library will be able to add few hundred more from the Elm runtime so they can get a 1.7 MB of JS simple echo app. ;) I might sound unduly bitter but I'm slowly losing my hope in Elm and this brings me tremendous sadness. -- There is NO FATE, we are the creators. blog: http://damoc.ro/ -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
