[dhucerbin]

Ports are not really a solution for rendering code. Obvious example is internationalization API. It’s not feasible to communicate back and forth through port every time you want to format a date.

Some folks propose web components but that’s another can of worms. Increase in complexity and still no help from compiler.

[madsbuch]

> It’s not feasible to communicate back and forth through port every time you want to format a date.

Why not? Is it code complexity or runtime inefficiency you are referring to?

[dhucerbin]

Actually both.

Let's say that on desired page, you have three components with dates somewhere - date of article, dates of comments below and date of last login in the header.

After some user action, you navigate to this page. In Elm terms that mean your Model updates and then your rendering functions will run.

Only then you can see that you need to format dates - your rendering function should be responsible for formatting.

Rendering function should be synchronous - so you need to return some string for date - "loading state" or default format. So user gets "flash of unformatted date".

Now, you should somehow communicate with Port - that mean, send asynchronous message "format this date for me". (And sending messages in render function is not something really supported out of the box in Elm)

Then Port comes back with response, you need to put this formatted value in your global Model (some kind of Dict from unformatted to formatted dates?) and that triggers another render with formatted value.

In summary: - you have multiple render loops where one would be enough - you pollute your global Model with junk that could be easily derived - you introduce latency in rendering because Ports are asynchronous

Ports are great for interaction - user clicks something, you can send command and wait for response and update your model. But there are a lot of cases where you want use synchronous, pure function from Javascript like Intl API.

[madsbuch]

So, the elegant way to solve this would be to use an Elm i18n library and just use ports to get the users region instead of formatting every single string.

I understand that it is hard for a software developer to accept that these things need to be reimplemented, but it also seems to be a natural consequence of "up-typing" an entire eco system.

I studied formal techniques for PL. A large portion of the work was in reimplementing existing things in Coq, HOL, etc. Not particularly interesting, but necessary to reach a mature ecosystem.

I do undestand that this makes it a no-go for a lot of people until these things have been implemented. This is also natural.

[dhucerbin]

> but it also seems to be a natural consequence of "up-typing" an entire eco system.

Reimplementation of i18n API in Elm would make sense only if benefits from types could outweigh robustness of browser implementation. Due to not very expressive Elm type system I really doubt that. You can’t capture intricacies of i18n in Elm type system.

I have more confidence in already tested and used by millions API in the browser than in reimplementation in niche language.

Elegant solution would be if I could write well typed layer that calls browser API. Low bar of entry would drive adoption and in effect real world test. But that’s not possible anymore.

[madsbuch]

> Elegant solution would be if I could write well typed layer that calls browser API

Not if your goal is correctness.

Again, it is completely OK that Elm is not your choice if it does not align with your values, which appears to be the case.

[dhucerbin]

> Not if your goal is correctness.

Could you define correctness in this context? I'm asking because I don't believe that you can achieve correctness using Elm type system. I don't see how you can encapsulate i18n rules inside Elm type definitions. Maybe something like Coq could do this ...

You can't express something like "if passed 3 as group size, integer part of the number should be represented as string with separators between three digits". Even in Elm that's something that you need to handle not in type system but in runtime code.

What is more - many core packages are just this - typed layer over browser API. elm/regex introduce barely any type safety. It assumes that browser API is "correct".

> Again, it is completely OK that Elm is not your choice if it does not align with your values, which appears to be the case.

I often see this response from Elmers but really I don't understand the point of it. I responded to claim that Ports solve all problems. I provided good, real example where Ports are a bad solution. In return I was scolded that I don't understand software engineering.

I don't jump into elmconf and complain or demand changes. I just provide my take on the discussed issue. And to be frank, I think that's very valuable take for someone who decides if Elm is good for them. That kind of information is not present on elm homepage and is not obvious for new users.

[gampleman]

The problem with I18n in particular is that reimplementing in Elm causes pretty unreasonable download size bloat.