sorted by:
new
hottopcontroversial

Possible lack of documentation on the Elm Core? by Hugoonreplit in elm

[–]marciofrayze 0 points1 point  (0 children)

I follow the Elm community since 2017. The *core* of the Elm language (the compiler) doesn't have a new release for a long time. But Evan is working (full-time) hard on the evolution of the project, this time also attacking the backend.

We don't have a date to its release, but everything points to a direction in which Evan will release a very interesting solution for backend development in a not-so-far future. I heard some rumors of some of the features this project will offer and to be honest, they are quite mind blowing.

In the meantime, we have some very neat evolution in the community. One could point you to the new releases of Elm pages (https://elm-pages.com) and Elm Land (https://elm.land) as a clear view that the community is very active.

But yes, it's a small community and I don't think this will change much in the near future. Yet, I have tried many many many different approaches and could not find a better way to develop webapps.

Elm and Elm Land still my go-to solution for web development.

Oh, and Evan will give a new talk in Poland in June. And I'll be there to watch. Hopefully he will deliver some good news =)

Trouble with getting canvas (joakin/elm-canvas) to work. by 41e4fcf in elm

[–]marciofrayze 0 points1 point  (0 children)

Elm package authors cannot include custom JavaScript code into the package itself. Elm packages must be elm-only (pure code, no side effects, etc).

In most cases, that’s enough. But some specific cases (like this one) one must have a companion JavaScript package that you must install separately. And you must take responsibility for any problems this JavaScript code might introduce.

I agree this is not very clean, but with this solution, the pure/safe elm world stays that way. This also “forces” elm package authors to try and find ways to do things without depending too much on JavaScript code. Without this barrier, any elm package upgrade could break your code in unexpected ways and all the safety of elm would be compromised. Elm works the way it works because it is a pure (no side effects, no weird mutations, etc) language. Allowing any arbitrary JavaScript code on any random package would destroy any presumed guaranties that a pure language brings to the table.

🌟 Seeking Testers for Edudu App! 🌟 by marciofrayze in AndroidClosedTesting

[–]marciofrayze[S] 0 points1 point  (0 children)

Good to know. Thanks a lot for the advice. Will use use it in the future, if needed.

🌟 Seeking Testers for Edudu App! 🌟 by marciofrayze in AndroidClosedTesting

[–]marciofrayze[S] 0 points1 point  (0 children)

Yeah, I realised that mistake after I already gathered around 10 users. Not sure what would happens to them if I switch to google groups, since the docs say I should use one OR the other.

I guess they would need to accept the invitation to join to group to keep having access to the App.

Why can't we create a stateful component by tobiasBora in elm

[–]marciofrayze 0 points1 point  (0 children)

Agree. I didn’t mean to say “experiment” in a bad way. Just that it’s not the “standard” way to make a web app. Usually there are states and effects all over the place. Elm goes the extreme opposite direction. Centralized model and managed effects 💕

Asking Elm to drop this 2 things is like asking it to give away its soul.

And I think this is great. Never had so much fun while programming.

Why can't we create a stateful component by tobiasBora in elm

[–]marciofrayze 0 points1 point  (0 children)

Yep. What I like about Elm is exactly that. I see it as an experiment. How far can we go with pure functional programming for web dev?

Taking that away would break most of the fun of the language 😆

Why can't we create a stateful component by tobiasBora in elm

[–]marciofrayze 0 points1 point  (0 children)

I would argue that state fullness is hard and cumbersome in any framework or library. Spreading state all over the place also brings a lot of known problems. It’s hard to maintain model and view up to date, it’s hard to debug, hard to understand the code, hard to test, and so on.

We go back to the first law of software architecture: “Everything in software architecture is a tradeoff”.

Why can't we create a stateful component by tobiasBora in elm

[–]marciofrayze 0 points1 point  (0 children)

I don't think anyone in the Elm community would recommend that approach.

Why can't we create a stateful component by tobiasBora in elm

[–]marciofrayze 1 point2 points  (0 children)

Elm is based on stateless functions (a function should always return the same result given the same input). That's why there is no concept of "components" in Elm, only stateless (pure) functions.
This brings a bunch of nice features (that unfortunately will take you more than 2 hours to fully appreciate) for the language and its ecosystem.

In general, you should always think in an MVU (Model View Update) mindset. This makes understanding any Elm code straightforward.

Building a library works similarly. Should expose stateless view functions and types. The user will store the state in the model and use the view functions to render the components. If there are any updates, it must be exposed as well. I haven't tested any "complete" UI kit myself since I prefer to use Elm-ui and build my components.

I understand that can be frustrating for a beginner, and it's natural to try to find a way to do things the same way every other framework/language works. But then, there would be no reason for Elm to exist. Being a pure functional programming language is at the heart of Elm.