| 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. |
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.