On Tuesday, 24 January 2017 21:42:54 UTC+7, Kennet Postigo wrote: Re: If performance, efficient output, and functional programming in the browser is what you are looking for OCaml + Bucklescript or ReasonML+ Bucklescript would be a solid fit!
If you read through the thread, you'll see that I did try BuckleScript with the view to using it to augment the Elm Architecture as a Web Application Framework. Some of the things I found are the following: 1. The compiler speed is exemplary and likely higher than anything else available due to its OCaml heritage. 2. The JS generated can be very high performance and the BuckleScript add-on back end adds tools to be able to efficiently talk to JavaScript or even directly emit JavaScript code without too much trouble. 3. One can use all of the functional programming paradigms that OCaml provides. Unfortunately (for my use), I found that high output JS code performance and functional paradigms weren't always possible at the same time across the range of mainstream browsers using BuckleScript, as follows: 1. Closures (functions that capture free mutable variables from outside the scope of the function) are implemented as required by JS by a function returning a function, but in some browsers (current Chrome V8 based), building these internal returned functions is 50 to a 100 times slower than calling a regular function. As with any of these transpilers, this isn't a serious problem as for any of them one can easily lift or manually create closures outside tight inner loops that generally makes this of no significance in most real code. It will likely get fixed in future versions of BuckleScript by more extensive mutability analysis so as this type of closure is only created when necessary (when the binding could mutate before the execution of the closure function) and their creation optimized so as to be created where the cost of creating will have the least cost (outside inner loops). 2. I found that the implementation of functional programming currying seems to be slow on some browsers (primarily in current Firefox) and the workarounds I found are ugly: I found that if one wants to write code that consistently runs fast across all current browsers, one either has to add extensive annotations to tell BuckleScript to emit JS without currying for tight inner loop calls or one has to write their code in ugly imperative style (without function calls) in tight inner loops if such tight inner loops take a significant portion of the execution time. Thus, I have chosen to try to stick with Elm for the following reasons: 1. Elm is a complete Web Application solution, providing both a Framework and a simple, concise, and consistent functional language that is well integrated with that Framework and with that Framework becoming recognizes as one of the best in the industry. To be a complete replacement for Elm, BuckleScriipt would need to have a Framework library/modules added. 2. It turns out that my main issue with Elm language performance is primarily in just one simple area as well described in the opening few posts of this thread. This is exactly the area which is fixed by using BuckleScript, but the costs of using it almost outweigh the benefits as per the above set of points. 3. My other speed issues with the Elm system are non-mainstream library/module issues, and they can easily be fixed by contributing to the libraries involved or contributing/using my own. In conclusion, I know that JS code output by Elm for the very tight math type loops I require will likely never be as fast as hand written and tuned JS, but I have confidence that it will get better as future developments improve Elm. By better, for most users this will be an increase of about 30% for some types of algorithm, which for my generally tighter loops than most people require, may translate into about a 300% to 500% increase in tight loop speed for my use; Meanwhile, I can easily either hand patch critical tight loops (or automate the process of patching) or put such critical tight loops into Native JS modules written in whatever language produces the best output JS code, whether it be TypeScript, BuckleScript, Nim, or even JS itself, as these tight loops are generally quite small. I've learned what I wanted to find out about Elm speed in this thread to date, and will now only report progress in contributing to further gains in Elm speed. -- 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.
