[elm-discuss] Super-unimportant request for Google Closure Compiler.js compatibility

This is a super-low-priority request: could the Elm compiler emit the following line at the end of its JS output: window['Elm'] = Elm; I’m used to using Google Closure Compiler after Clojure so I tried it with my tiny ~400 LOC Elm app, and without this line above, the `Elm` object gets renamed

Re: [elm-discuss] Build iOS apps with Elm

(Note from list admin: Rudolf, I didn't approve your second message because it seemed like a duplicate attempt. We've had problems with spam in the past, so first-time posts require moderator approval. Your future posts will not need moderation.) On Wed, Jan 25, 2017 at 4:13 PM, Rudolf Adamkovič

[elm-discuss] Build iOS apps with Elm

In case anyone is interested, I set aside 2 days and created a small framework that allow to build iOS apps with Elm: https://github.com/salutis/swift-elm It can drive both 100% native and web UI. One can also mix and match the two. P.S. It's very early and there're no unit tests yet. -- Yo

[elm-discuss] Re: Html.Attributes.none

The following fits in good enough for me. ... filterDiv : List (Maybe (H.Attribute msg)) -> List (Maybe (H.Html msg)) -> H.Html msg filterDiv a n = H.div (List.filterMap identity a) (List.filterMap identity n) ... measurements : Maybe (Int, Int) ... isNotClicked: Bool ... let style

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

Not really, closure has very very advanced optimizations that uglify does not even come close . If you feed bad code to it , of course it won't help too much. There are limitations to closure and its limitations are documented unclearly, so you have to be very careful On Wed, Jan 25, 2017 at 8:09 P

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

Uglify essentially removes functions that are not added to objects (how you export functions from "namespaces"). Since Elm adds all functions to a single local-scope, and then only exports ports and the main function, it's very easy for uglify to see what functions are unused, and can therefore

Re: [elm-discuss] Re: Emphasizing /r/elm more

On Monday, January 23, 2017 at 9:45:56 PM UTC-5, Richard Feldman wrote: > > Worth noting that the top thread on elm-discuss for several weeks > > > has been largely about languages other than Elm, and the Elm-specif

[elm-discuss] Re: Audio Library?

You could just use an element for simple playback, but if you want anything more sophisticated you'll probably have to use ports to access a JS library, like this one: https://github.com/kittykatattack/sound.js -- You received this message because you are subscribed to the Google Groups "Elm

Re: [elm-discuss] Re: What do you think about Types/State/View split?

On Wednesday, January 25, 2017 at 3:25:56 PM UTC, Alex Barry wrote: > > we tried to stick to generally Module.View, Module.Update, and > Module.Model. We had a few instances where we had to break out sub-update > messages (ie the union type typically used in Module.Update) because we had > messa

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

Note, we are working on es6 modules for BuckleScript, which means you don't need google closure compiler for tree shaking, it will benefit webpack/rollup/browserify users too! On Wed, Jan 25, 2017 at 10:56 AM, OvermindDL1 wrote: > I use browserify for some code via brunch, rollup for others, I r

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

I use browserify for some code via brunch, rollup for others, I run both of those through uglify + closure when building a 'prod' release. browserify and rollup and both blazing fast in compile time with very large bases of code, but rollup prunes based on functions called (meaning it can break

Re: [elm-discuss] Composing Things in Elm

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

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

On Wednesday, 25 January 2017 22:25:39 UTC+7, OvermindDL1 wrote: > > Sent too soon. > > Also, uglify is a minimizer, it does a *lot* more than tree shaking. > > > On Wednesday, January 25, 2017 at 8:25:10 AM UTC-7, OvermindDL1 wrote: >> >> Tree Shaking as implemented by Brunch and Webpack default

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

On Wednesday, 25 January 2017 19:25:40 UTC+7, Bob Zhang wrote: > > elm is a reasonably fast language, I think it might run even faster than > purescript, enjoy your work! Yes, Elm is reasonably fast for some programs such as the functional primes generator but is inconsistent and not very fast

Re: [elm-discuss] Composing Things in Elm

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" }, Cm

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

Sent too soon. Also, uglify is a minimizer, it does a *lot* more than tree shaking. On Wednesday, January 25, 2017 at 8:25:10 AM UTC-7, OvermindDL1 wrote: > > Tree Shaking as implemented by Brunch and Webpack default setups at least > only prune based on if a module is accessed or not (which is

Re: [elm-discuss] Re: What do you think about Types/State/View split?

Just to pipe in with my experience, I'm working on a medium sized project with a lot of inter-related data between my modules, which is dictated by a database structure. We started the project as a single file elm project, but the code was starting to get unmanageable, so we broke it out into modul

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

Tree Shaking as implemented by Brunch and Webpack default setups at least only prune based on if a module is accessed or not (which is also why it is easy to fool if you use a non-static string for the name). I've not seen any tree shaking yet that does otherwise. Although the fascinating rol

[elm-discuss] Re: What do you think about Types/State/View split?

On Wednesday, January 25, 2017 at 12:11:46 PM UTC, Rupert Smith wrote: > > I think a better approach would be to put build a TEA component like this: > > module MyComponent exposing (Model, Msg, update, view, init, > subscriptions) -- and perhaps also OutMsg > So I think I understand where the te

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

I am not interested in campaign, it's not fun. But I cannot help replying when I see some inexact arguments... elm is a reasonably fast language, I think it might run even faster than purescript, enjoy your work! On Wed, Jan 25, 2017 at 4:55 AM Robin Heggelund Hansen wrote: > > Actually tree shak

[elm-discuss] Re: What do you think about Types/State/View split?

On Tuesday, January 24, 2017 at 4:32:41 PM UTC, jphedley wrote: > > FYI, Kris Jenkins' approach- > http://blog.jenkster.com/2016/04/how-i-structure-elm-apps.html > Part of the reason I think this design is wrong, is that when importing a component into the top-level Main module to use it, I have

[elm-discuss] Re: Html.Attributes.none

On Tuesday, January 24, 2017 at 10:21:31 PM UTC, Robert Lee wrote: > > Would anyone else find --Html.Attributes.none-- useful? > +1 Yes. Also elm-mdl has a 'when' function which is very useful, and a version of it for Html.Attribute would be very handy: Button.disabled |> when (not model.isRu

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

> Actually tree shaking will do absolutely nothing for Elm code as Elm > compiles everything into a single module that all highly indirectly > references itself. It would help with bucklescript as it outputs modules, > but bucklescript already tree-shakes as part of its compiler optimizations