I had submitted a couple of talks on advance Elm usage for elm-conf,
but sadly that never happened. I have however talked about this kinda
thing in local meetups and in the remote meetup. Sadly the most
interesting and relevant one (on how to not get blocked with Elm in
production) failed to record correctly. These are the kind of talks
that I've been heavily recommending elm-conf should focus on. There
are so many intro to elm talks.

Maybe elm-conf EU will have more focus on that.



On Thu, Nov 24, 2016 at 7:58 AM, Zachary Kessin <zkes...@gmail.com> wrote:
> I think we are only differing on the details. We could use talks / blogposts
> on all of those things. If you want to write a guest blogpost on any of the
> above I would be happy to put it on my blog.
>
>
> Zach
>
> On Thu, Nov 24, 2016 at 9:31 AM, Peter Damoc <pda...@gmail.com> wrote:
>>
>> I beg to differ.
>> There are a lot of intro talks to Elm syntax and some of them touch a
>> little bit on some libraries but we are doing very poorly in addressing
>> important concerns like styling, persistence or deployment.
>> Of course, one might argue that this falls outside of Elm concerns but
>> should it be outside of Elm's concerns?
>> Are we trying to build reliable webapps or are we trying to reliably
>> generate html?
>>
>> The domain covered by CSS is virtually unexplored in Elm. It is taken as a
>> given that people will solve this on their own using previous knowledge or
>> by learning CSS somewhere else.
>> There are a few libraries that attempt to address this but most of them
>> are bindings to CSS with a little bit of type safety thrown in and do a very
>> poor job at documenting use-cases.
>>
>> The topic of reusable components is still in limbo.
>> If someone asks me how would they do a dropdown in Elm I still don't know
>> what to say (other than implement it from scratch).
>> Have the sortable-table solution and the auto-complete examples been
>> imitated? Do we have a large pool of reusable UI elements?
>>
>> The topic of build tools and end-to-end development, again... it rests on
>> people reusing outside knowledge.
>> There is very little documentation on producing a deliverable.
>>
>> Were do we want to be in 3 years time?
>> How would we want Elm to have changed the webapp domain?
>> What would be the less than desirable future that we might risk ending up
>> in?
>>
>>
>>
>> On Thu, Nov 24, 2016 at 8:30 AM, Zachary Kessin <zkes...@gmail.com> wrote:
>>>
>>> Glad you liked the blog post.
>>>
>>> I thinkw e are doing well on the intro talks and case studies part of the
>>> Elm story. But there are other stories to tell around elm that might appeal
>>> to the developer who has been doing elm already for 6 months.
>>>
>>>
>>> Zach
>>>
>>> On Thu, Nov 24, 2016 at 8:04 AM, Peter Damoc <pda...@gmail.com> wrote:
>>>>
>>>> I've seen a short blogpost by Zach
>>>> http://get-finch.com/2016/11/23/what_elm_needs_to_to_move_forward.html
>>>> and it got me curious.
>>>>
>>>> What do the rest of you think Elm needs to move forward faster?
>>>> (it is already moving forward and will continue to do so but... maybe
>>>> some things can accelerate the process.)
>>>>
>>>> I've seen also this comment:
>>>>
>>>> https://www.reddit.com/r/elm/comments/5dox3b/reddit_uses_elm_for_internal_apps/da6cyu9/?st=ivvxoob1&sh=4476d8ec
>>>> and I think the point made there is relevant.
>>>>
>>>> I think Elm needs a common story around some kind of web-framework.
>>>>
>>>> With one framework that multiple entities use and improve it is easier
>>>> to build shared ground and shared knowledge and this gives the impression 
>>>> of
>>>> stability and predictability. In theory, it would be easier to find 
>>>> multiple
>>>> developers with the same subset of know-how.
>>>>
>>>> Attempting to implement such a framework would also make salient the
>>>> issues that still remain (CSS) and will stress the tools (elm-format,
>>>> elm-test) enough to push them forward faster.
>>>>
>>>> Constrains liberate.
>>>>
>>>> What do you think?
>>>>
>>>>
>>>> --
>>>> There is NO FATE, we are the creators.
>>>> blog: http://damoc.ro/
>>>>
>>>> --
>>>> 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.
>>>
>>>
>>>
>>>
>>> --
>>> Zach Kessin
>>> SquareTarget
>>> Twitter: @zkessin
>>> Skype: zachkessin
>>>
>>> --
>>> 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.
>>
>>
>>
>>
>> --
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
>> --
>> 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.
>
>
>
>
> --
> Zach Kessin
> SquareTarget
> Twitter: @zkessin
> Skype: zachkessin
>
> --
> 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.

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