Draft blog post - "How to Use Elm at Work" - looking for feedback

[Evan Czaplicki]

DRAFT - Do not share the npm package or draft blog post yet!

Embedding Elm in some big JavaScript project is not very hard, but I think you currently need quite a lot of experience with Elm for this to be obvious. It's like three lines of JS, but you typically learn those lines pretty late.

So I created react-elm-components to make it much more obvious.

In addition, I drafted a blog post called How to Use Elm at Work that outlines the typical success story I hear from people that introduced Elm successfully. Let me know what you think!

I am planning to announce both of these things on Monday, so please do not share react-elm-components or the blog post before then! It is cool to talk about it in Elm community forums of course, but please not on Twitter, Reddit, HN, etc!

Context

I released keyed HTML nodes last week. This was the final technical hurdle blocking a blog post about the performance improvements in elm-lang/html. It is much faster than a lot of things! As I drafted that blog post, I realized it would be helpful to publish "How to Use Elm at Work" first. I hope that "Elm is faster than X" will get a decent group of people interested in giving it a shot, so I want to make the next steps as clear as possible!

[Gage Peterson]

Looks pretty awesome Evan! I think the React component is especially genius. 

[Max Goldstein]

not pouring time and money -> not pouring a lot of time and money, just in case some skeptical manager reads it.

Otherwise looks good!

[Jeff Smits]

The post looks good.
The title might rub people the wrong way though. Maybe it's just me but it sounds a bit like "You don't get to decide how to use Elm at work, I'm going to tell you how you're allowed to do it".
"Using Elm at Work" doesn't have that connotation for me. But the post seems to be more about "Introducing Elm at Work". Or perhaps the title should focus on JavaScript integration, since that's what people cannot easily find but is described in the blog post.

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

[Max Goldstein]

So I thought about this a bit more and have some technical feedback, even though it's beyond the scope of this post. If I apply this pattern more than once, do I have completely separate elm programs that live in different parts of my js app? What if they need to share code, e.g. model definitions? Do I have to send multiple copies of the core library down the wire? Do I commit the compiled Elm to git?

My ideal tooling here, and I suspect that NRI has some of this already, would allow multiple Elm projects to be built, linking against one copy of common code (core, model defs, 3rd part libs). It would tie into Rail's asset pipeline to recompile on page load or file change in development and precompile in production.

If we're serious that this is the success story, than we should write tooling to that story. The compiler is still built around an entirely elm website.

[Dmitry Utkin]

This is a great starting point to introduce Elm to existing app.

But I think it's missing a very important note: what happens to the resulting bundle size once you include multiple <Elm/> components...

Another interesting(IMHO) question that's not covered is introducing Elm at the top level, that can become a root supervisor for the existing stateful React component trees.

[Yonatan Kogan]

I think this is super awesome. We tried to create some Elm components that could live as part of the React view and really struggled. I echo the other sentiments, however, that the tone of the post feels a bit prescriptive (perhaps by design) and that the specific case of an Elm component that can live without needing any changes from the javascript data model is rare. I think fleshing out the "advanced usage" a bit more (maybe with one example) might help with that.

[Rohan Orton]

>>> Richard has the best strats.

Is this a typo? Or is Richard a collector of guitars?

[José Lorenzo Rodríguez]

This is great news!!

Do you know if this will work when using server side rendering? If not, how big of an effort would it be to support it?

[Adam Waselnuk]

I would suggest the following change:

Embedding Elm in some big JavaScript project is not very hard. It's like three lines of JS, but it feels like no one knows about them! So I created react-elm-components to make it much more obvious.

change to something like:

Elm is optimized for embedding into your existing JavaScript projects. With about three lines of JS, you can have Elm components interoperating with your app giving you the opportunity to experiment and experience the power of Elm sooner! I have created react-elm-components to make this even simpler.

Still needs work probably but basically consider the following: "some big project" is vague and sounds a bit dismissive of existing JS projects. "not very hard" is probably true but try not to assume what is hard for other people. "It's like three lines .." also sounds dismissive and like anyone should know this obvious thing. It's very obvious to us but not to the people you want to capture in this post. Finally, try front loading a bit of the Elm awesomeness! Why do I care to embed an Elm component? Probably because I want to experiment and Elm is just really great!

[Yosuke Torii]

Looks great. However, I also agree with what other folks have mentioned.

Multiple Elm components in one app needs large copy of common code. I think providing a core library like "elm-runtime.js" would be helpful, for sharing code and enabling browser cache (maybe using it via CDN?). React + Elm is already heavy especially considering mobile apps (not sure mobile apps are the target of Elm though). Also, some people find value in server side rendering which React supports and Elm doesn't.

IMHO, the title "How to use Elm at Work" sounds like estimating the reasons for not using Elm in production too small. For reasons like "I love Elm but my manager does not allow adopting it" or "I don't have enough confidence to introduce Elm in a large legacy code", this post is super great. I strongly agree with everything mentioned in "The checklist".

Please don't take this wrong way. I don't mean to say "Elm should support all these features". Just thinking how to tell things the best way.

2016年7月7日木曜日 8時46分27秒 UTC+9 Evan:

[Evan Czaplicki]

What about the other stories?

To folks saying, this seems too one-size-fits-all, I have not heard another story. I have seen people try other paths. They don't work though. So I'd love for there to be other paths, but I have not heard of another one.

Now, it is true that if you are a consultant under specific circumstances or the only engineer on a project, you can do things a different way. I think these stories are the outlier though, and I think the general outline of the story here still applies to them. They just skip the "help everyone learn" phase.

I feel like I emphasize this appropriately in the post though.

Many Components

Yesterday I added a section about "what to do the second time" that suggests growing your component or doing something more ambitious on a separate page. I can't tell if people are reacting to the most recent blog or the commentary on old versions, but I think the "embed 90 things and be sad" route is a plausible mistake, so I'll make it more explicit.

Okay, thanks for the feedback! I gotta write a bunch of other posts too, so I will make edits and things will go live on Monday.

--

[Peter Damoc]

On Fri, Jul 8, 2016 at 9:28 PM, Evan Czaplicki <eva...@gmail.com> wrote:

What about the other stories?

I have tried to use Elm in a work context and I'm becoming one of those sad failure stories that can be used with the "caveat emptor" label. 

 

I have seen people try other paths. They don't work though. So I'd love for there to be other paths, but I have not heard of another one.

Of course they don't work. 

The main reason for this is the lack of an Elm component architecture that would allow people to create reusable components that can be bundled in libraries. 

If someone wants to implement a 1996 webpage in Elm, they can do that with the current technologies. 

If someone wants to implement a 2016 webpage in Elm... tough luck! They will have to reinvent multiple wheels and few people have either the time, energy or the know-how to do that.

Do you have a story of someone implementing a simple user form in Elm and enjoying both the experience and the result? 

I'm not talking about something exotic or completely out of the ordinary here. 

Just some textfields for First Name, Last Name,  username, password. A switch for gender and an Address subform with a filter/search dropdown for State/Country. 

This is trivial in Html/CSS/JS land with the help of (take your pick: Bootstrap, SemanticUI, AUI, etc.)

When I discovered Elm it promised to offer a nicer interface to creating web apps and isolate people from the insanity of HTML/CSS/JS. 

I don't know enough HTML/CSS/JS and so this was tremendously attractive to me. 

Graphics.* elements were a huge step in the right direction (API wise) and people loved them but they were abandoned without an alternative. 

And now we live in a world where the best path for approaching Elm is embedding it into a React component. :( 

Elm should have been the alternative to React. You should have been writing articles about how to port React components to Elm components. 

elm-make/reactor could have replaced the entire insanity of the JS build tools. 

Sadly we do not live in that world. We could have, but we don't. 

There have been people who have tried to approach this (e.g. elm-mdl)  but they were explicitly or implicitly dismissed. 
You seam to have buried your head in the sand and ignore the issue of components considering that it is solved with The Elm Architecture. 

It is not solved and the countless questions about communication within a components hierarchy are a proof of that. 
The More About Modularity page from the guide that's just promising "more soon" is a testament to how bad things are.
I remember when this section had "Nesting" and "Communication" which were things people are truly interested in. 

The process that prevented this section from reaching completion is the very essence of the biggest problem with Elm right now.  

Who, beside you Evan, understands The Elm Architecture well enough to write that section to your satisfaction ?

It looks like the answer is no one. 

How about getting rid of Signals and leaving empty the Effect Mangers section of the guide? You know, the one that was suppose to deal with their replacement. 

You do tell them that the exotic stuff that they might have used Signals to implement can be implemented easier with the Effects Managers BUT give no clue about how they could go about doing that. 

But I'm glad that developers that have already added few hundred kb of the React library will be able to add few hundred more from the Elm runtime so they can get a 1.7 MB of JS simple echo app.  ;) 

I might sound unduly bitter but I'm slowly losing my hope in Elm and this brings me tremendous sadness. 

--

There is NO FATE, we are the creators.
blog: http://damoc.ro/

[Richard Feldman]

Ouch, those are some strong words... D:

I agree that the docs for reusable Elm Architecture components are not published. Fair point.

I can't say I agree with the rest, though.

Do you have a story of someone implementing a simple user form in Elm and enjoying both the experience and the result?

*raises hand*

This is trivial in Html/CSS/JS land with the help of (take your pick: Bootstrap, SemanticUI, AUI, etc.)

This is also trivial in Html/CSS/JS without the help of any of those.

It's also trivial in Elm.

It's just a trivial project...why would you need a nontrivial component hierarchy to implement a simple user form?

Graphics.* elements were a huge step in the right direction (API wise) and people loved them but they were abandoned without an alternative.

And now we live in a world where the best path for approaching Elm is embedding it into a React component. :(

The thing is, from the perspective of "using Elm at work," we've always lived in that world.

The only folks I know of who used Graphics.* in production are CircuitHub, and they embedded multiple Elm widgets inside an existing HTML/JS page. I'm not sure if the host was precisely React, but regardless, they followed exactly the same path Evan is writing about here. Nobody has done a scratch-rewrite at work and succeeded, as far as I know.

Also, Graphics.* has not been "abandoned without an alternative" considering it's been updated for 0.17. Anyone who thinks it's a good choice for work has just as much ability to use it today as they have for the past 3 years!

There have been people who have tried to approach this (e.g. elm-mdl)  but they were explicitly or implicitly dismissed. 

Huh? elm-mdl is alive and well - its latest release was less than two weeks ago.

I get that you've venting, but aside from the complaint that the guide is unfinished, these other objections seem to be more hurtful than accurate.

[Peter Damoc]

Richard, 

Regarding the user form, you said that what I asked is trivial in Elm. 

Do you have some kind of sample code that you can share or, if you would be so kind, could you post some sample repository that does that? 
I would LOVE to be proven wrong about that. I would love to see some simple Elm code that outputs a form that looks like it came from 2016 and go "oops, my bad, sorry for wasting everyone's time". 

Regarding the "Elm at work" and React. 

Yes, you (NoRedInk) might have always lived in that world but this doesn't make that world the best world. 

It's just the most familiar world for you.  

Regarding using Graphics.* in production, I feel I need to clarify something. I was not arguing for using Graphics.* in production, that library was never ready from my perspective. 

What I was arguing for was something akin to SemanticUI implemented using the approach that Graphics.* had. For example, using a button from Graphics is a better experience than using a button from Html. 

When I was decrying the abandonment of Graphics.* I was not decrying the fact that the library does not work with 0.17, I was decrying the fact that the reason for creating that library has been abandoned. 

That reason was allowing someone to create a UI without ever having to touch HTML/CSS/JS

Regarding elm-mdl. I am well aware of the release of 6.0.0. I was not arguing that people are not still fighting. 

What I said was that "they were explicitly or implicitly dismissed". 

If you want me to be more explicit, I was thinking about the discussions around boilerplate that prompted elm-parts, the difficulties around geometry that prompted debois/elm-dom.
The component ideas around elm-mdl are at best tolerated.  

I apologize if what I said was hurtful, it is not my intention to hurt anyone. 

Maybe some of my own pain dripped into my words. 

--

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.

[Janis Voigtländer]

This:

Also, Graphics.* has not been “abandoned without an alternative” considering it’s been updated for 0.17. Anyone who thinks it’s a good choice for work has just as much ability to use it today as they have for the past 3 years!

is simply not true, is it?

All of Graphics.Input was dropped, so none of the functionality earlier available in http://package.elm-lang.org/packages/elm-lang/core/3.0.0/Graphics-Input is available anymore. And we have seen people on this mailing list react in shock that what they did with inputs in a Graphics setting before is suddenly not possible anymore. I remember at least one instance where someone wrote that they had an Elm application in their company built with Graphics.Input and it was now impossble for them to update it. For that person it is certainly not true that they have just as much ability to continue using Graphics.* today as they had for the past 3 years.

​

--

[Janis Voigtländer]

Richard, this is the post I had been remembering: https://groups.google.com/d/msg/elm-discuss/Y1B6kKdXCNw/5Ky57c-IAQAJ

Sounds like these are other folks, aside from CircuitHub, that have been using Graphics.* in production (but I don’t know for sure what your definition of “in production” is; does an in-house tool count?). And would you agree that what you said in your message about continued ability to use Graphics.* does not seem to be a reality for them?

BTW, it’s also remarkable that the plea for help/guidance expressed in that posting didn’t get any response. At least not on the mailing list.

​

2016-07-09 10:45 GMT+02:00 Richard Feldman <richard....@gmail.com>:

--

[William Bailey]

Oh dear.

>>  Elm promised to offer a nicer interface to creating web apps and isolate people from the insanity of HTML/CSS/JS

This is exactly why I chose to go with Elm a couple months ago.  I had no interest in becoming enough of an expert on HTML/CSS/JS to do a complex animated game in them. See what I have done in Elm here:

deepfinesse.com/demo. 

It's been a total joy implementing this in Elm, learning as I go.  But now I seem to have hit several show stoppers.  I chose to implement using Graphics.* not Html.*.  At first, the paradigm shift in 0.17 presented no problems, my app ported over easily.  But now:

1. Lack of Touch.* means no smart phone support (partially solved, see separate post)

2. Animations even when idle burn 100% CPU causing complaints of laptop fans going beserk (see separate post)

3. No Graphics.Input

I've been woken up to this last one by this thread. I haven't added it yet, but I do need a way for users to enter new deals to analyze and play through.  Usually this would just be a cut&paste job of a text description of a deal but also one could type into it manually, something like this describes a bridge hand:

7.9.A987642.9863 96.T852.KT.AKJ52 AKQJ8542.AKJ..T7 T3.Q7643.QJ53.Q4

I suppose all 3 issues means I will need to bite the bullet and convert everything over to Html.*?

[Christopher Anand [g]]

We have tried to make a Graphics replacement candidate which uses SVG instead of canvas.  SVG should be more efficient than canvas for vector graphics, although benchmarking is ambiguous.

The roadblocks are:

 - embedding html in svg as a foreign object is extremely inconsistent across browsers

 - there is no good way of determining the size of text so that other graphics elements can flow around them

This makes text input impractical.  Note that text input was not robust across browsers in the old Graphics.

The first problem is not an ELM problem, but the second one seems solvable.

[Richard Feldman]

 

Regarding the user form, you said that what I asked is trivial in Elm. 

Do you have some kind of sample code that you can share or, if you would be so kind, could you post some sample repository that does that? 

I would LOVE to be proven wrong about that. I would love to see some simple Elm code that outputs a form that looks like it came from 2016 and go "oops, my bad, sorry for wasting everyone's time". 

Sure - I even wrote a blog post about it. :)

That post includes examples in the form of SignupForm.elm and the styles that go with it. I didn't bother inline the styles into Elm, but obviously that's a copy/paste and find/replace job.

All of Graphics.Input was dropped

Ah, I did not know that! My mistake. You're right, Janis.

Regarding elm-mdl. I am well aware of the release of 6.0.0. I was not arguing that people are not still fighting. 

What I said was that "they were explicitly or implicitly dismissed". 

If you want me to be more explicit, I was thinking about the discussions around boilerplate that prompted elm-parts, the difficulties around geometry that prompted debois/elm-dom.

Facebook released React with a built-in, dead-easy way to do reusable stateful components: each component has its own local mutable state.

However, they at Facebook weren't satisfied with how this UX scaled, so they also released Flux as a more scalable way to manage state.

Many people weren't happy with Flux, though, so they started looking elsewhere, for example to ClojureScript, leading to Omniscient.js based on David Nolen's cursor-based state management model for Om.

David Nolen himself ended up moving away from that with Om Next, which abandoned cursors in favor of a custom state management system based on Relay, Falcor, and Datomic. Obviously not everyone agrees with him; Omniscient.js is still under active development. Its last commit is 2 days ago.

Others looked to Elm, like Dan Abramov, who created Redux. It's very popular in the React world, although since Facebook hired Dan, he's been working on ways to make React not need it anymore. That seems likely to result in the release of a new way to do things, whenever whatever it is gets released.

Others thought Redux was too heavyweight and trying to do too much at once, which has led to Choo, a self-described adaptation of Elm 0.17's architecture in JS.

I've spent hours discussing these things with Jafar Husain at Netflix, who thinks Observables are the answer. See for example rx-react or Andre Staltz's popular Cycle.js.

This is to say nothing of how Angular manages state. Or Ember. Or Aurelia. Or Vue.

My point is this:

Every single community that's involved in making browser-based UIs is flooded with conflicting viewpoints on how reusable stateful components should be done.

There is not some glaringly obvious answer that will make everyone happy. It does not exist.

History strongly suggests that in this area, making one group of people happy makes others unhappy.

I was on a Skype call several months ago where Søren and Evan had an extended discussion about his experiences developing elm-mdl. The fact that Evan did not end up doing things the way you think he should is not a reflection of Evan being dismissive of Søren's experience, it's that reusable stateful components are a minefield of tradeoffs.

Personally I think when one finds oneself in a minefield, it is wise to tread carefully. :)

[Peter Damoc]

Richard, 

Thank you for taking the time to write this considerate answer. 

I apologize for the post I wrote yesterday. 

I was in a very very dark place after a night plagued by insomnia at the end of an extremely stressful week where I could not get anything done. 

Fear is the path to the dark side... and I think I let fear take over. 

Anyway, it is fascinating to see that such a seemingly simple topic has the brightest minds in the world still looking for an answer. 

I did not knew that the situation is this complicated. 

--

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.

[Richard Feldman]

It's all good. :)

This stuff is complicated!

You received this message because you are subscribed to a topic in the Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-discuss/gVY5DmZOR9s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss...@googlegroups.com.

[Yosuke Torii]

Sorry, please let me adjust my previous comment.

I said React+Elm is too large, but now I found it's NOT so large as I thought.

(Of course not as small as lightweight libraries yet)

I just saw the number at TodoMVC.

elm.js: 69.7 KB gziped

(including all user code)

react-with-addons.js: 174 KB gziped

jquery.js: 83.9 KB gziped

I'm surprised the fact Elm is even smaller than jQuery.

It means React+Elm is smaller than React+jQuery.

Considering it's temporary to use them together, this number is not too bad, I think.

[Peter Damoc]

TodoMVC in Elm is 21kb (minified & gzip) ;) 

[Yosuke Torii]

TodoMVC in Elm is 21kb (minified & gzip) ;) 

Oh, great to hear that :)

Is that using Closure Compiler? I'd like to know if there are some place to see those numbers. It may be helpful to make decisions.

[Janis Voigtländer]

Christopher, has your Graphics-via-SVG experiment led anywhere in the meantime?

I have this hobby project relying heavily on the interactive aspects of the old Graphics library (see below), originally done when Elm 0.16 was current, but only now put online (previous uses were “in-house” only, as in “in our family home, by my son”).

Thinking about how this might be updated to Elm 0.17, it seems almost impossible to do. Not because of any signal vs. not-signal problems, but simply because of the lack of a declarative graphics API like Graphics that also enables attaching event handlers. That’s what disappeared from elm-graphics when Graphics.Input.* disappeared. Anyway, a Graphics replacement done via SVG would probably address this, because I assume it would support attaching event handlers like onclick and onmouseover to the created graphics nodes just as it works for “normal” (html and svg) nodes now?

https://github.com/jvoigtlaender/circuits

--
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+unsubscribe@googlegroups.com.

​

[Rupert Smith]

On Tuesday, September 6, 2016 at 4:08:29 PM UTC+1, Janis Voigtländer wrote:

Thinking about how this might be updated to Elm 0.17, it seems almost impossible to do. Not because of any signal vs. not-signal problems, but simply because of the lack of a declarative graphics API like Graphics that also enables attaching event handlers. That’s what disappeared from elm-graphics when Graphics.Input.* disappeared. Anyway, a Graphics replacement done via SVG would probably address this, because I assume it would support attaching event handlers like onclick and onmouseover to the created graphics nodes just as it works for “normal” (html and svg) nodes now?

+1 for getting Graphics ported to SVG + Elm 0.17. 

I'm pretty sure I will go with SVG for the graphical portion of my application and not canvas. I also need to combine text + graphics. Not sure how I will achieve this yet...