Re: [elm-discuss] Re: Embedding multiple elements into JS

Cheers no problem. That was the conclusion on Slack also. On 25 March 2017 at 10:55, Nicholas Hollon wrote: > err, I meant that message to be a little bit more timely, but it got held > up in moderation. Glad you got help -.- > > > On Friday, March 24, 2017 at 3:49:24

[elm-discuss] Re: 'Native' -> 'Kernel': a msgpack example

Yeah, I regretted posting that 2nd half. I don't use any native modules myself except the one to return decoders out of ports. And I was getting by without it via ports, although somewhat less optimally. Maybe some people really need native stuff, though. I haven't. (And I'm willing to monkey

[elm-discuss] Re: Embedding multiple elements into JS

err, I meant that message to be a little bit more timely, but it got held up in moderation. Glad you got help -.- On Friday, March 24, 2017 at 3:49:24 PM UTC-7, Nicholas Hollon wrote: > > You should have Elm return the , and embed the program an empty div. I > am pretty sure you are only

[elm-discuss] Kite, An Interactive Visualization Tool for Graph Theory

Thanks for sharing - particularly interested in seeing your link to d3; I'm using it extensively and hoping to use 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

[elm-discuss] Re: Embedding multiple elements into JS

You should have Elm return the , and embed the program an empty div. I am pretty sure you are only allowed to embed Elm programs in divs anyway, not just any old html tag. On Wednesday, March 22, 2017 at 7:36:44 AM UTC-7, Matt Joiner wrote: > > I'm looking to embed Elm in an existing web

[elm-discuss] elm debugger as a browser extension

Have you seen this? https://github.com/jinjor/elm-devtool -- Roman -- 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

[elm-discuss] Re: 'Native' -> 'Kernel': a msgpack example

Indeed, the post mentions renaming Native to Elm.Kernel and ending the native module whitelist (sortof). Expectation management. User native module blocking was not mentioned. In our current Javascript ecosystem such a thing would make Elm non-viable. Well, except that repo-forking and

[elm-discuss] Re: Web components vs. Native

Hey Rupert. I'm not comparing web components to ports. Of course ports are a standard, important part of elm. My comparison is to native elm, which is different. For example, https://github.com/elm-lang/persistent-cache/tree/master/src/Native Ports can't break the debugger's guarantees

[elm-discuss] elm debugger as a browser extension

It would be nice to have the elm debugger (the overlay one you get when running apps with elm-reactor) as a browser extension, instead of being embedded in the document. Something like the redux-devtools-extension: https://github.com/zalmoxisus/redux-devtools-extension How would one approach

[elm-discuss] Re: 'Native' -> 'Kernel': a msgpack example

On Thursday, March 23, 2017 at 8:15:51 PM UTC, Simon wrote: > > It's pretty clear that these practices are frowned upon, but the shift to > 'kernel' sounds like a plan to squeeze the pragmatic programmer's options > further. I hope that's not the case. > I think all that is happening is that

[elm-discuss] Re: Web components vs. Native

On Wednesday, March 22, 2017 at 11:57:22 PM UTC, Maxwell Gurewitz wrote: > > Hi all. I'm creating this thread to discuss the relative merits of web > components and native code. > One of the merits is that you can avoid ports to some extent, because a web component can be set up by passing it

[elm-discuss] Re: Kite, An Interactive Visualization Tool for Graph Theory

Great stuff, thanks for making it open source! On Thursday, March 23, 2017 at 11:26:50 PM UTC+1, Erkal Selman wrote: > > I would like to announce that I open sourced my hobby project, which I > named Kite. Here is the demo . Here is the > source

[elm-discuss] Re: To wrap or not to wrap

I try to answer myself the question whether or not a type is going to be exposed (used by client code) or if I just want to wrap some fields into an alias for convenience. As soon as a type becomes exposed, I prefer strong types because of their stricter contract. Also, strong types are easier

Re: [elm-discuss] Re: 'Native' -> 'Kernel': a msgpack example

> The work around is a native file along the lines of (or see this NoRedInk > library): Sidenote: That is not a NoRedInk library. I do not work at NoRedInk any more. It's a eeue56 library. It's important to distinct the two. On Fri, Mar 24, 2017 at 4:19 AM, Martin Bailey