I think there are two important topics surfacing on this thread that are 
important to differentiate.

The first one is the first message from Peter Damoc, addressing collaboration 
and bottlenecks. Personally I agree that the situation can improve, and that 
the bus factor seems too high. Personally I was quite sad to see that I 
couldn't even contribute typo fixes to the elm guide when I was going through 
it. For such a friendly language when working with it, it seems very community 
averse in many places. I felt like I wasn't trusted or welcomed, neither my 
time or contributions, so I haven't bothered to even try further. I'm not sure 
if this happens to others, but if it does then it means we're losing on 
creating a community of contributors, which is an extremely important factor to 
keep the ecosystem working at scale if the language wants to grow.

---

The second issue, related but different I think, is the one explicitly 
mentioned by Ryan Rempel and Daniel Bachler about sharing solutions for common 
problems. How do you deal <common-problem-that-needs-interop> in your elm 
project? You usually copy and paste files from another project, or code from 
gists into your source folder. This is bad and sad. There is only a way to 
share pure Elm code with elm-package, but the world is far from pure, so we are 
left dead in the water. We need a way to share our impure, not 
elm-package-worthy code, to stop having to copypaste code from place to place 
without versions and tests and being out of sync.

This is not the case of things like localstorage, that belongs in platform as 
mentioned in other emails. This is the case of things like Firebase 
integration, or Google Analytics, etc. Firebase is not web platform, and it is 
always going to be a wrapper over google's official firebase implementation. I 
wouldn't want an official elm-lang authored library for firebase as if it 
belonged in the web-platform, it is a propietary platform and library and it is 
not worth supporting it officially.

But if we want to use Elm in production for real projects, we are going to need 
to version and test and share wrappers over these services. Copypasting is not 
going to cut it, that's why we need community and production projects creating 
and supporting libraries that do and need interop, and a shared place to get 
those libraries and work together without blocking progress on platform and 
core language.

---

Addendum: I'm loving the civil discussion on this thread and I'm happy to see 
I'm not alone on my thoughts. Goes without saying great thanks to Evan for his 
work, we just want to use it more, and make it thrive.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to