Re: [elm-discuss] Proposal: Main.attach(node) to attach Elm to existing DOM?

This is more than theoretical. First rendering delays are noticeable on even moderately highend mobile devices. Attaching to an pre rendered DOM, optionally enhancing it, is a big win. It's not just something done in React. (I first saw it in a Backbone application if that helps date it.)

Re: [elm-discuss] Re: My Argument for "Why Elm" please review before I present to my company

Looking back I can totally see that this is the wrong approach. I'll be thinking about what project or presentation I can use in lieu of this write up. On Fri, Jan 13, 2017, 5:51 AM 'Rupert Smith' via Elm Discuss < elm-discuss@googlegroups.com> wrote: > On Friday, January 13, 2017 at 12:49:57 PM

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

Keep in mind that code is the easy part ; the major thing standing between Elm and a different compilation target than JavaScript is 1-2 years of design work to figure out a quality user experience. > I'm wondering why the Elm compiler is so slow

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

On Saturday, 14 January 2017 00:38:03 UTC+7, OvermindDL1 wrote: > > But yes, translating Elm to OCaml/Bucklescript would not at all be a hard > task. :-) > An Elm front-end to OCaml sounds interesting and I especially like the sound of "faster compilation speed" (about 400 times faster???).

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

On Friday, 13 January 2017 22:40:07 UTC+7, Rupert Smith wrote: > > On Friday, January 13, 2017 at 3:18:48 PM UTC, OvermindDL1 wrote: >> >> That is actually why I think Elm should compile to a a different >> back-end, like ocaml/bucklescript or so. The syntax is uniform enough that >> making an

Re: [elm-discuss] Re: Replacing Json.Decode.customDecoder for new 0.18 code?

Matt, that's great code! Super concise! I've actually seen a couple people ask about this lately and run into it myself, so I wrote it up with more details: https://www.brianthicks.com/post/2017/01/13/create-custom-json-decoders-in-elm-018/ On Friday, January 6, 2017 at 11:15:24 AM UTC-5, Rex

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

On Friday, January 13, 2017 at 10:10:28 AM UTC-7, Joey Eremondi wrote: > > Even a direct Elm to OCaml translation wouldn't be too hard. Elm is not > the same as OCaml, but my understanding is that most of its features are > included in Elm (row polymorphism, strict evaluation, >

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

Even a direct Elm to OCaml translation wouldn't be too hard. Elm is not the same as OCaml, but my understanding is that most of its features are included in Elm (row polymorphism, strict evaluation, first-class-functions). OCaml has lots of features Elm doesn't want (like mutable references) but

Re: [elm-discuss] Mutually dependent types

Op vrijdag 13 januari 2017 09:13:25 UTC+1 schreef Marco Perone: > > Coming back to my original question, supposing we have two mutually > recursive types, they must be in the same module and hence in the same > file, right? > Yes, that is what I would think too. I would argue that it would be

Re: [elm-discuss] Proposal: Main.attach(node) to attach Elm to existing DOM?

On Fri, Jan 13, 2017 at 5:28 AM, 'Rupert Smith' via Elm Discuss < elm-discuss@googlegroups.com> wrote: > I said that it might add some complexity or be a little slower but only in > the case where 'attach' is being used. A further observation is that the > extra complexity would only be needed on

Re: [elm-discuss] Mutually dependent types

This is exactly what I am doing right now to circumvent this issue. But I feel that this is some kind of language limitation that I would like to avoid. It would be nice to be able to define parts of the same module in different files 2017-01-13 17:17 GMT+01:00 Wouter In t Velt

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

On Friday, January 13, 2017 at 8:40:07 AM UTC-7, Rupert Smith wrote: > > All that this would take would be to write an Elm parser into the first > stage of the OCaml pipeline? You'd also need to compile the Native modules, > is there already some way to feed them into the Ocaml pipeline? >

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

On Friday, January 13, 2017 at 3:20:24 PM UTC, OvermindDL1 wrote: > > I'd still not recommend reddit, it has no mailing list support. Here or > Discourse both act well as a forum (though discourse more so) and as a > mailing list both, so either works. > I agree, /r/elm should point here for

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

I'd still not recommend reddit, it has no mailing list support. Here or Discourse both act well as a forum (though discourse more so) and as a mailing list both, so either works. On Friday, January 13, 2017 at 12:34:47 AM UTC-7, Håkon Rossebø wrote: > > I would also prefer a solution like

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

That is actually why I think Elm should compile to a a different back-end, like ocaml/bucklescript or so. The syntax is uniform enough that making an elm->ocaml/bucklescript transpiler would be just a matter of re-using most of the existing parser in OCaml, which is already beyond blazing fast

[elm-discuss] elm-graphics-app: An Elm Teaching Library (influenced in part by elm-playground)

I thought that Elm.Graphics was on its way to being replaced by something else. The fact that it's not even found in the official (latest) docs doesn't help. Will look at your lib though as it seems quite interesting. Thanks for that. -- You received this message because you are subscribed to

[elm-discuss] Re: My Argument for "Why Elm" please review before I present to my company

On Friday, January 13, 2017 at 12:49:57 PM UTC, Rupert Smith wrote: > > On Thursday, January 12, 2017 at 10:54:12 PM UTC, joseph ni wrote: >> >> arrived into the face of anyone who will listen. This revolution needs >> your emations as much as your cleverness. :-P >> > s/emations/emotions/ - if

[elm-discuss] Re: My Argument for "Why Elm" please review before I present to my company

On Thursday, January 12, 2017 at 10:54:12 PM UTC, joseph ni wrote: > > Reading through your points, it seems that this is not a pitch but rather > a list of highly emotional responses to their concerns the first time > around. > Yeah, just shove anyone out of the way who disagrees that

[elm-discuss] Re: elm-mode-goto-tag-at-point (Emacs)

Answering my own question: just set '(elm-tags-exclude-elm-stuff nil). This will cause elm-tags to include everything in ./elm-stuff Sorry to bother everyone, though hope this helps someone else! Marshall On Wednesday, January 11, 2017 at 7:35:48 PM UTC-5, Marshall handheld Flax wrote: > >