>>You can compile two modules into the same file and use one in the header and one in the footer. No problem there.
Since I could only bind the elm to a html div, and if I wanted to the center to not be in elm, I would need one file to bind to the header and one to bind to the footer. Is there double binding in elm right now, where I can attach one compiled elm file to two different sections of a page? >>elm-html is very easy to pick up. It's a direct mapping. A designer that know HTML can learn and adapt their knowledge within the hour. It may be easy to learn, but wow is it not fun. I once converted a 1000 line html page all in Elm with css redone in elm. It took forever and it was harder for people to find things. I tried the Atom html to elm converter, but it breaks. If a very small portion of a project needed to be done in elm-html I can understand people copping with this extra work. >>New versions of Elm This might depend on the size of the project. It took hours to sort through the mess after the change from 0.16. Imported packages did not update or took months to be changed. Many portions of our application needed to be completely redone. Trivial projects might have no issue. Any code base with more than 5 or so files will feel the pain when these large changes happen. 2017年1月29日日曜日 17時43分21秒 UTC+9 Peter Damoc: > > On Sun, Jan 29, 2017 at 4:40 AM, Wyatt Benno <[email protected] > <javascript:>> wrote: > >> 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? >> > > There is an experimental compiler that does just that: compile Elm in the > browser. > However, to make that reach the level of performance of the installable > compiler requires a large amount of developer time and there are other > things that are more important. > > >> 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. >> > > Do you think that a developer would have troubles installing the tools of > the language that he is developing in? > > 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. >> > > You can compile two modules into the same file and use one in the header > and one in the footer. No problem there. > > >> 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. >> > > elm-html is very easy to pick up. It's a direct mapping. A designer that > know HTML can learn and adapt their knowledge within the hour. > > > 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. >> > > New versions of Elm change things but most changes are small and they > improve things. The core of the language is made of a set of small and > powerful ideas and those are rock solid. Most changes are at the periphery. > Take the removal of FRP. With the move to 0.16 The Elm Architecture became > a standard and with people adopting it, it meant that most of the hairy > Signal code was delegated to the periphery. The core of the app code was > just types and functions. > When the Signals were removed, for most people, of the update process was > a matter of deleting addresses from the view and adapting some update code. > And the compiler got your back giving you a TO DO list that you could see > getting smaller and smaller. > > This was the biggest change to the language since its creation and people > were able to update the code base within a day or so. > Contrast that with the change from python 2 to python 3 or ng1 to ng2. > > >> 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. > > > It can be used in production right now but it is not ready for early > majority. > We are still in the early adopters phase. > > > > -- > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
