[elm-discuss] Elm-discuss admin help?

[Duane Johnson]

I've been away on a Thanksgiving trip this week and have not had time to
approve newcomer posts to this mailing list. There are usually 2-3
newcomers per day, posting for their first time. Would another admin check
to see if there are posts needing approval?

Thanks,
Duane

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

Re: [elm-discuss] What Elm needs to move forward

[Erkal Selman]

@Max: I think Eve does, what you want. I mean uniting events, http 
requests, model access. They are all accessed by "search".
Look at this page: http://docs.witheve.com/handbook/blocks/
(I know very little about Eve. I was just reading this page)


On Thursday, November 24, 2016 at 7:17:27 PM UTC+1, Max Goldstein wrote:
>
> Regarding simple type systems, experiments, and language features for 
> library authors -- finding the right abstraction is hard. In 0.18, there's 
> an HTTP abstraction, so you can run requests in parallel (but not arbitrary 
> effects: racing a file read and a file delete is a bad idea!). Then there's 
> an abstraction for arbitrary effects, Task, which can be chained with 
> andThen. Finally there's Cmd which is more restricted and represents the 
> final unit of work to be done by the runtime. The most sophisticated thing 
> you can do is map over its return value (not the work itself), usually to 
> wrap it so you can identify what happened. But importantly, the preferred 
> way to run an HTTP request is to turn it directly into a Cmd. You can turn 
> it into a Task, and a Task into a Cmd, but that's an escape hatch for 
> experts.
>
> Back to the larger goals: I think it's fair to say that we want to be able 
> to write webapps/SPAs in Elm. That is, we want it to replace Angular, 
> Ember, React+Flux, etc.
>
> Evan has said that he wants to wrap the "web platform", and as a result of 
> that, we have access to most web primitives but not nice framework 
> abstractions. We have virtual DOM but resuable UI components. We have HTTP 
> but no models (like Ember Data or Rails, not the Elm model that holds all 
> your state). That is, Elm is really good at computation and the ability 
> extract functions is incredibly useful. But things stop working when you 
> look at the inputs and outputs of a webapp, and they are primarily HTML and 
> HTTP (also the current time, randomness, and a few others).
>
> So I think what we need is the ability to abstract over HTTP with models, 
> and to abstract over HTML with reusable components. The former seems really 
> hard. The former seems hard only if you need to hold state in your 
> component; maybe we'd have some luck trying to make "components" that are 
> actually just functions?
>

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

[elm-discuss] Decoding childNodes textContent

[Laurence Roberts]

I've become stumped by a json decode issue where the code compiles 
correctly but does not appear to actually run.

If you run this code below, open your console, enter anything in the 
editable element and click out of it. I would expect the message `"Write!"` 
to be logged but it is not. Equally the model is not updated.

Is this an issue with my code or is it a limitation of decoding child 
nodes? The app works fine if refactored to take a model of `type alias 
Model = { contents : String }` instead of a `List String`. As far as I can 
tell the issue seems to lie with attempting to decode `childNodes`. Any 
ideas?

Thanks!

import List exposing (map)
import Html exposing (beginnerProgram)
import Html exposing (Html, article, p)
import Html.Attributes exposing (style, contenteditable, spellcheck)
import Html.Events exposing (on)
import Json.Decode as Decode


main : Program Never Model Message
main =
beginnerProgram { model = model, view = view, update = update }


-- MODEL

type alias Model =
{ contents : List String }

model : Model
model =
{ contents =
[ "Lorem"
, "ipsum"
, "dolor"
]
}


-- UPDATE

type Message =
Write (List String)


update : Message -> Model -> Model
update message model =
case message of
Write contents ->
{ model | contents = Debug.log "Write!" contents }

-- VIEW

view : Model -> Html Message
view model =
article
[ contenteditable True
, spellcheck False
, on "blur" <| Decode.map Write <| childrenContentDecoder
]
(viewContents model.contents)

viewContents : List String -> List (Html a)
viewContents contents =
contents |> map (\content -> p [] [ Html.text content ])


childrenContentDecoder : Decode.Decoder (List String)
childrenContentDecoder =
Decode.at [ "target", "childNodes" ] (Decode.list textContentDecoder)


textContentDecoder : Decode.Decoder String
textContentDecoder =
Decode.field "textContent" Decode.string



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

Re: [elm-discuss] How to structure the code for a PersonSection widget?

[Vlad GURDIGA]

>
> What types of updates are possible?


For every type of person there is a set of fields, so by updates I mean the 
changes to those fields.

Are the sorts of updates allowed with companies & individuals very similar 
> or very different?


I guess they can be considered similar in that they both have a set of 
fields that the user is expected to fill in or change.

How do we transition from having an Individual to having a Company, and 
> vice versa?


Well, there is the “Type person” dropdown, and whatever the user choses, 
the corresponding set of fields — IndividualFields or CompanyFields — id 
displayed.

I will try the model you’re proposing and see what comes out. 8-)

I see that you’re using the term “Action” instead of “Message” — I like 
that, I feel like action better reflects the concept: it’s something that’s 
happening. 8-)

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

Re: [elm-discuss] What Elm needs to move forward

[Max Goldstein]

Regarding simple type systems, experiments, and language features for 
library authors -- finding the right abstraction is hard. In 0.18, there's 
an HTTP abstraction, so you can run requests in parallel (but not arbitrary 
effects: racing a file read and a file delete is a bad idea!). Then there's 
an abstraction for arbitrary effects, Task, which can be chained with 
andThen. Finally there's Cmd which is more restricted and represents the 
final unit of work to be done by the runtime. The most sophisticated thing 
you can do is map over its return value (not the work itself), usually to 
wrap it so you can identify what happened. But importantly, the preferred 
way to run an HTTP request is to turn it directly into a Cmd. You can turn 
it into a Task, and a Task into a Cmd, but that's an escape hatch for 
experts.

Back to the larger goals: I think it's fair to say that we want to be able 
to write webapps/SPAs in Elm. That is, we want it to replace Angular, 
Ember, React+Flux, etc.

Evan has said that he wants to wrap the "web platform", and as a result of 
that, we have access to most web primitives but not nice framework 
abstractions. We have virtual DOM but resuable UI components. We have HTTP 
but no models (like Ember Data or Rails, not the Elm model that holds all 
your state). That is, Elm is really good at computation and the ability 
extract functions is incredibly useful. But things stop working when you 
look at the inputs and outputs of a webapp, and they are primarily HTML and 
HTTP (also the current time, randomness, and a few others).

So I think what we need is the ability to abstract over HTTP with models, 
and to abstract over HTML with reusable components. The former seems really 
hard. The former seems hard only if you need to hold state in your 
component; maybe we'd have some luck trying to make "components" that are 
actually just functions?

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

Re: [elm-discuss] What Elm needs to move forward

[Nick H]

I found out about the 0.18 release and elm-conf EU via Twitter. Also lots
of announcements there about live coding sessions, local meetups, etc.

I can try to echo some of that stuff here if the organizers don't do it,
but I am only on Twitter sporadically. But there is a wealth of community
chatter on there!!

Also, I just sent a request to Elm Weekly  to
post their newsletter here on the mailing list. Because everybody should
know about it!

On Thu, Nov 24, 2016 at 6:42 AM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Thursday, November 24, 2016 at 2:38:07 PM UTC, Rupert Smith wrote:
>>
>> On Thursday, November 24, 2016 at 8:54:33 AM UTC, Zachary Kessin wrote:
>>>
>>> I wish I could go to Elm-conf eu, but right now I don't have the budget
>>> to travel.
>>>
>>
>> Paris 8/9 June 2017 - https://elmeurope.org/ - Is this the Elm-conf EU
>> we are talking about?
>>
>> It says:
>>
>> CFP rules
>> Elm Europe 2017
>>
>> Only english, we'll announce the result of the CFP when it's done (it
>> seems that it'll be december 8th)
>>
>
> I think something Elm needs to help move it forward might be a better
> approach to galvanising the community. I did not hear of this Elm-conf EU
> until now. Perhaps I live in a cave or something, but I searched this
> mailing list and also found no mention of it.
>
> Also, the recent release of Elm 0.18, it was discussed on the elm-dev
> list, but no announcement was made here.
>
> I think we could try and get a few volunteers to act as 'community
> secretaries' or something like that, and get a bit better at making
> community announcements.
>
> Anyway, the EU conference looks possible for me, I shall submit a CFP for
> my work on Elm + Polymer.
>
> --
> 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.

[elm-discuss] Re: Pre-requisites for learning Elm?

[Razi Syed]

It's Elm specific. This class is offered in first year and in first 
semester so there are no pre-requisites. But there obviously feels like 
there are prequisites because I'm totally lost.

On Sunday, October 23, 2016 at 5:56:54 PM UTC-4, OvermindDL1 wrote:
>
> Elm is definitely a front-end language for javascript so it does assume at 
> least a little prior experience, at least with html/css and how they work 
> if not javascript (depending on what you need to do).  The class does not 
> have those pre-requisites first?  Is it Elm specific or just a generic 
> functional language of which you could pick another?
>
>
> On Sunday, October 23, 2016 at 3:22:22 PM UTC-6, Razi Syed wrote:
>>
>> Hi everyone, I've never programmed before and in my first year course 
>> we're doing Elm. The prof expects us to learn Elm on our own, and simply 
>> does examples in class applying what he thinks we should have learned. 
>> Problem is, I'm totally lost. Some people are telling me you're supposed to 
>> know HTML and CSS before Elm. Even the official elm guide seems like it 
>> assumes you know HTML and CSS and javascript (note: I simply know the names 
>> of these languages and nothing about them), or have programmed in a 
>> non-functional programming.
>>
>

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

[elm-discuss] What do I need to know before attempting to learn ELM?

[Razi Syed]

Are there any prerequisites I should know before trying to learn ELM? I've 
never programmed in my life before, and the elm website's tutorial seems to 
assume the reader already has some sort of background in programming since 
I don't understand a lot of terminology. Where do I start?

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

Communication between >1 Elm.Main with effects? (Was Re: [elm-discuss] Can't install native package using elm-github-install)

['Rupert Smith' via Elm Discuss]

On Tuesday, November 22, 2016 at 4:59:22 AM UTC, Gusztáv Szikszai wrote:
>
> I think you are looking for something like this: 
> https://github.com/gdotdesign/elm-ui/blob/master/source/Ui/Helpers/Emitter.elm
>  
> It's a pure Elm pub / sub effects module (and possibly the most minimal 
> example of an effect module).
>

If I used this in 2 Elm applications running at once, by which I mean 2 
Elm.Mains on the same page, would this allow messages to flow between the 2 
applications? Or would there be 2 effect manager instances created, which 
are isolated from each other?

I suppose I should just try it and see what happens.

The reason I ask is because of the Elm + Polymer experiments I did 
previoulsy, where I implemented a Polymer webcomponent in Elm then embedded 
the component in a containing Elm application. I did not find a way so far 
to allow some events from the inner component to be sent to the containing 
application and this could be a way of doing that.

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

[elm-discuss] Re: Structure for multiple small "apps" when using Elm with webpack (elm-webpack-loader)

[Robin Heggelund Hansen]

Define "big blob of js"

React, the framework alone, is around 54kb gzipped, my elm SPA is currently 
half that gzipped. Also, you would load the same blob once, as it's cached 
in your browser.
Currently, if you split your app up into multiple entry points, those would 
still require the Elm runtime, core library, virtual dom and html library.

torsdag 24. november 2016 13.40.12 UTC+1 skrev Rafał Cieślak følgende:
>
> Robin:
>
> I would just keep everything in one Elm app, then use a router to display 
>> the correct page.
>
>
> The problem I see with this is that our app is not SPA, so each page that 
> needs an Elm app would need to load a big blob of JS with dependencies of 
> all the Elm modules in our source code.
>
> When it comes to google closure, Elm only works with SimpleOptimizations.
>
>
> Thanks for the info, I was under the impression that it worked okay with 
> advanced optimizations.
>
> In any case, the difference between Google Closure and Uglify is very 
>> small when it comes to Elm.
>
>
> Yeah, that's why I eventually gave up – the few KBs of reduced size were 
> not worth the time I spent figuring out how to make this all work with 
> Closure Compiler. ;)
>
>
>
> Noah:
>
> So you use a similar setup to what I described, right? I assume that by "a 
> unique Elm app" you mean "a main module" and that all the main modules 
> share a single elm-package.json.
>
> This is ideal in terms of build time and reliabitly, as everything can be 
>> built and once and  share a single lot of packages. 
>
>
> Yeah, definitely. Another advantage for me is what I mentioned earlier: it 
> can be easily plugged in to our existing workflow with webpack.
>

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

Re: [elm-discuss] What Elm needs to move forward

['Rupert Smith' via Elm Discuss]

On Thursday, November 24, 2016 at 2:38:07 PM UTC, Rupert Smith wrote:
>
> On Thursday, November 24, 2016 at 8:54:33 AM UTC, Zachary Kessin wrote:
>>
>> I wish I could go to Elm-conf eu, but right now I don't have the budget 
>> to travel. 
>>
>
> Paris 8/9 June 2017 - https://elmeurope.org/ - Is this the Elm-conf EU we 
> are talking about?
>
> It says:
>
> CFP rules
> Elm Europe 2017
>
> Only english, we'll announce the result of the CFP when it's done (it 
> seems that it'll be december 8th)
>

I think something Elm needs to help move it forward might be a better 
approach to galvanising the community. I did not hear of this Elm-conf EU 
until now. Perhaps I live in a cave or something, but I searched this 
mailing list and also found no mention of it.

Also, the recent release of Elm 0.18, it was discussed on the elm-dev list, 
but no announcement was made here.

I think we could try and get a few volunteers to act as 'community 
secretaries' or something like that, and get a bit better at making 
community announcements.

Anyway, the EU conference looks possible for me, I shall submit a CFP for 
my work on Elm + Polymer.

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

Re: [elm-discuss] What Elm needs to move forward

['Rupert Smith' via Elm Discuss]

On Thursday, November 24, 2016 at 8:54:33 AM UTC, Zachary Kessin wrote:
>
> I wish I could go to Elm-conf eu, but right now I don't have the budget to 
> travel. 
>

Paris 8/9 June 2017 - https://elmeurope.org/ - Is this the Elm-conf EU we 
are talking about?

It says:

CFP rules
Elm Europe 2017

Only english, we'll announce the result of the CFP when it's done (it seems 
that it'll be december 8th)

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

[elm-discuss] Re: Structure for multiple small "apps" when using Elm with webpack (elm-webpack-loader)

[Rafał Cieślak]

Robin:

I would just keep everything in one Elm app, then use a router to display 
> the correct page.


The problem I see with this is that our app is not SPA, so each page that 
needs an Elm app would need to load a big blob of JS with dependencies of 
all the Elm modules in our source code.

When it comes to google closure, Elm only works with SimpleOptimizations.


Thanks for the info, I was under the impression that it worked okay with 
advanced optimizations.

In any case, the difference between Google Closure and Uglify is very small 
> when it comes to Elm.


Yeah, that's why I eventually gave up – the few KBs of reduced size were 
not worth the time I spent figuring out how to make this all work with 
Closure Compiler. ;)



Noah:

So you use a similar setup to what I described, right? I assume that by "a 
unique Elm app" you mean "a main module" and that all the main modules 
share a single elm-package.json.

This is ideal in terms of build time and reliabitly, as everything can be 
> built and once and  share a single lot of packages. 


Yeah, definitely. Another advantage for me is what I mentioned earlier: it 
can be easily plugged in to our existing workflow with webpack.

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

Re: [elm-discuss] What Elm needs to move forward

[Erkal Selman]

Let me quote some text from that post to be more precise about what I mean
when i say "we need examples"

*Why?*

> Examples are lightweight and informal; they can often be made in a few
> minutes; they lack the ceremony of polished graphics or official tools. Yet
> examples are a powerful medium of communication that is capable of
> expressing big ideas with immediate impact.


*How?*

> I use examples so often that I created bl.ocks.org to make it easier for
> me to share them. It lets you quickly post code and share examples with a
> short URL. Your code is displayed below; it’s view source by default. And
> it’s backed by GitHub Gist , so examples have a
> git repository for version control, and are forkable, cloneable and
> commentable.


On Thu, Nov 24, 2016 at 1:35 PM, Erkal Selman  wrote:

> We need examples: https://bost.ocks.org/mike/example/
>
>
>
>
> On Thursday, November 24, 2016 at 12:26:25 PM UTC+1, Zachary Kessin wrote:
>>
>> Some of this makes me a bit twichy. I think one of Elm's great advantages
>> is that while its type system is good it is also simple. Having tried
>> haskell and quickly drowned I am in favor of keeping the types as simple as
>> possible
>>
>> Zach
>>
>>
>> On Thu, Nov 24, 2016 at 1:11 PM, John Orford  wrote:
>>
>>> Totally agree with that also.
>>>
>>> I would love a underscore or lo-dash situation where libraries could be
>>> used as petri dishes for future language features... or just doing cool
>>> stuff : )
>>>
>>> Perhaps, you could add deprecable new features, which could only be
>>> included in experimental packages or something...
>>>
>>> If the libraries or features take make sense, keep them, if not everyone
>>> is aware of that they can be axed...
>>>
>>> On Thu, 24 Nov 2016 at 12:04 Oliver Searle-Barnes 
>>> wrote:
>>>
 Something that I feel isn't acknowledged is that it's ok to have a
 language with more advanced features for library authors than library
 consumers. I don't see that it follows that having more advanced features
 makes the language harder to use for beginners (I'd argue the opposite
 even). I do see your point though that allowing more powerful abstractions
 and maintaining ease of use is perhaps something that more powerful FP
 languages have failed (or not attempted even) to find and careful and
 patient thought is required.


 On Thursday, 24 November 2016 11:45:38 UTC+1, John Orford wrote:

> Oliver,
>
> I understand. But... we are swimming in a sea of imperative
> programmers. A lot of FP is not obviously better for them.
>
> From my POV, this is Elm's greatest strength and weakness.
>
> It would be so easy to be a PureScript and corner a hardcore niche,
> where 'power' is everything.
>
> Elm has a larger goal - to bring FP to the masses.
>
> I am sure abstractions will come in good time, but they will be added
> carefully with a lot of thought.
>
> So... I totally understand, but there's not a lack of 'powerful' FP
> out there, there's a lack of FP for the masses.
>
> This is extremely challenging in all sorts of ways, and an open
> question of whether it's even possible.
>
> But this I believe is what Elm is aiming to do.
>
> Who knows whether it will fail or not. No one really knows. I know
> it's worth a shot though!
>
> John
>
> On Thu, 24 Nov 2016 at 11:34 Oliver Searle-Barnes 
> wrote:
>
 I'm definitely still in the process of moving my thinking into a
>> functional approach (currently working through Programming Haskell and 
>> Bartosz
>> Milewski 's Category Theory
>> series on youtube, both recommended by other Elmers so thanks!). The lack
>> of abstraction in Elm does seem like a major stumbling point at the 
>> moment,
>> the problems I mentioned above are abundantly obvious for anyone that
>> starts to use it (I say this with big love for Elm). I want more people 
>> to
>> be able to enjoy Elm but these issues make it very difficult for 
>> beginners
>> or even mid-level developers to get going quickly.
>>
>>
>> On Thursday, 24 November 2016 11:00:36 UTC+1, Peter Damoc wrote:
>>
>>> On Thu, Nov 24, 2016 at 11:17 AM, Oliver Searle-Barnes <
>>> oli...@opsb.co.uk> wrote:
>>>
 The fact remains though that I don't feel I can offer a sound
 justification as to why it's far more complicated to do these things in
 Elm. Elm strives to be easy for users to understand, in this area it is
 decidedly more complicated than the existing alternatives.

>>>
>>> The class of problems you described is precisely the class of
>>> problems that Object Oriented Programming solves easily.
>>> It is 

Re: [elm-discuss] What Elm needs to move forward

[Zachary Kessin]

Some of this makes me a bit twichy. I think one of Elm's great advantages
is that while its type system is good it is also simple. Having tried
haskell and quickly drowned I am in favor of keeping the types as simple as
possible

Zach


On Thu, Nov 24, 2016 at 1:11 PM, John Orford  wrote:

> Totally agree with that also.
>
> I would love a underscore or lo-dash situation where libraries could be
> used as petri dishes for future language features... or just doing cool
> stuff : )
>
> Perhaps, you could add deprecable new features, which could only be
> included in experimental packages or something...
>
> If the libraries or features take make sense, keep them, if not everyone
> is aware of that they can be axed...
>
> On Thu, 24 Nov 2016 at 12:04 Oliver Searle-Barnes 
> wrote:
>
>> Something that I feel isn't acknowledged is that it's ok to have a
>> language with more advanced features for library authors than library
>> consumers. I don't see that it follows that having more advanced features
>> makes the language harder to use for beginners (I'd argue the opposite
>> even). I do see your point though that allowing more powerful abstractions
>> and maintaining ease of use is perhaps something that more powerful FP
>> languages have failed (or not attempted even) to find and careful and
>> patient thought is required.
>>
>>
>> On Thursday, 24 November 2016 11:45:38 UTC+1, John Orford wrote:
>>
>> Oliver,
>>
>> I understand. But... we are swimming in a sea of imperative programmers.
>> A lot of FP is not obviously better for them.
>>
>> From my POV, this is Elm's greatest strength and weakness.
>>
>> It would be so easy to be a PureScript and corner a hardcore niche, where
>> 'power' is everything.
>>
>> Elm has a larger goal - to bring FP to the masses.
>>
>> I am sure abstractions will come in good time, but they will be added
>> carefully with a lot of thought.
>>
>> So... I totally understand, but there's not a lack of 'powerful' FP out
>> there, there's a lack of FP for the masses.
>>
>> This is extremely challenging in all sorts of ways, and an open question
>> of whether it's even possible.
>>
>> But this I believe is what Elm is aiming to do.
>>
>> Who knows whether it will fail or not. No one really knows. I know it's
>> worth a shot though!
>>
>> John
>>
>> On Thu, 24 Nov 2016 at 11:34 Oliver Searle-Barnes 
>> wrote:
>>
>> I'm definitely still in the process of moving my thinking into a
>> functional approach (currently working through Programming Haskell and 
>> Bartosz
>> Milewski 's Category Theory
>> series on youtube, both recommended by other Elmers so thanks!). The lack
>> of abstraction in Elm does seem like a major stumbling point at the moment,
>> the problems I mentioned above are abundantly obvious for anyone that
>> starts to use it (I say this with big love for Elm). I want more people to
>> be able to enjoy Elm but these issues make it very difficult for beginners
>> or even mid-level developers to get going quickly.
>>
>>
>> On Thursday, 24 November 2016 11:00:36 UTC+1, Peter Damoc wrote:
>>
>> On Thu, Nov 24, 2016 at 11:17 AM, Oliver Searle-Barnes > > wrote:
>>
>> The fact remains though that I don't feel I can offer a sound
>> justification as to why it's far more complicated to do these things in
>> Elm. Elm strives to be easy for users to understand, in this area it is
>> decidedly more complicated than the existing alternatives.
>>
>>
>> The class of problems you described is precisely the class of problems
>> that Object Oriented Programming solves easily.
>> It is the class of problems where, as a library developer, you provide
>> and API and you allow the client to do multiple implementation of an
>> interface, (e.g. the interface of a web-component or the interface of a
>> debounceable app).
>>
>> Implementing something that solves this issue is non-trivial because it
>> can be a source of chaos (complexity).
>> Approaching the Expression Problem
>>  Elm chose defer
>> solving it for later implementing only a few practical facilities like
>> toString (allows extension of cases without recompilation)
>>
>>
>>
>> --
>> 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...@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.
>>
> --
> You received 

Re: [elm-discuss] What Elm needs to move forward

[Oliver Searle-Barnes]

Something that I feel isn't acknowledged is that it's ok to have a language 
with more advanced features for library authors than library consumers. I 
don't see that it follows that having more advanced features makes the 
language harder to use for beginners (I'd argue the opposite even). I do 
see your point though that allowing more powerful abstractions and 
maintaining ease of use is perhaps something that more powerful FP 
languages have failed (or not attempted even) to find and careful and 
patient thought is required. 


On Thursday, 24 November 2016 11:45:38 UTC+1, John Orford wrote:
>
> Oliver,
>
> I understand. But... we are swimming in a sea of imperative programmers. A 
> lot of FP is not obviously better for them.
>
> From my POV, this is Elm's greatest strength and weakness.
>
> It would be so easy to be a PureScript and corner a hardcore niche, where 
> 'power' is everything.
>
> Elm has a larger goal - to bring FP to the masses. 
>
> I am sure abstractions will come in good time, but they will be added 
> carefully with a lot of thought.
>
> So... I totally understand, but there's not a lack of 'powerful' FP out 
> there, there's a lack of FP for the masses.
>
> This is extremely challenging in all sorts of ways, and an open question 
> of whether it's even possible.
>
> But this I believe is what Elm is aiming to do.
>
> Who knows whether it will fail or not. No one really knows. I know it's 
> worth a shot though!
>
> John
>
> On Thu, 24 Nov 2016 at 11:34 Oliver Searle-Barnes  > wrote:
>
>> I'm definitely still in the process of moving my thinking into a 
>> functional approach (currently working through Programming Haskell and 
>> Bartosz 
>> Milewski 's Category Theory 
>> series on youtube, both recommended by other Elmers so thanks!). The lack 
>> of abstraction in Elm does seem like a major stumbling point at the moment, 
>> the problems I mentioned above are abundantly obvious for anyone that 
>> starts to use it (I say this with big love for Elm). I want more people to 
>> be able to enjoy Elm but these issues make it very difficult for beginners 
>> or even mid-level developers to get going quickly. 
>>
>>
>> On Thursday, 24 November 2016 11:00:36 UTC+1, Peter Damoc wrote:
>>
>>> On Thu, Nov 24, 2016 at 11:17 AM, Oliver Searle-Barnes <
>>> oli...@opsb.co.uk> wrote:
>>>
 The fact remains though that I don't feel I can offer a sound 
 justification as to why it's far more complicated to do these things in 
 Elm. Elm strives to be easy for users to understand, in this area it is 
 decidedly more complicated than the existing alternatives.

>>>
>>> The class of problems you described is precisely the class of problems 
>>> that Object Oriented Programming solves easily. 
>>> It is the class of problems where, as a library developer, you provide 
>>> and API and you allow the client to do multiple implementation of an 
>>> interface, (e.g. the interface of a web-component or the interface of a 
>>> debounceable app). 
>>>
>>> Implementing something that solves this issue is non-trivial because it 
>>> can be a source of chaos (complexity).  
>>> Approaching the Expression Problem 
>>>  Elm chose defer 
>>> solving it for later implementing only a few practical facilities like 
>>> toString (allows extension of cases without recompilation) 
>>>
>>>
>>>
>>> -- 
>>> 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...@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.

Re: [elm-discuss] What Elm needs to move forward

[John Orford]

Oliver,

I understand. But... we are swimming in a sea of imperative programmers. A
lot of FP is not obviously better for them.

>From my POV, this is Elm's greatest strength and weakness.

It would be so easy to be a PureScript and corner a hardcore niche, where
'power' is everything.

Elm has a larger goal - to bring FP to the masses.

I am sure abstractions will come in good time, but they will be added
carefully with a lot of thought.

So... I totally understand, but there's not a lack of 'powerful' FP out
there, there's a lack of FP for the masses.

This is extremely challenging in all sorts of ways, and an open question of
whether it's even possible.

But this I believe is what Elm is aiming to do.

Who knows whether it will fail or not. No one really knows. I know it's
worth a shot though!

John

On Thu, 24 Nov 2016 at 11:34 Oliver Searle-Barnes  wrote:

> I'm definitely still in the process of moving my thinking into a
> functional approach (currently working through Programming Haskell and Bartosz
> Milewski 's Category Theory
> series on youtube, both recommended by other Elmers so thanks!). The lack
> of abstraction in Elm does seem like a major stumbling point at the moment,
> the problems I mentioned above are abundantly obvious for anyone that
> starts to use it (I say this with big love for Elm). I want more people to
> be able to enjoy Elm but these issues make it very difficult for beginners
> or even mid-level developers to get going quickly.
>
>
> On Thursday, 24 November 2016 11:00:36 UTC+1, Peter Damoc wrote:
>
> On Thu, Nov 24, 2016 at 11:17 AM, Oliver Searle-Barnes 
> wrote:
>
> The fact remains though that I don't feel I can offer a sound
> justification as to why it's far more complicated to do these things in
> Elm. Elm strives to be easy for users to understand, in this area it is
> decidedly more complicated than the existing alternatives.
>
>
> The class of problems you described is precisely the class of problems
> that Object Oriented Programming solves easily.
> It is the class of problems where, as a library developer, you provide and
> API and you allow the client to do multiple implementation of an interface,
> (e.g. the interface of a web-component or the interface of a debounceable
> app).
>
> Implementing something that solves this issue is non-trivial because it
> can be a source of chaos (complexity).
> Approaching the Expression Problem
>  Elm chose defer
> solving it for later implementing only a few practical facilities like
> toString (allows extension of cases without recompilation)
>
>
>
> --
> 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.
>

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

Re: [elm-discuss] What Elm needs to move forward

[Wouter In t Velt]

My learning curve has been similar to what Oliver describes.

IMHO, there still a large gap between The Official Guide and the community 
platforms, that needs to be filled. 
The Official Guide is a great doc, but it has very few examples, and mostly 
entry-level and small. 
Outside the guide, the mailing list and slack channels are great for 
instant Q and small code snippets.
Beyond that, it is a world of “anyone can share anything anywhere”. 

Don’t get me wrong, there is very good elm-stuff out there, and I am very 
grateful for the effort that the community puts in examples, blogs, confs 
etcetera.
I just wish there were a sharing platform in-between.

For libraries, the processes and publication around packages are very 
useful.
But not everything is a library.

It would be useful if there was some sort of “community endorsed” examples 
archive, with some vetting process (maybe voting).
These could be small (like a dropdown, sortable table, drag-and-drop 
reorder list, sidebar, port to do Firebase authentication and database 
connections etc etc), or larger, like a SPA.
With not just code, but also written in a Guide-like way.

I lack the skills to set up something like that, but would be more than 
happy to contribute with code examples and descriptions.

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

Re: [elm-discuss] What Elm needs to move forward

[Oliver Searle-Barnes]

I'm definitely still in the process of moving my thinking into a functional 
approach (currently working through Programming Haskell and Bartosz Milewski 
's Category Theory series on 
youtube, both recommended by other Elmers so thanks!). The lack of 
abstraction in Elm does seem like a major stumbling point at the moment, 
the problems I mentioned above are abundantly obvious for anyone that 
starts to use it (I say this with big love for Elm). I want more people to 
be able to enjoy Elm but these issues make it very difficult for beginners 
or even mid-level developers to get going quickly. 


On Thursday, 24 November 2016 11:00:36 UTC+1, Peter Damoc wrote:
>
> On Thu, Nov 24, 2016 at 11:17 AM, Oliver Searle-Barnes  > wrote:
>
>> The fact remains though that I don't feel I can offer a sound 
>> justification as to why it's far more complicated to do these things in 
>> Elm. Elm strives to be easy for users to understand, in this area it is 
>> decidedly more complicated than the existing alternatives.
>>
>
> The class of problems you described is precisely the class of problems 
> that Object Oriented Programming solves easily. 
> It is the class of problems where, as a library developer, you provide and 
> API and you allow the client to do multiple implementation of an interface, 
> (e.g. the interface of a web-component or the interface of a debounceable 
> app). 
>
> Implementing something that solves this issue is non-trivial because it 
> can be a source of chaos (complexity).  
> Approaching the Expression Problem 
>  Elm chose defer 
> solving it for later implementing only a few practical facilities like 
> toString (allows extension of cases without recompilation) 
>
>
>
> -- 
> 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.

Re: [elm-discuss] What Elm needs to move forward

[Peter Damoc]

On Thu, Nov 24, 2016 at 11:17 AM, Oliver Searle-Barnes 
wrote:

> The fact remains though that I don't feel I can offer a sound
> justification as to why it's far more complicated to do these things in
> Elm. Elm strives to be easy for users to understand, in this area it is
> decidedly more complicated than the existing alternatives.
>

The class of problems you described is precisely the class of problems that
Object Oriented Programming solves easily.
It is the class of problems where, as a library developer, you provide and
API and you allow the client to do multiple implementation of an interface,
(e.g. the interface of a web-component or the interface of a debounceable
app).

Implementing something that solves this issue is non-trivial because it can
be a source of chaos (complexity).
Approaching the Expression Problem
 Elm chose defer solving
it for later implementing only a few practical facilities like toString
(allows extension of cases without recompilation)



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

Re: [elm-discuss] What do people thing about the idea of Elm Remote Conf

[Zachary Kessin]

I forgot about those :)



Zach

On Thu, Nov 24, 2016 at 11:18 AM, Peter Damoc  wrote:

> How would this be different from the current Elm Remote Meetups?
>
>
> On Thu, Nov 24, 2016 at 10:56 AM, Zachary Kessin 
> wrote:
>
>> I know Charles Max Wood of Ruby Rouges (and other podcasts) has been
>> doing a lot of remote conferences. I was thinking we should approach him to
>> do Elm Remote Conf. Would others be interested?
>>
>> What kind of content would you like to see. I would have 2 goals
>>
>> 1) Get speakers who have never given a conference talk before
>> 2) Get more advanced talk
>>
>> Obviously not every talk would have to check both boxes.
>>
>> --
>> 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.

Re: [elm-discuss] What Elm needs to move forward

[Oliver Searle-Barnes]

I'm going to touch on a couple of sensitive areas here, hopefully you'll 
take my comments in the manner they're intended, to try and expose problems 
that newcomers from other frameworks face so that we can think about how we 
might improve the situation.

I've been using Elm a good portion of the working week for about 3 months 
now, I'm still very much missing a solution for components (to be clear I'm 
talking about an equivalent to WebComponents). Every framework that 
developers come from has a solution for this, with a huge number of 
components available that you can just drop into your app. At the moment 
it's a brick wall that you hit with no real answers. I'm not going to dig 
into the details of the topic here (I have my own workarounds which are 
working in a not ideal way), but it manifests in a few ways. 

1) The only selection of ready to go components available is elm-mdl and it 
requires a technique which is at odds with the recommended architecture.  

2) The level of interest in WebComponents - seems viable but is a long way 
from being a recommended route and is unclear if it would ever be accepted 
as a first class part of the Elm experience.

3) The amount of boilerplate required to integrate a package, 
e.g. http://package.elm-lang.org/packages/jinjor/elm-debounce/latest vs for 
instance https://github.com/nkbt/react-debounce-input 
or https://github.com/offirgolan/ember-debounced-input-helpers.

I'm familiar with all of the arguments and have applied various techniques 
in my own app and have workable solutions. The fact remains though that I 
don't feel I can offer a sound justification as to why it's far more 
complicated to do these things in Elm. Elm strives to be easy for users to 
understand, in this area it is decidedly more complicated than the existing 
alternatives. I personally believe a good experience for beginners requires 
library authors having access to more abstraction (whether it be via type 
classes or whatever), as shown by the debouncer example we currently force 
library consumers to do more work than they'd be used to in other 
environments. 

Elm is fantastically easy to learn, but currently it does seem to come at 
the cost of being hard to use to build SPAs (the learning curve between 
learning the language and knowing how to build a complex app is not only 
steep but also undefined). Can we improve the experience of building SPAs 
without sacrificing how easy it is to learn Elm? 




On Thursday, 24 November 2016 09:41:22 UTC+1, Noah Hall wrote:
>
> 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  > 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  > 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 

Re: [elm-discuss] What Elm needs to move forward

[Peter Damoc]

On Thu, Nov 24, 2016 at 11:01 AM, John Orford  wrote:

> On the perennial CSS-in-Elm topic - I think Elm's lack in this regard
> reflects a general lack of being able to do CSS in an elegant manner
> (correct me if I am wrong).
>
> I am pretty sure if there was a clear way to do CSS right generally, Elm
> would've jumped on that band wagon.
>
> Having said all that, I'd love to hear suggestions on how best to do CSS,
> in an Elm context or not...
>

CSS is part of a theory about how to do documents.
It predicates a split between what is content and what is presentation of
said content.
This is all fine in a typical document like web page. In a webapp things
might need to be reconsidered.

I'm not a CSS guru but from the outside of industry it looks like there are
two main concerns: layout and visuals.
My guess is that more than 80% of the trouble of CSS are generated by
troubles in the layout domain so... that would be a low hanging fruit.

A clear split between layout and visuals (skeleton and surface) could allow
the the creation of a layout library that does just that: layout but in a
very considerate and intelligent way.

A second concern regarding CSS is at a higher level of abstraction and
relates to encapsulation of layout and styling information together with
behavior.
This is the realm of what one can see in Polymer where components
encapsulate everything.
To give you a more visual example, imagine some kind of ripple button that
can be used instead of Html.button and does not require mounting of outside
CSS or declaring some class and style attributes.
It can be done with webcomponents/polymer by going outside of Elm but it is
cumbersome.



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

Re: [elm-discuss] What Elm needs to move forward

[Peter Damoc]

On Thu, Nov 24, 2016 at 10:54 AM, Zachary Kessin  wrote:

> What topics should we cover?
>

That's like putting the cart before the horses.
We need first to develop a coherent vision to where do we want to take Elm.

I'll reuse a map from a book that I'm reading now:
[image: Inline image 1]

We need to better understand what should be and then venture into the
unknown and unpredictable in order to search for the means to get to What
should be.
Without this "What should be" we are likely to miss the big picture and
focus on small details.




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

Re: [elm-discuss] What Elm needs to move forward

[John Orford]

On the perennial CSS-in-Elm topic - I think Elm's lack in this regard
reflects a general lack of being able to do CSS in an elegant manner
(correct me if I am wrong).

I am pretty sure if there was a clear way to do CSS right generally, Elm
would've jumped on that band wagon.

Having said all that, I'd love to hear suggestions on how best to do CSS,
in an Elm context or not...

Perhaps I need to be educated : )

On Thu, 24 Nov 2016 at 09:56 Matija Srček  wrote:

> I'm having fun learning programming as a hobby and Elm is the most
> beautiful, friendly, clean and focused language that I've tried, including
> JS frameworks. I see it as a great solution for building logic and
> structure (HTML) of an app. It's true, styling (CSS) is almost completely
> absent. Elm definitely needs it's core CSS library or some official
> approach for building UI elements that is clean and optimized. For example,
> HTML library is awesome, It's easy to transition from writing regular HTML
> to writing one using Elm syntax. It would be great to have something like
> that on the styling side.
>
>
> On Thursday, November 24, 2016 at 8:31:22 AM UTC+1, Peter Damoc 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  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  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=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...@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...@googlegroups.com.
>
>
> For more options, visit 

Re: [elm-discuss] What Elm needs to move forward

[Matija Srček]

I'm having fun learning programming as a hobby and Elm is the most 
beautiful, friendly, clean and focused language that I've tried, including 
JS frameworks. I see it as a great solution for building logic and 
structure (HTML) of an app. It's true, styling (CSS) is almost completely 
absent. Elm definitely needs it's core CSS library or some official 
approach for building UI elements that is clean and optimized. For example, 
HTML library is awesome, It's easy to transition from writing regular HTML 
to writing one using Elm syntax. It would be great to have something like 
that on the styling side.

On Thursday, November 24, 2016 at 8:31:22 AM UTC+1, Peter Damoc 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  > 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 > > 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=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...@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...@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 

Re: [elm-discuss] What Elm needs to move forward

[Noah Hall]

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