I honestly suggest going as far as you can with either Elm or BuckleScript-TEA and then evaluating the experience based on results. Personally, I think BuckleScript-TEA has higher potential mostly because OCaml is a fantastic language. The upside also is that you’d be in early when there’s an opportunity to shape things.
6 Likes
I’m planning to keep the ' in the names instead of _ preferably as it’s more OCaml’y (and what elm did before), but I try to keep backwards things working, even if new things are identical too.
Exactly, React is very designed for a mutable component style setup.
Do note that Buckelscript is not the only javascript backend for OCaml either. There is also js_of_ocaml, but it’s a very low level translater, meaning it makes horrendously ugly, but fast, javascript code. And there is a webassembly back-end in dev too so that might be the best thing to use later. I designed the API of bucklescript-tea to not really be tied to bucklescript (it could compile to the backend or whatever else as well) but it does use the bucklescript’s ppx elsewhere (it has some nice helpers built in that’d require multiple other PPX’s to use, especially in regards to testing the platform state), but I’ve been intending to make it support generating web pages on the server too (would be easy to drop in to (or even link in as a NIF) elixir projects then).
That’s similar to my ultimate design that I still need to get around to making. The full WebComponent spec for HTML5 is pretty well ‘set’ now, and TEA would work fantastically inside each webcomponent, I want to make that trivial to make and use. ^.^
Vua is kind of like webcomponents but in pure javascript and less interoperability. It’s pretty decent though if mutability is fine to you, and you could even build an immutable system if you to as well.
Yeah the catch-all is highly discouraged in the Elm world (and the OCaml world too).
However holding state for things like a button ripple in the material design is horrendous, that is where webcomponents come in, as then you’d use it like a normal button and still pass in the state to it that is actually important to the main app. ^.^
Yeah it has no higher typed modules, no HPT’s, no HKT’s (I’m still not a fan of HKT’s, I’d prefer HPT’s) and more, it makes it very difficult to make re-usable code (it’s very like Go in that way…).
Yes OCaml can handle that fine. 
I hit it really REALLY fast, I ended up making literal hundreds of helper functions because of it’s utter lack of anything remotely like generics or higher types.
Yeah pick whichever you prefer, tea or react, but definitely use a better language. ^.^;
That was my use-case. 
I love Issues and PR’s! Especially ones that spur discussion and make me think.
I really need to start my whole webcomponent style one.
It would be pretty easy to plug it into react too actually, that’s on my ‘to-look-at’ list someday too.
4 Likes
I guess BuckleScript for Node.js based FaaS is a nice option (especially with the JS platform optimized stdlib).
Scalable and serverless media processing using BuckleScript/OCaml and AWS Lambda/API Gateway
OCaml on operations
Still much slower than OCaml compiled to native though. ^.^
Are there any nice web frameworks in OCaml? Just curious, not thinking of using them in real life
The only established I know about is ocsigen (https://ocsigen.org/).
Is it nice? I don’t know 
I tried to learn it a while back but didn’t spend too much time on it. It works a little bit differently than your normal web framework (it is continuation based).
2 Likes
To add my usual opinion about this:
There is still F-Sharp with Elmish and Fable.
It supports a high variety of interesting web frameworks, such as Websharper, Freya and Giraffe, as well as Service Stack, Suave and what not. 
I think in terms of Javascript interop is WebSharper and Fable
outstanding.
Besides of this, since somebody mentions Unikernels above:
Can anybody explain me the obvious benefits of OCamls Unikernels compared to .NET Core on SmartOS?
The downside is obviously that you have to reimplement each single part in a pretty expensive way, while the other one is running without any adoption.
The benefit of Unikernels is so far as I am informed, that you reduce the amout of code which you ship with your software.
Are there any other differences?
AWS lamnda node vs go
I assume for Unikernel you can customize what you what to strip from OS, depends what is required for your application. For example you can remove all USB support from kernel if you don’t need it.
Smart Os is quite interesting like https://www.redox-os.org/ (OS written in Rust )
1 Like
Yes, I think its amazing how two dudes coded a functional OS within two years.
Shows the power of Rust, IMHO.
My gut tells me that I can compile SmartOS without specific components also and this OS is anyway very lean already.
I would prefer anyhow that I am able to run all the already written .NET software on it.
This issue lets Unikernel appear very nonelastic?
Podcast with author of redox. He talks a little about Unikernels.
1 Like
A Pragmatists’s Guide to ReasonML. Marcel Cutts - React Day Berlin (2017-12-02)
With an Erlang/Elixir cameo @2:49.
5 Likes
What can happen when you try to “learn a language by doing a project”:
Fun Fun Function: Let’s code a speed typing game with ReasonML
3 Likes
I think this is a perfect illustration of how the JS syntax is of absolutely no significance at all. If anything, it allows people to think they know what’s going on but ultimately it’s a false friend. People who know only know JavaScript won’t just start using ReasonML and magically know what to do, so having this imaginary crutch doesn’t lead anywhere. It’s easy to assume it’s working when you’re actually doing the same work via actual training, etc… Familiarity of syntax is incredibly overrated.
MPJ funnily enough has done this previously. He started a series about learning Haskell that fizzled out pretty early, but much like with this super short foray into ReasonML he developed opinions that don’t match the time he spent at all. I think he does it to pander to other people who’ve done this as well in order to sort of validate their experiences and echo what they think, so that he gets a better connection with his audience.
2 Likes
Don’t forget you can get 35% off with your forum discount, use code ‘ElixirForum’ 
Announcement: Web Development with ReasonML, in beta (Newsletter)
J. David Eisenberg is also author of Études for Elixir (Études for Erlang, Études for ClojureScript) and coauthor of Introducing Elixir (O'Reilly)
10 Likes
https://blog.usejournal.com/journey-with-reasonml-as-a-junior-developer-17ee53a25fa7
In order to achieve long-term stability as a great engineer, knowing the syntax of individual programming languages seems less important now than developing a strong way of thinking about and constructing code.
https://medium.com/@lineville/how-functional-programming-made-me-a-better-web-developer-851db7f214b8
1 Like
This is an oddly good article about how strong types make for much better programming, Elixir could learn from this. ^.^
1 Like
I also thought it is a good anecdote about the kicking’n’screaming that can go on when some imperative programmers are dragged into functional programming because of familiarity bias. In this case it had a good ending but sometimes people just bail.
So, after dabbling in the shallows of functional programming in Python, …
Over the two (of six) weeks I’ve stuck with this MOOC, I’ve seen some very interesting things - …
But I’ve really struggled to get things - the toy programs in this introductory part of an introductory course - to work, so I’m dropping out. The alienness of ML - conceptually, syntax-wise and to some extent in terms of the vocabulary used to describe concepts - is definitely the main factor.
1 Like
