3 posts were split to a new topic: Web Assembly - impact on web development
Bucklescript is OCaml, even if it fails there is still another json backend for ocaml called json_of_ocaml (it makes very low level code, not as readable as bucklescripts output, but it can handle more than bucklescript), so there is a migration path regardless.
Honestly at this point I’m looking toward wasm, and primarily Rust.
Bucklescript is just a language, it’s not a framework. The most popular framework in bucklescript is React (yes that React), my bucklescript-tea is another, and a few others have popped up as well.
The speed will be dependent on the framework you use. At worst the speed of BS will be about on par with JS, at best it will be faster due to better typing optimizations. For my framework of bucklescript-tea it outperformed a dozen other things I tested it again, but I mostly made it to make porting Elm applications more easy, I’d generally recommend something else for a new application unless you really just want the elm approach.
BS is just a language, SSR is calls, it’s about the same as in javascript, and generally your framework will deal with that.
Remember, you can call any javascript framework from BS.
Svelte is fast, has SSR, offline support, has no VDOM, it is fully reactive, it seems to me there is more up-to-date resources, but on the other hand Svelte has no strong and static types ;/
Svelte is a framework, not a language, it’s a language that supplies strong/static types, not the framework. You can use Svelte with BS. You can use Svelte with Typescript. You can even use Svelte from Rust. Use whatever language you think you will be most productive in, in the long term, then choose whatever framework is most appropriate for the task, then use them together.
Specifically BS is a language, not a framework, and Svelte is a framework, not a language.
Yes these. ^.^
Elm is a language, BS is a language, so they are comparable. Elm was based on a simplified OCaml, BS is a full OCaml, thus BS has more capabilities and features than Elm (though is newer than Elm, but has the entire processing pipeline from the multi-decade old OCaml behind it, unlike Elm).
They probably meant to compare Svelte/React/Etc… to TEA, which is The Elm Architecture, which is different from Elm-the-language (my bucklescript-tea is a TEA framework in BS for example).
That would be more accurate, bs-tea is just a TEA implementation. But still, use whatever you think is most appropriate for whatever task you are making.
Actually ReasonML is just another syntax on top of OCaml, nothing hard binds it to react at all. Bucklescript, for example, can translate the ReasonML->OCaml pipeline into javascript instead of native code, but you can use ReasonML to generate native code just as easily as normal OCaml. Bucklescript isn’t even a language, it’s just a backend for the OCaml compiler to output javascript instead of bytecode or native code.
I love yew, I’ve only experimented with it but it’s basically TEA in Rust, it’s awesome. Rust is a bit overkill compared to OCaml for single-threaded apps (which the web is), but the Rust ecosystem is ginormous and being able to wrap code in rust for backend and frontend both cannot be overstated. ^.^
Definitely agree here, don’t touch frameworks until you actually understand HTML, CSS, Javascript, and most especially how the DOM itself works. Not just a quick glossing but a lot of the oddities as well. Without understanding these your frontend will never be efficient or stable. Offline apps of which are even harder.
Svelte does intend to support TypeScript eventually. (Personally though I wonder whether TypeScript will in the long term suffer the same fate as CoffeeScript - so I’d be inclined to use it with JSDoc annotations instead).
Or Flow. Really though I foresee typescript replacing javascript someday, but I have no doubt wasm will overtake it all (typescript can compile a subset of itself to wasm, so that’s not bad to learn either).
And a framework doesn’t need to support TypeScript, you can add the typing bindings yourself easily enough, the ‘support’ is just including a prebuilt set of bindings, which is not really needed.
2 Likes
I’ve read on main page:
Svelte [...] It's a compiler that takes your declarative components and converts them into efficient JavaScript
There is also issue on github about adding typescript support, and it might be problem to use svelte with other languages I guess.
I know HTML, CSS, JS, but I will learn more about DOM and other stuff before start writing in frameworks. After that, maybe I will make simple apps in svelte and elm, and then decide, if I go dipper and checkout BS or stay with svelte.
Thanks ALL 
Svelte 3 is a (reactive) UI compiler - Solid is another one that popped up recently.
https://medium.com/@ryansolid/javascript-ui-compilers-comparing-svelte-and-solid-cbcba2120cea
Sapper is the Svelte based framework.
Have a look at Go Make Things: Daily Developer Tips
After that, maybe I will make simple apps in svelte and elm
With Elm it’s a foregone conclusion that you are building an SPA. “Offline first” doesn’t automatically imply an SPA thanks to the Service Worker API.
1 Like
It’s as much of a compiler as PPX is, I.E. it’s a transpiler just converting some syntax. It’s not a language. And you don’t need to use the transpiler unless you are wanting to use the very-PPX-like syntax (can do it via other ways).
The DOM is hell, but it is absolutely required to know well… ^.^;
Looking at the code it appears to be a fairly simple ppx-like transpiler? Not a compiler by any stretch?
1 Like
You can also check facebook Reason ML https://reasonml.github.io/.
50% of facebook messenger is in Reason ML
https://reasonml.github.io/blog/2017/09/08/messenger-50-reason
https://sketch.sh/
If someone in Chicago October 7th 2019
https://www.reason-conf.us/
Little of topic but cool 
Purescript-native can now target Golang
2 Likes
You have a very specific idea of what a “compiler” is.
In this case it loosely refers to a source-to-source compiler.
For example I remember Cfront and other products of its ilk being referred to as cross-compilers - I didn’t run into the term transpiler until Traceur and Babel which both refer to themselves as compilers.
So usage of the term compiler has become more and more sloppy over the years because it is being applied to all sorts of transformers.
I generally do, it’s because where I teach has a very specific idea of a compiler. ^.^
This sounds more like what is now called a Transpiler (though “back in ma’ day” a PreProcessor).
Yeah that’s generally where that term came from as far as I know as well. A Pre-Processor was the old term.
Quite agree, a transformer is not a compiler (though a compiler is a transformer). ^.^
From a “C-language” perspective preprocessors always seemed to be associated with something like macro expansion (which Elixir resolves at compile time).
C’s preprocessor focused on macro expansion, but don’t forget it is turing complete, C’s preprocessor can do full code generation, recursion, the works. Other preprocessors were even more easily used. One of the most famous old ones was Caml4P.
If anyone is interested in OCaml, there is a free MOOC starting tomorrow. I’m going to watch the lectures.
2 Likes
