[elm-discuss] Using Elm with existing UI controls

[Joe Andaverde]

Statement: Elm is difficult to adopt for some groups because they require 
UI controls that may be difficult or time-prohibitive to re-implement.

Current Approach: Use ports to initialize controls by passing the id of a 
DOM element to use as the container.

Problem: Using ports to wire UI controls can cause memory leaks because 
there's no indication when a DOM element has been removed. When these DOM 
elements disappear there's no way to clean up event handlers or other GC 
roots.

Due Diligence: I've put together an example of one type of memory leak 
that's possible using a jQuery Date picker control:

https://github.com/joeandaverde/elm-jquery-memory-leak

The README contains a short gif of the memory leak in action.

Solutions to being notified when a DOM element is created or removed have 
been proposed in various (closed) issues in virtual-dom and this list. I 
understand these lifecycle hooks have been acknowledged as a useful tool. I 
propose that these lifecycle hooks are more than a convenience and instead 
required in order to prevent memory leaks and aid adoption of Elm.


-- 
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] I wish ELM could just be used in the browser

[Wyatt Benno]

Thanks all! I still do not see why ELM can never be compiled directly in the 
browser. A V8 engine compiler for ELM?
After all it becomes JavaScript right?

Elm's benefits are derived from the functional paradigm (no runtime errors, 
static types, optimized speed, etc.). 
They are trying to make JavaScript more functional, and if used in this way 
there are little differences with the benefits of Elm other than developer 
preference and ease of learning; However since JavaScript runs in the browser 
it will always be more accessible to most people. 

1) What if I want a header done in Elm, and then a footer with different 
function done in Elm but with a standard HTML center. If I compiled two elm 
files and connected them to the header and footer they would both contain 
overlapping dependencies.

2) HTML in ELM looks like div[][div[class "this"][text "does not read well"]]. 
This would not make sense to most team members "designers", anyone who does not 
no ELM. This would mean that developers would need to manually change any HTML 
portion that needs to be in ELM. I could not argue on the point that JSX is 
easier to work with for most people because it looks like plain old HTML.

3) When there is an update we would need to go through the entire project and 
fix everything for the new version of Elm.
I wonder how NoRedInc deals with this.

I want to use ELM more in production, it is just really hard to make the case 
for it right now. Evan seems busy with a few specific issues at one time, so I 
expect progress will be slow. Dropping FRP was a great start to accessibility!

Very good hobby language, I hope I can use it in production soon.

-- 
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] Generating reports for printing

[Duane Johnson]

Hi Rory, forgive me if you've already been down this path, but wouldn't CSS
be the right place to apply page breaks for printable documents / reports?
For instance: https://css-tricks.com/almanac/properties/p/page-break/

Are you trying to generate PDFs specifically, or just create reports that
can be printed via the browser?

Duane

On Thu, Jan 26, 2017 at 9:02 AM, Rory  wrote:

> I'm just starting out with developing and Elm.
>
> If I generate a long list and wanted to export to PDF I believe I would
> first need a way to 'break' at a specific page length.
>
> Will exporting to PDF break the individual list items at the proper time?
> Is there a package to export to PDF or to print?
>
> Thanks in advance,
>
> Rory
>
> --
> 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] Generating reports for printing

[Rory]

I'm just starting out with developing and Elm.

If I generate a long list and wanted to export to PDF I believe I would 
first need a way to 'break' at a specific page length.

Will exporting to PDF break the individual list items at the proper time? 
Is there a package to export to PDF or to print?

Thanks in advance,

Rory

-- 
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] Composing Things in Elm

[Jigar Gosar]

Thanks a lot!

It is in examples like this that a functional noob like me learns about how 
to exploit the functional goodness. And start programming on next level of 
abstraction. I am very keen on learning tools/patterns for creating higher 
levels of abstractions. I hate to repeat myself over and over. Removing 
duplicate code is not enough; there are patterns of functions/modules which 
are also repeated over. It is hard to spot them and even harder to find a 
decent abstraction. Add to it lack of background in functional programming.

I am aware that this approach is prone to premature 
abstraction/optimization. But regardless I would like to carry it out in my 
spare time to learn from it. 

Once again, Thanks a lot!

On Wednesday, 25 January 2017 21:22:13 UTC+5:30, Peter Damoc wrote:
>
>
> On Wed, Jan 25, 2017 at 8:17 AM, Maksim Demin  > wrote:
>
>> Thanks for the response, it totally works, and I definitely think it is 
>> cleaner than having to Html.map everything! I am still trying to fully 
>> understand what is going on, pretty new to Elm. I kinda get what you are 
>> doing in the update to map the command, 
>>
>> ( { model | field2 = "2" }, Cmd.map cfg.lift pageTwoCmd ) 
>>
>> but how does that happen in the view? How does this cfg.lift which 
>> is lift : Page1Msg -> msg work here?
>>
>> div [ onClick (cfg.lift <| DoSomething1) ] [ text model.field2 ]
>>
>
> Sorry about that, my bad. It should have been 
>
> div [ onClick (cfg.lift DoSomething1) ] [ text model.field2 ]
>  
> basically, the view receives a function that knows how to lift the 
> messages of the SubModule to the message of the parent. If you have type 
> defined as 
>
> type Msg
> = Msg1 Page1Msg
>
> Msg1 is also a value constructor, in other words, a function that takes a 
> Page1Msg and outputs a Msg. This is why you can use it as cfg.lift 
>
>
> Now, the reason my code looked like that was because it started as: 
>
>  div [ onClick (cfg.lift << DoSomething1) ] [ text model.field2 ]
>
> and when I saw that not working, my mind produced the version with the <| 
> (my mind is weird sometimes) 
>
> You need << (function composition) when the event handler receives a 
> function. 
> So, if you have a submodule message like `type Msg = UpdateNameField 
> String` and in the view you have an input event, it would look like 
>
> input [onInput (cfg.lift << UpdateNameField)] [] 
>
> if cfg.lift is *f* and UpdateNameField is *g*, then (cfg.lift << 
> UpdateNameField) is *h* so that h(a) = f(g(a)) 
>
> I remember being new to Elm and finding function application (*<|* and* 
> |>* ) and function composition ( *<<* and *>>*) mystifying. 
> After seeing few more examples and reading through these functions 
> documentation 
>  
> my mind clicked and now I love them. 
> They can make the code very very readable. 
>
>
>
>
> -- 
> 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.

[elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[GordonBGood]

On Tuesday, 24 January 2017 21:42:54 UTC+7, Kennet Postigo wrote:

Re: If performance, efficient output, and functional programming in the 
browser is what you are looking for OCaml + Bucklescript or ReasonML+ 
Bucklescript would be a solid fit!

If you read through the thread, you'll see that I did try BuckleScript with 
the view to using it to augment the Elm Architecture as a Web Application 
Framework.

Some of the things I found are the following:

   1. The compiler speed is exemplary and likely higher than anything else 
   available due to its OCaml heritage.
   2. The JS generated can be very high performance and the BuckleScript 
   add-on back end adds tools to be able to efficiently talk to JavaScript or 
   even directly emit JavaScript code without too much trouble.
   3. One can use all of the functional programming paradigms that OCaml 
   provides.

Unfortunately (for my use), I found that high output JS code performance 
and functional paradigms weren't always possible at the same time across 
the range of mainstream browsers using BuckleScript, as follows:

   1. Closures (functions that capture free mutable variables from outside 
   the scope of the function) are implemented as required by JS by a function 
   returning a function, but in some browsers (current Chrome V8 based), 
   building these internal returned functions is 50 to a 100 times slower than 
   calling a regular function.  As with any of these transpilers, this isn't a 
   serious problem as for any of them one can easily lift or manually create 
   closures outside tight inner loops that generally makes this of no 
   significance in most real code.  It will likely get fixed in future 
   versions of BuckleScript by more extensive mutability analysis so as this 
   type of closure is only created when necessary (when the binding could 
   mutate before the execution of the closure function) and their creation 
   optimized so as to be created where the cost of creating will have the 
   least cost (outside inner loops).
   2. I found that the implementation of functional programming currying 
   seems to be slow on some browsers (primarily in current Firefox) and the 
   workarounds I found are ugly:  I found that if one wants to write code that 
   consistently runs fast across all current browsers, one either has to add 
   extensive annotations to tell BuckleScript to emit JS without currying for 
   tight inner loop calls or one has to write their code in ugly imperative 
   style (without function calls) in tight inner loops if such tight inner 
   loops take a significant portion of the execution time.

Thus, I have chosen to try to stick with Elm for the following reasons:

   1. Elm is a complete Web Application solution, providing both a 
   Framework and a simple, concise, and consistent functional language that is 
   well integrated with that Framework and with that Framework becoming 
   recognizes as one of the best in the industry.  To be a complete 
   replacement for Elm, BuckleScriipt would need to have a Framework 
   library/modules added.
   2. It turns out that my main issue with Elm language performance is 
   primarily in just one simple area as well described in the opening few 
   posts of this thread.  This is exactly the area which is fixed by using 
   BuckleScript, but the costs of using it almost outweigh the benefits as per 
   the above set of points.
   3. My other speed issues with the Elm system are non-mainstream 
   library/module issues, and they can easily be fixed by contributing to the 
   libraries involved or contributing/using my own.

In conclusion, I know that JS code output by Elm for the very tight math 
type loops I require will likely never be as fast as hand written and tuned 
JS, but I have confidence that it will get better as future developments 
improve Elm.  By better, for most users this will be an increase of about 
30% for some types of algorithm, which for my generally tighter loops than 
most people require, may translate into about a 300% to 500% increase  in 
tight loop speed for my use;  Meanwhile, I can easily either hand patch 
critical tight loops (or automate the process of patching) or put such 
critical tight loops into Native JS modules written in whatever language 
produces the best output JS code, whether it be TypeScript, BuckleScript, 
Nim, or even JS itself, as these tight loops are generally quite small.

I've learned what I wanted to find out about Elm speed in this thread to 
date, and will now only report progress in contributing to further gains in 
Elm speed.

-- 
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] I wish ELM could just be used in the browser

[Joey Eremondi]

Also: if you don't have a separate compiler, what's the point of static
types?

On Sat, Jan 28, 2017 at 10:38 AM, Peter Damoc  wrote:

> Elm was designed to help with reliability and maintainability of large
> scale apps.
>
> If it is a toy app or if reliability and maintainability are not important
> enough, other technologies are more appropriate.
>
> It depends on what you want to optimize on.
>
> If however reliability and maintainability are important, the time it
> takes to learn Elm will be payed back manyfold as the app grows.
>
>
>
>
> On Sat, Jan 28, 2017 at 4:53 PM, Wyatt Benno  wrote:
>
>> I love ELM to work with, but it is too bad it cannot be more direct. I
>> had a project come up where ELM could have been used in production but
>> React won because it is just js, browser read, and very easy for anyone to
>> start. Import React start using it anywhere with or without ports. i wish I
>> could import elm in the same way. Any plans for this?
>>
>> --
>> 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.
>

-- 
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] I wish ELM could just be used in the browser

[Peter Damoc]

Elm was designed to help with reliability and maintainability of large
scale apps.

If it is a toy app or if reliability and maintainability are not important
enough, other technologies are more appropriate.

It depends on what you want to optimize on.

If however reliability and maintainability are important, the time it takes
to learn Elm will be payed back manyfold as the app grows.




On Sat, Jan 28, 2017 at 4:53 PM, Wyatt Benno  wrote:

> I love ELM to work with, but it is too bad it cannot be more direct. I had
> a project come up where ELM could have been used in production but React
> won because it is just js, browser read, and very easy for anyone to start.
> Import React start using it anywhere with or without ports. i wish I could
> import elm in the same way. Any plans for this?
>
> --
> 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.

[elm-discuss] Re: I wish ELM could just be used in the browser

[Rex van der Spuy]

I am totally wrong, but my opinion is that Elm is being designed to be a 
long-term replacement for entire HTML/CSS/JS stack - also lovingly known as 
the Hairball-Of-Hell, (or, just Hoh!)
There are a gazillion JS libraries for doing JS things in a 
nicer-than-average JS way (React, Redux, Ember, Angular, Vue, etc, etc, 
etc, etc,)
If you like that kind of thing - go ahead and use them, nothing is stopping 
you!

But Elm is not trying to compete with those - instead it's founded an 
entire New World - a new Planet - built on completely new foundations.
It's for those of use who have discovered that developing with the 
Hairball-of-Hell is possibly the worst form of punishment ever devised by 
those Old World mavens of medieval torture.
We're trying to turn the page on all that and build a beautiful fresh new 
future for a whole new generation of developers to build on.
If that means ports and JSON decoders - I can live with that :)
 





On Saturday, January 28, 2017 at 9:53:02 AM UTC-5, Wyatt Benno wrote:
>
> I love ELM to work with, but it is too bad it cannot be more direct. I had 
> a project come up where ELM could have been used in production but React 
> won because it is just js, browser read, and very easy for anyone to start. 
> Import React start using it anywhere with or without ports. i wish I could 
> import elm in the same way. Any plans for this?

-- 
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] I wish ELM could just be used in the browser

[Wyatt Benno]

I love ELM to work with, but it is too bad it cannot be more direct. I had a 
project come up where ELM could have been used in production but React won 
because it is just js, browser read, and very easy for anyone to start. Import 
React start using it anywhere with or without ports. i wish I could import elm 
in the same way. Any plans for this?

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