I thought you might 
If Ricardo is too busy, or just not interested in Bucklescript, perhaps he would allow you to use the assets to duplicate/create the Bucklescript version and put it on your own blog… then you could link to each other’s blog posts saying this is how the same project could be tackled in the other language. I reckon it would be a huge hit 
What do you think @bigardone @OvermindDL1 
Please feel free to tell me to get lost if you hate the idea 
Elm’s syntax is taken near straight from OCaml (Bucklescript is just an OCaml back-end that compiles to javascript) except for function definitions and let bindings where Elm follows Haskell for some weird reason (OCaml’s is a lot more succinct). 
I’ve made an npm package for bucklescript called bucklescript-tea that adds the Elm TEA style as a library to Bucklescript, you can copy your elm code over and make just a couple minor changes.
That sounds awesome; I’ll definitely give it a try! 
FYI: My interpretation of this is that basically “components” are an OO thing, not an Elm thing - which deals with its constituent parts a bit differently (though I may be oversimplifying things a bit).
PS: GRiSP - Bare metal hardware for the Internet of Things, specifically designed for Erlang.
Hi, I am new to bucklescirpt recommanded by @jackalcooper. I have read the thread and readme of your bucklescript-tea, I understand that you think elm really bad and bucklescript is just awesome. However, I have some questions just on elm. To be frank, I am also new to elm. I am building my second app in phoenix and elm.
In this app with 1982 lines of elm in 8 files, and it compiled in 453ms in total on a change (elm: v0.18). Since elm is a front-end language, I think elm files are separated like User.elm, Editor.elm or Post.elm, each communicating with backend by api individually, therefore it is reasonable to assume code in each (each part of, if you prefer architecture like Update.elm Model.elm) elm file is not too much and the compile time is linear to total code lines.
If you spent over 40s in compiling the elm files in a real world project, does it mean you have approximately over 175000 lines of elm? If my theory is wrong, does it mean that when elm files are increasing, the total compile time is increasing much faster? Another question, why not test each part of elm files individually in development?
Elm is not necessarily bad, and TEA is not bad at all, just the Elm ‘language’ has…issues that I kept running in to repeatedly. Bucklescript is an awesome transpiler, but the language is OCaml of course.
Ah still a tiny app yeah, it will compile fast still.
Compile time is not linear to total code lines, the way the Elm compiler works is it tries to ‘resolve’ a lot of paths in the type system, in some cases very inefficiently, so you have have very little code and suddenly get 15 minutes compile times (I hit one of those cases once) or have 50k lines that compile in 40 seconds (which was about the best I could get it down to without breaking up the messages a great deal more). In the ‘general’ case the compile time will increase at a small exponential, but it is a great deal more than linear (I do not think any compiler could compile in linear speed short of direct assembly or something similar).
It was about 29,000 lines. And cannot test the compile time of individual files since elm compiles them in whole. Elm takes all the files and concats them into a single giant javascript file (with interestingly no optimizations performed over it). The OCaml compiler (and thus bucklescript) compiles each module by itself (after pre-generating types from dependent modules, but not compiling them) and outputs a javascript file for each module (with as many in-module optimizations possible already performed) in such a way to be trivially optimizable further by the likes of rollup or the closure compiler both). That means that by definition OCaml will always compile faster than something like Elm that output a single monolithic file.
However, elm is thinking of splitting up into multiple JS file per module like Bucklescript is doing, however they are requiring that all dependent modules are compiled first, which still makes per-file compilation linear (with in-file compilation still exponential) compared to OCaml/Bucklescript that can compile everything concurrently.
Sadly, a lot of the compile-time issues will not be able to be improved significantly in the Elm compiler because the design of the Elm language took a few very specific and VERY slow-to-compile Haskell’isms instead of the OCaml style, thus to fix those the language would have to make a couple very specific syntax changes, which are quite a radical change from what it does not.
Just one update, we now have 4302 lines of Elm and the compile time of a change is 307ms.
I’ve never seen one so small! Do you have it available? I’d like to try compiling it.
Screencast is not useful for testing on same systems though. 
Also, you do not seem to be compiling a single project, your elm files are being compiled into different javascript files, which is not how elm works for a single project. Thus it looks like you are compiling a lot of micro-applications (which consequently will be HUGE in filesize compared to a monolithic file), which will of course compile faster than a large type system.
For note, the game in the blog posts so far compiles from scratch in 0.03s on my system so far, you could re-make it in elm and post it up, that would be an interesting test. 
Because the project is private, the only data I can provide you is the screencast of my pc.
My project is a single project, not even a umbrella project.
If you ever build a project using Elm and Phoenix in real world, you may try to put all elm files in a src folder and export them to a Main.elm and then compile the Main.elm. That is not a wise way to organize all elm files, because you will not put all views in one single index.html.eex. If you think that’s how elm should work in a single project, I think you are wrong.
All js files are concatenated into one app.js: “info: compiled 4 files and 8 cached into app.js in 284 ms”. And the html only needs app.js, which is a monolithic file.
I am not arguing that elm compiles any faster than bucklescript. If you just aim for absolute compile time, bucklescript is obviously better. I am suggesting that If one builds a project with elm as the frontend language, there is a much better way to organize all elm files: not to import all views into one View.elm, not to import all models into one Model.elm, not handle all msgs (even indirectly) in one Update.elm. If you follow my suggestions, you will not have to wait too long for a change in one elm file.
I think I am still new to elm, not writing any effect managers, not reading enough source code, but someone in elm community once told me they have over 100k LoC and incremental recompiles are about 1s:
What do you think @jackalcooper ?
Except I had to do that as it was a single monolithic app, thus yes all the views were together. The way Elm’s type resolver works is the more types you have then the exponentially slower it gets to compile.
If you check you’ll see the elm standard lib duplicated a lot, though google closure can help with that at times.
Okay, so how would you split up a single monolithic notification/messaging app for a teacher tracking system? How could you not import all the parts of the view into a singular location?
rtfeldman’s thing minimizes the types used and they have multiple pages, not a single page that drives everything. They came from a javascript centered world so types were not at their forefront. A ~28k line project here takes about 48s to compile even after it had already been compiled once, though this was in 0.17, 0.18 brought some improvements in some areas but nothing substantial.
EDIT: Also Elm has nothing to do with ocaml, moved to where it belongs. 
Yes, no concatenation is needed, thus less time is required.
Using different divs in index.html.eex dealing with user profile, notification, data…, each with an elm file (folder) not a single one.
We are not focusing on single page application, but a single project with multiple pages. It is not reasonable to assume that a team wrote 100K LoC of Elm instead of JS, not caring about types.
How many branches are there in update function in your single page monolithic application?
Assuming you have done an experiment to get the correct exp number, in most cases, in multiple page apps, you can organize the architecture so that not a single part of elm files have too many types to get that slow.
The original is not about Ocaml. It is about bucklescript, where you made a lot of comparison with Elm, one of which I am arguing about is the recompile time and app structure, which may be misleading to those who actually not aim to build a single page monolithic app with huge types reaching 28k lines.
I will dig more into Elm as development, and aim to get an unbiased view of it.
Not easily possible when all need to interact together and share information though.
Eh, the largest I think is 18, but a lot of those are delegation messages to other areas, which in turn might have other delegation messages.
I’d be curious to see monolithic projects in it, I’ve yet to see one the size of the one we had at work. ^.^
EDIT: For note, the four main reasons I see Bucklescript taking over Elm is that:
I have take a look to Bucklescript looks pretty interesting, but I have a mind blow…
I’m learning Elm actually, I already take a look to another frameworks like Vuejs, Angular, React, Ember and I really don’t like javascript at all, thats why I take Elm
I see your post about Bucklescript and have a lot of advantages, but Elm like all js frameworks, aim to make the frontend dev more easy, but Bucklescript looks like a translator thats all, for example I haven’t see a example to create a single page app, so I don’t see any way to compare with a “complete tool-kit” to frontend like Elm.
Maybe I’m very wrong but I like to know what you think
I don’t tell Bucklescript is bad, I’m just curious its just a translator or have advantages to create spa for example
PD: I also have my problems with Elm, create functions its very confusing, and handle json its really painfull more for a SPA, I want for a better solution to my project, I like Vuejs but javascript is… duh
Also check out Drab
It’s ready for production? I don’t take a complete look because when I saw the readme tell us this:
Warning: this software is still experimental!
So I think was just an experiment…
© Copyright Elixir Forum | Terms | Privacy & Cookies
