On Sun, Jan 29, 2017 at 4:40 AM, Wyatt Benno <[email protected]> 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.
