You can use elm-format and never think about formatting again.
Instead of mixing html and js why not use function calls for everything. I believe there would be no jsx if javascript would allow function calls without the parens.
That philosophy works better when the style you enforce is, if not happily accepted, at least not moderately controversial. Otherwise many developers will choose simply not to use x-format—or worse, be turned off from the language.
In such layout-block languages (without curly braces and semicolons for denoting blocks and "statements") it shouldn't be a big deal one way or the other anyway..
Yep, I think the emerging tradition with Elm is just to leave it to elm-format. I wonder if tooling may end up being the answer to composability and boilerplate too, though I'm not sure quite yet how.
There is no boilerplate in Elm if you don't write self-contained components and you really shouldn't. You end up with huge model/update/view functions that you split down into modules. Here is an example app - https://github.com/knewter/time-tracker.
Really cool app! I'm going to study this. I'd love to put the app I'm working on up as an example to share lessons learned but it's commercial work, so I'll have to make another hobby one in the future and use that :)
I alluded a bit to it in another comment here, but I'm not entirely convinced that the "you shouldn't write components" is a good design target overall vs. just being a necessity because of the limitations of Elm the language right now.
It probably hinges on what you mean by 'component'. When I say 'component', I mean a bit of UI I'm planning to reuse across multiple pages, where there might be some private model, where I would not want the internals of that model duplicated across and polluting otherwise clean page models.
Here is an example that comes to mind: I have common functionality across pages in my app where I want to let the user edit a database field.
To do this, the user can select the list of fields from a drop-down or they can type the field name into a search box, with choices being displayed as they type in real-time; they can then click on a choice and edit that field.
To submit the edit, they click an 'Update' button.
Now, this functionality is shared across different pages in my app. None of these pages should, IMHO, necessarily have to care about the intermediate states of the field-list as it is auto-completing. I simply want a function I can call from any view like this:
renderChoiceThingy : List FieldChoices -> ChoiceThingyModel -> msg -> Html msg
renderChoiceThingy fieldsToPickFrom model actionOnSubmit =
....
Not only might I want multiple instances of this same thing across many pages, but I'll also want multiple instances of it on the same page sometimes. For example, let the end-user build up a list of changes and then submit them all in a batch or cancel them all at once.
Without treating this like a self-contained unit, I'm now duplicating model bits in all my pages that use this function. So it's nice to wrap that control up into a module, with its' own 'update' and 'view' and have appropriate parameters to allow the proper message types to work.
Another example (not one I've implemented); say you have an interactive colour picker, that you can click on an icon to exapnd, select the colour you want by changing sliders interactively, then have the picker disappear and the page know what colour you've selected. To me, the containing page shouldn't care about all that slider stuff and all the messaging and updating that goes on, just to draw the picker.
Would love to hear other Elm devs thoughts on this. These are the kinds of examples I don't see directly addressed when people say "don't write components". Though I suspect, having not used other 'component' frameworks like React, that people might generally mean something slightly different to what I'm thinking when they say "no components". Really interested to find out what others think about this.
If you haven't seen it, take a look at elm-sortable-table [0]. It's an example reusable view, written by Evan, that's meant to demonstrate exactly what you're asking about.
