I’m looking to build a “game-story dialog” editor, data gets stored in JSON file, the JSON should be manipulated by friendly GUI Elm app with dropdown menus, radio buttons, textlabel, inputboxes, scrollbars etc to create more editable storyboards and substories. You know, it’s basically just a tool to write stories in a glorified story diagrams or in other simple GUI format.
At some point it has to become a PWA (not high priority), but I don’t want it to be a browser only thing forever.
My problems:
I’m complete beginner in Functional Programming. (Programming language I “master” are GDscript (Python dialect), Javascript, C#… I tried to get into F# and Haskell but I find no reasons for the effort.
That leads to next fear:
I would like to build webapp rather quickly, I don’t want to spend months (or even years) learn Functional Programming to learn another month(s) to learn Elm. Can I just learn and use Elm comfortably and productively in matter of weeks, or is there some long road ahead?
I have a somewhat experience with React but I’m eager to try a new better/framework to main, it’s going to be Svelte or Elm… or React, but I’m not a fan of “you have 30 framework addons (routing) to solve the problem X”.
I would say that it should be quite easy to learn and to get started. The only problem I see is that having a lot of GUI elements can result in a lot of boilerplate code that lets the size of the project explode. I realize more and more that this actually also happens in other languages, you most often just don’t notice it as much and then suddenly you have a lot of weird bugs.
You want something quick and dirty? Then don’t use Elm. You want to really understand how FP works? Then use Elm.
I hope it’s possible to make something quick when you are “fluent” with Elm!
True, the bigger the application the more code is involved, It’s inevitable. But I believe Elm splits code base in modules/components as well right, similar fashion as React does? Or… not?
UI elements do not have to be stateful components. It’s totally reasonable to have a module for a view element and not need to recreate TEA. I often have:
module Ui.SomeElement exposing (view, Events, Data)
import Html exposing (Html)
...
type alias Events msg =
{ foo : msg
, bar : String -> msg
, baz : Int -> String -> msg
}
type alias Data =
{ title : String
, id : Int
, somethingElse : String
}
view : Events msg -> Data -> Html msg
view events data =
...
This works fine for many things. And honestly, there’s a brief complexity and conceptual cost when adding a stateful component to your project, but once you’ve paid that cost you only pay again in a little bit (more) boilerplate for everything else.
Start with elm create app, that gets the PWA basics done.
And I would say with Elm you can iterate very fast, as you don’t have to spend time debugging. Just like you I learned functional programming through Elm, and I’m very grateful to Evan for creating a language to make FP accessible.
We have been using Elm in my company for some 3 years now. Before that we were mostly working with PHP, React and Javascript.
Our developers (about 15) were quite productive in Elm after less than a month, without having any previous experience with FP. I would encourage you to try it.
Still not confident yet about Elm, do you know the strength of Elm and the disadvantage of Elm compared to React? I would like to know more about that part.
I wrote React professionally for 4 years at large and small companies, and Elm professionally for 8 months at a smaller company. I’ve also written both for years with my hobby projects. Given all that, I find myself to be significantly more productive with Elm.
Reasons I would choose React over Elm today would be, in no particular order:
My team refuses to learn Elm
I needed to use a package that’s specific to React
and that’s it. Everything I’ve ever built in React, could be built in Elm and it would have been easier, faster, and more maintainable.
For someone who’s not me another reason to choose React over Elm would be that you need to build your app now and you’re already familiar with React. But if you have time and are willing, I’d definitely recommend Elm over react.
My experience is pretty much exactly what @wolfadex said. The only reasons I would not choose Elm is because people are not willing to learn it, or if there are highly specific requirements which would make intergration hard(I have yet to come across a scenario that could not be adequately worked around with ports or custom elements). Elm helps producing high quality code that is also fun to write. Most React projects I worked on sooner or later became very messy and very risky to refactor.