This is one post in a series to begin focused discussion about ideas that came out of our 2018 GSoC Brainstorm.
Please use this post as a place to begin to discuss this idea more in depth.
It was proposed by @ebrehault and it has been suggested that @gotcha might be a good mentor.
The idea description: "Implement Plone frontend in Elm"
Go for it, community! Make this one shine!
Seriously, stay mainstream and do not force ppl to learn yet another language or new concepts. This blocks adaption.
thanks for the input, @zopyx. Let's see what everyone has to say.
As this is a proposal for a front-end application, separate from the backend API, you could see this as a way of inviting folks who love Elm to participate in the Plone project. Who knows. There might be some love out there.
Compelete Pastanaga in Elm is unrealistic, but I should be able to mentor any project building UI components agains Plone Rest API in Elm, because also my employer would be interested in that.
Seriously, please stop this yet-another-configuration-lnaguage nightmare..it hurts adaptation. Stay mainstream.
You are taking this too seriously. Let’s put it other way: having Plone to pop up as a GSOC organization for a student looking for Elm related projects could bring us good candidates for any project.
@zopyx, what do you mean by "yet-another-configuration-language"? That's not what Elm is, is it? I'm with @datakurre on this. Widening the funnel of users who interact with Plone at any level can only be a good thing for community growth and sustainability.
Hey i dont know much about Elm, i went through on what Elm is and want to ask if Elm has an edge over what the front-end is implemented in?
An Elm implementation sounds like a very interesting idea!
My 2 cents: Having implemented Pastanaga with React, I have some doubts about the Pastanaga part though. There are still lots of rough edges and UX details that we have to figure out when it comes to Pastanaga. We are currently in the process of doing so for the React implementation but this is a non-trivial task that requires lots of work. I see the risk that we start to implement several half-ready Pastanaga implementations before we even fully figured out how things actually are supposed to work. In addition, we will waste time on multiple implementations instead of focusing on one.
I see two options:
Keep the UI out of the GSoC and just implement a library with a minimal example implementation (not sure how well Elm supports the library approach, this also might be too hard for a GSoC student)
Rely on Semantic UI to being able to share styles across the different implementations. We use Semantic UI for the React implementation and we are fairly happy with it. Semantic has implementations for React, Angular, Ember, and other libraries. There is also an Elm implementation: http://package.elm-lang.org/packages/b52/elm-semantic-ui/1.1.0 (Though, I am not sure how mature this package is, something a possible mentor might want to figure out)
Timo
@tisto, thanks for the thoughtful analysis of the issues with this project. I'd love to hear feedback from anyone else involved in this discussion about the point that Pastanaga still needs to be ironed out. Would working on the react version of Pastanaga be a possible GSoC project? It does sound like there's significant work remaining there. Is it well enough defined that it could be pushed forward or even completed (at least in part) by a GSoC student?
Hello, to Everyone
I am Mritunjay Goutam . First message to Plone community.
I do not know why Elm for frontend implementation. @tisto if we concern for semantic UI can we go with Vuejs semantic UI(https://semantic-ui-vue.github.io/#/) or more better Vuetifyjs(https://vuetifyjs.com/vuetify/quick-start).Vuejs is also very cool and with great features.
I am B.tech student from India and I am participating in GSoC 2018. I did my GSoC 2017 from CMU Sphinx(javascript developer).
Sincerely,
Mritunjay goutam
The topic is available for students interested to do GSOC with Elm and able to write good enough proposal to compete with the other proposals (eg for React and Ng which already have existing base for Plone). If you do not agree with the benefits of Elm over other languages/frameworks, this may not be for you.
Ok, I uderstand.